來自Uber，最牛逼的kafka集群怎樣的？
Uber 擁有世界上最大的 Kafka 集群，每天處理數(shù)萬億條消息和幾個 PB 的數(shù)據(jù)。如圖 1 所示，Kafka 現(xiàn)在成了 Uber 技術(shù)棧的基石，我們基于這個基石構(gòu)建了一個復(fù)雜的生態(tài)系統(tǒng)，為大量不同的工作流提供支持。其中包含了一個用于傳遞來自乘客和司機 App 事件數(shù)據(jù)的發(fā)布 / 訂閱消息總線、為流式分析平臺（如 Apache Samza、Apache Flink）提供支持、將數(shù)據(jù)庫變更日志流到下游訂閱者，并將各種數(shù)據(jù)接收到 Uber 的 Hadoop 數(shù)據(jù)湖中。
圖 1：Uber 的 Kafka 生態(tài)系統(tǒng)
為了能夠基于 Kafka 構(gòu)建一個可伸縮、可靠、高性能、易于使用的消息傳遞平臺，我們克服了許多挑戰(zhàn)。在這篇文章中，我們將著重介紹在進行災(zāi)難恢復(fù)（因集群宕機導(dǎo)致）時所面臨的一個挑戰(zhàn)，并分享我們?nèi)绾螛?gòu)建一個多區(qū)域的 Kafka 基礎(chǔ)設(shè)施。
提供業(yè)務(wù)彈性和連續(xù)性是 Uber 的首要任務(wù)。我們制定了詳細的災(zāi)難恢復(fù)計劃，盡量減少自然和人為災(zāi)難 (如停電、災(zāi)難性軟件故障和網(wǎng)絡(luò)中斷) 對業(yè)務(wù)的影響。我們采用多區(qū)域部署策略，將服務(wù)與備份一起部署在分布式的數(shù)據(jù)中心中。當(dāng)一個區(qū)域的物理基礎(chǔ)設(shè)施不可用時，服務(wù)仍然可以在其他區(qū)域運行。
我們構(gòu)建了一個多區(qū)域 Kafka 架構(gòu)，實現(xiàn)了數(shù)據(jù)冗余，為區(qū)域故障轉(zhuǎn)移提供支持。Uber 技術(shù)棧中的很多服務(wù)都依賴 Kafka 來實現(xiàn)區(qū)域級故障轉(zhuǎn)移。這些服務(wù)是 Kafka 的下游，并假定 Kafka 中的數(shù)據(jù)是可用且可靠的。
圖 2 描繪了多區(qū)域 Kafka 架構(gòu)。我們有兩種集群：生產(chǎn)者在本地向區(qū)域集群發(fā)布消息，將來自區(qū)域集群的消息復(fù)制到聚合集群，以此來提供全局視圖。為簡單起見，圖 2 只顯示了兩個區(qū)域的集群。
圖 2：兩個區(qū)域之間的 Kafka 復(fù)制拓撲
在每個區(qū)域，生產(chǎn)者總是在本地生產(chǎn)消息，以便獲得更好的性能，當(dāng) Kafka 集群不可用時，生產(chǎn)者會轉(zhuǎn)移到另一個區(qū)域，然后向該區(qū)域的區(qū)域集群生產(chǎn)消息。
這個架構(gòu)中的一個關(guān)鍵部分是消息復(fù)制。消息從區(qū)域集群異步復(fù)制到其他區(qū)域的聚合集群。我們開發(fā)了 uReplicator（https://eng.uber.com/ureplicator）——Uber 的 Kafka 數(shù)據(jù)復(fù)制解決方案，健壯且可靠。uReplicator 擴展了 Kafka 的 MirrorMaker，專注于可靠性、零數(shù)據(jù)丟失保證和易維護性。
從多區(qū)域集群消費消息比生產(chǎn)消息更為復(fù)雜。多區(qū)域 Kafka 集群支持兩種類型的消費模式。
一種常見的類型是雙活（Active/Active）消費模式，消費者在各自區(qū)域中消費聚合集群的主題。Uber 的很多應(yīng)用程序使用這種模式消費多區(qū)域 Kafka 集群里的消息，而不是直接連接到其他區(qū)域。當(dāng)一個區(qū)域發(fā)生故障時，如果 Kafka 流在兩個區(qū)域都可用，并且包含了相同的數(shù)據(jù)，那么消費者就會切換到另一個區(qū)域。
例如，圖 3 顯示了 Uber 的動態(tài)定價服務(wù) (即峰時定價) 如何使用雙活模式來構(gòu)建災(zāi)備計劃。價格是根據(jù)附近地區(qū)最近一系列打車數(shù)據(jù)來計算的。所有的打車事件都被發(fā)送到 Kafka 區(qū)域集群，然后聚合到聚合集群中。然后，在每個區(qū)域，一個復(fù)雜的、占用大量內(nèi)存的 Flink 作業(yè)負責(zé)計算不同區(qū)域的價格。接下來，一個全活服務(wù)負責(zé)協(xié)調(diào)各個區(qū)域的更新服務(wù)，并分配一個區(qū)域作為主區(qū)域。主區(qū)域的更新服務(wù)將定價結(jié)果保存到雙活數(shù)據(jù)庫中，以便進行快速查詢。
圖 3：雙活消費模式架構(gòu)
當(dāng)主區(qū)域發(fā)生災(zāi)難時，雙活服務(wù)會將另一個區(qū)域作為主區(qū)域，峰時價格計算會轉(zhuǎn)移到另一個區(qū)域。需要注意的是，F(xiàn)link 作業(yè)的計算狀態(tài)規(guī)模太大了，無法在區(qū)域之間同步復(fù)制，因此必須使用聚合集群的輸入消息來計算其狀態(tài)。
我們從實踐中獲得了一個很關(guān)鍵的經(jīng)驗，可靠的多區(qū)域基礎(chǔ)設(shè)施服務(wù)（如 Kafka）可以極大地簡化應(yīng)用程序針對業(yè)務(wù)連續(xù)性計劃的開發(fā)工作。應(yīng)用程序可以將狀態(tài)存儲在基礎(chǔ)設(shè)施層中，從而變成無狀態(tài)的，將狀態(tài)管理的復(fù)雜性 (如跨區(qū)域的同步和復(fù)制) 留給基礎(chǔ)設(shè)施服務(wù)。
另一種多區(qū)域消費模式是主備模式（Active/Passive）：一次只允許一個消費者 (通過唯一名稱標(biāo)識) 從一個區(qū)域 (即主區(qū)域) 的聚合集群中消費消息。多區(qū)域 Kafka 集群跟蹤主區(qū)域的消費進度（用偏移量表示），并將偏移量復(fù)制到其他區(qū)域。在主區(qū)域出現(xiàn)故障時，消費者可以故障轉(zhuǎn)移到另一個區(qū)域并恢復(fù)消費進度。主備模式通常被支持強一致性的服務(wù) (如支付處理和審計) 所使用。
在使用主備模式時，區(qū)域間消費者的偏移量同步是一個關(guān)鍵問題。當(dāng)用戶故障轉(zhuǎn)移到另一個區(qū)域時，它需要重置偏移量，以便恢復(fù)消費進度。由于 Uber 的很多服務(wù)不能接受數(shù)據(jù)丟失，所以消費者無法從高水位 (即最新消息) 恢復(fù)消費。另外，為了避免過多的積壓，消費者也不能從低水位 (即最早的消息) 恢復(fù)消費。此外，從區(qū)域集群聚合到聚合集群的消息可能會變得無序。由于跨區(qū)域復(fù)制延遲，消息從區(qū)域集群復(fù)制到本地聚合集群的速度比遠程聚合集群要快。因此，聚合集群中的消息順序可能會不一樣。例如，在圖 4a 中，消息 A1、A2、B1、B2 幾乎是同時發(fā)布到區(qū)域 A 和區(qū)域 B 的區(qū)域集群中，但經(jīng)過聚合后，它們在兩個聚合集群中的順序是不一樣的。
圖 4：a. 跨區(qū)域消息復(fù)制 b. 消息復(fù)制檢查點
為了管理這些區(qū)域的偏移量映射，我們開發(fā)了一個復(fù)雜的偏移量管理服務(wù)，架構(gòu)如圖 5 所示。當(dāng) uReplicator 將消息從源集群復(fù)制到目標(biāo)集群時，它會定期檢查從源到目標(biāo)的偏移量映射。例如，圖 4b 顯示了圖 4a 消息復(fù)制的偏移量映射。表的第一行記錄了區(qū)域 A 區(qū)域集群的消息 A2（在區(qū)域集群中的偏移量是 1）映射到區(qū)域 A 聚合集群的消息 A2（在聚合集群中的偏移量是 1）。同樣，其余行記錄了其他復(fù)制路線的檢查點。
偏移量管理服務(wù)將這些檢查點保存在雙活數(shù)據(jù)庫中，并用它們來計算給定的主備消費者的偏移量映射。同時，一個偏移量同步作業(yè)負責(zé)定期同步兩個區(qū)域之間的偏移量。當(dāng)一個主備消費者從一個區(qū)域轉(zhuǎn)移到另一個區(qū)域時，可以獲取到最新的偏移量，并用它來恢復(fù)消費。
圖 5：偏移量管理服務(wù)架構(gòu)
偏移量映射算法的工作原理如下：在活躍的消費者正在消費的聚合集群中找到每個區(qū)域集群的最近檢查點。然后，對于每個區(qū)域檢查點的源偏移量，找到它們在另一個區(qū)域聚合集群對應(yīng)的檢查點。最后，在另一個區(qū)域的聚合集群中取最小的那個偏移量。
在圖 6 中，假設(shè)活躍消費者目前的進度是區(qū)域 B 的 A3 消息（偏移量為 6）。根據(jù)右邊的表檢查點，最近的兩個檢查點分別是偏移量為 3(藍色) 的 A2 和偏移量為 5(紅色) 的 B4，分別對應(yīng)區(qū)域集群 A 中偏移量 1（藍色）和區(qū)域集群 B 的偏移量 3(紅色)。這些源偏移量映射到區(qū)域 A 聚合集群的偏移量 1(藍色) 和偏移量 7(紅色)。根據(jù)算法，被動消費者 (黑色) 取兩者中較小的偏移量，即偏移量 1。
圖 6：主備消費者從一個區(qū)域失效轉(zhuǎn)移到另一個區(qū)域
在 Uber，業(yè)務(wù)的連續(xù)性取決于高效、不間斷的跨服務(wù)數(shù)據(jù)流，Kafka 在公司的災(zāi)備計劃中扮演著關(guān)鍵角色。在這篇文章中，我們簡要地強調(diào)了在 Uber 多區(qū)域 Kafka 集群的總體架構(gòu)，以及當(dāng)災(zāi)難發(fā)生時不同區(qū)域的故障轉(zhuǎn)移策略。但是，我們還有更具挑戰(zhàn)性的工作要做，目前要解決如何在不進行區(qū)域故障轉(zhuǎn)移的情況下容忍單個集群故障的細粒度恢復(fù)策略。
英文原文鏈接：https://eng.uber.com/kafka/
后臺回復(fù) 學(xué)習(xí)資料 領(lǐng)取學(xué)習(xí)視頻
如有收獲，點個在看，誠摯感謝