怎么打造規模大的Kafka集群

這篇文章主要介紹“怎么打造規模大的Kafka集群”，在日常操作中，相信很多人在怎么打造規模大的Kafka集群問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”怎么打造規模大的Kafka集群”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

- Uber 的 Kafka 生態系統 -

Uber 擁有世界上最大的 Kafka 集群，每天處理數萬億條消息和幾個 PB 的數據。如圖 1 所示，Kafka 現在成了 Uber 技術棧的基石，我們基于這個基石構建了一個復雜的生態系統，為大量不同的工作流提供支持。其中包含了一個用于傳遞來自乘客和司機 App 事件數據的發布/訂閱消息總線、為流式分析平臺（如 Apache Samza、Apache Flink）提供支持、將數據庫變更日志流到下游訂閱者，并將各種數據接收到 Uber 的 Hadoop 數據湖中。

圖 1：Uber 的 Kafka 生態系統

為了能夠基于 Kafka 構建一個可伸縮、可靠、高性能、易于使用的消息傳遞平臺，我們克服了許多挑戰。在這篇文章中，我們將著重介紹在進行災難恢復（因集群宕機導致）時所面臨的一個挑戰，并分享我們如何構建一個多區域的 Kafka 基礎設施。

- Uber 的 Kafka 多區域部署 -

提供業務彈性和連續性是 Uber 的首要任務。我們制定了詳細的災難恢復計劃，盡量減少自然和人為災難(如停電、災難性軟件故障和網絡中斷)對業務的影響。我們采用多區域部署策略，將服務與備份一起部署在分布式的數據中心中。當一個區域的物理基礎設施不可用時，服務仍然可以在其他區域運行。

我們構建了一個多區域 Kafka 架構，實現了數據冗余，為區域故障轉移提供支持。Uber 技術棧中的很多服務都依賴 Kafka 來實現區域級故障轉移。這些服務是 Kafka 的下游，并假定 Kafka 中的數據是可用且可靠的。

圖 2 描繪了多區域 Kafka 架構。我們有兩種集群：生產者在本地向區域集群發布消息，將來自區域集群的消息復制到聚合集群，以此來提供全局視圖。為簡單起見，圖 2 只顯示了兩個區域的集群。

圖 2：兩個區域之間的 Kafka 復制拓撲

在每個區域，生產者總是在本地生產消息，以便獲得更好的性能，當 Kafka 集群不可用時，生產者會轉移到另一個區域，然后向該區域的區域集群生產消息。

這個架構中的一個關鍵部分是消息復制。消息從區域集群異步復制到其他區域的聚合集群。

- 從多區域 Kafka 集群消費消息 -

從多區域集群消費消息比生產消息更為復雜。多區域 Kafka 集群支持兩種類型的消費模式。

· 雙活模式

一種常見的類型是雙活（Active/Active）消費模式，消費者在各自區域中消費聚合集群的主題。Uber 的很多應用程序使用這種模式消費多區域 Kafka 集群里的消息，而不是直接連接到其他區域。當一個區域發生故障時，如果 Kafka 流在兩個區域都可用，并且包含了相同的數據，那么消費者就會切換到另一個區域。

例如，圖 3 顯示了 Uber 的動態定價服務(即峰時定價)如何使用雙活模式來構建災備計劃。價格是根據附近地區最近一系列打車數據來計算的。所有的打車事件都被發送到 Kafka 區域集群，然后聚合到聚合集群中。然后，在每個區域，一個復雜的、占用大量內存的 Flink 作業負責計算不同區域的價格。接下來，一個全活服務負責協調各個區域的更新服務，并分配一個區域作為主區域。主區域的更新服務將定價結果保存到雙活數據庫中，以便進行快速查詢。

圖 3：雙活消費模式架構

當主區域發生災難時，雙活服務會將另一個區域作為主區域，峰時價格計算會轉移到另一個區域。需要注意的是，Flink 作業的計算狀態規模太大了，無法在區域之間同步復制，因此必須使用聚合集群的輸入消息來計算其狀態。

我們從實踐中獲得了一個很關鍵的經驗，可靠的多區域基礎設施服務（如 Kafka）可以極大地簡化應用程序針對業務連續性計劃的開發工作。應用程序可以將狀態存儲在基礎設施層中，從而變成無狀態的，將狀態管理的復雜性(如跨區域的同步和復制)留給基礎設施服務。

· 主備模式

另一種多區域消費模式是主備模式（Active/Passive）：一次只允許一個消費者(通過唯一名稱標識)從一個區域(即主區域)的聚合集群中消費消息。多區域 Kafka 集群跟蹤主區域的消費進度（用偏移量表示），并將偏移量復制到其他區域。在主區域出現故障時，消費者可以故障轉移到另一個區域并恢復消費進度。主備模式通常被支持強一致性的服務(如支付處理和審計)所使用。

在使用主備模式時，區域間消費者的偏移量同步是一個關鍵問題。當用戶故障轉移到另一個區域時，它需要重置偏移量，以便恢復消費進度。由于 Uber 的很多服務不能接受數據丟失，所以消費者無法從高水位(即最新消息)恢復消費。另外，為了避免過多的積壓，消費者也不能從低水位(即最早的消息)恢復消費。此外，從區域集群聚合到聚合集群的消息可能會變得無序。由于跨區域復制延遲，消息從區域集群復制到本地聚合集群的速度比遠程聚合集群要快。因此，聚合集群中的消息順序可能會不一樣。例如，在圖 4a 中，消息 A1、A2、B1、B2 幾乎是同時發布到區域 A 和區域 B 的區域集群中，但經過聚合后，它們在兩個聚合集群中的順序是不一樣的。

圖 4：a.跨區域消息復制 b.消息復制檢查點

為了管理這些區域的偏移量映射，我們開發了一個復雜的偏移量管理服務，架構如圖 5 所示。當 uReplicator 將消息從源集群復制到目標集群時，它會定期檢查從源到目標的偏移量映射。例如，圖 4b 顯示了圖 4a 消息復制的偏移量映射。表的第一行記錄了區域 A 區域集群的消息 A2（在區域集群中的偏移量是 1）映射到區域 A 聚合集群的消息 A2（在聚合集群中的偏移量是 1）。同樣，其余行記錄了其他復制路線的檢查點。

偏移量管理服務將這些檢查點保存在雙活數據庫中，并用它們來計算給定的主備消費者的偏移量映射。同時，一個偏移量同步作業負責定期同步兩個區域之間的偏移量。當一個主備消費者從一個區域轉移到另一個區域時，可以獲取到最新的偏移量，并用它來恢復消費。

圖 5：偏移量管理服務架構

偏移量映射算法的工作原理如下：在活躍的消費者正在消費的聚合集群中找到每個區域集群的最近檢查點。然后，對于每個區域檢查點的源偏移量，找到它們在另一個區域聚合集群對應的檢查點。最后，在另一個區域的聚合集群中取最小的那個偏移量。

在圖 6 中，假設活躍消費者目前的進度是區域 B 的 A3 消息（偏移量為 6）。根據右邊的表檢查點，最近的兩個檢查點分別是偏移量為 3(藍色)的 A2 和偏移量為 5(紅色)的 B4，分別對應區域集群 A 中偏移量 1（藍色）和區域集群 B 的偏移量 3(紅色)。這些源偏移量映射到區域 A 聚合集群的偏移量 1(藍色)和偏移量 7(紅色)。根據算法，被動消費者(黑色)取兩者中較小的偏移量，即偏移量 1。

圖 6：主備消費者從一個區域失效轉移到另一個區域 

到此，關于“怎么打造規模大的Kafka集群”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！