Kafka架構圖

來自專欄 Python程序員27 人贊了文章

作者：Zarten

知乎ID： Zarten

簡介： 互聯網一線工作者，尊重原創並歡迎評論留言指出不足之處，也希望多些關注和點贊是給作者最好的鼓勵 ！

1.架構圖

如上圖，一個kafka架構包括若干個Producer（伺服器日誌、業務數據、web前端產生的page view等），若干個Broker（kafka支持水平擴展，一般broker數量越多集群的吞吐量越大），若干個consumer group，一個Zookeeper集群（kafka通過Zookeeper管理集群配置、選舉leader、consumer group發生變化時進行rebalance）。

2.名稱解釋

• Broker

消息中間件處理節點（伺服器），一個節點就是一個broker，一個Kafka集群由一個或多個broker組成

• Topic

Kafka對消息進行歸類，發送到集群的每一條消息都要指定一個topic

• Partition

物理上的概念，每個topic包含一個或多個partition，一個partition對應一個文件夾，這個文件夾下存儲partition的數據和索引文件，每個partition內部是有序的

• Producer

生產者，負責發布消息到broker

• Consumer

消費者，從broker讀取消息

• ConsumerGroup

每個consumer屬於一個特定的consumer group，可為每個consumer指定group name，若不指定，則屬於默認的group，一條消息可以發送到不同的consumer group，但一個consumer group中只能有一個consumer能消費這條消息

3.關係解釋

• Topic & Partition

一個topic為一類消息，每條消息必須指定一個topic。物理上，一個topic分成一個或多個partition，每個partition有多個副本分布在不同的broker中，如下圖3.1。

每個partition在存儲層面是一個append log文件，發布到此partition的消息會追加到log文件的尾部，為順序寫人磁碟（順序寫磁碟比隨機寫內存的效率還要高）。每條消息在log文件中的位置成為offset（偏移量），offset為一個long型數字，唯一標記一條消息。如下圖3.2

每個消費者唯一保存的元數據是offset值，這個位置完全為消費者控制，因此消費者可以採用任何順序來消費記錄，如下圖3.3

圖3.1

另外，對於傳統的消息隊列而言，一般會刪除已經被消費的消息，而kafka集群會保留所有的消息。因為磁碟限制，不可能永久保留所有消息，因此kafka提供了兩種策略刪除數據：1.基於時間，讓kafka刪除2天或一周的數據；2.基於partition文件大小：讓kafka在partition文件超過1GB時刪除數據

圖3.2

圖3.3

kafka中只能保證partition中記錄是有序的，而不保證topic中不同partition的順序

• Consumer group & consumer

一個消費組由一個或多個消費者實例組成，便於擴容與容

錯。kafka是發布與訂閱模式，這個訂閱者是消費組，而不是消費者實例。每一條消息只會被同一個消費組裡的一個消費者實例消費，不同的消費組可以同時消費同一條消息，如下圖

為了實現傳統的消息隊列中消息只被消費一次的語義，kafka保證同一個消費組裡只有一個消費者會消費一條消息，kafka還允許不同的消費組同時消費一條消息，這一特性可以為消息的多元化處理提供了支持，kafka的設計理念之一就是同時提供離線處理和實時處理，因此，可以使用Storm這種實時流處理系統對消息進行實時在線處理，同時使用Hadoop這種批處理系統進行離線處理，還可以同時將數據實時備份到另一個數據中心，只需要保證這三個操作的消費者實例在不同consumer group 即可

創建一個topic（名為topic1，3個partition 0,1,2），group1有1個consumer，group2中有3個consumer，通過producer向topic1發送3條消息（key分別為1,2,3），結果group1中的1個consumer收到了所有這2條消息，group2中的3個consumer分別收到了這3條消息，如下圖

• Consumer Rebalance

kafka保證了同一個消費組中只有一個消費者實例會消費某條消息，實際上，kafka保證的是穩定狀態下每一個消費者實例只會消費一個或多個特定partition數據，而某個partition的數據只會被某一特定的consumer實例消費，這樣設計的劣勢是無法讓同一個消費組裡的consumer均勻消費，優勢是每個consumer不用跟大量的broker通信，減少通信開銷，也降低了分配難度。而且，同一個partition數據是有序的，保證了有序被消費。根據consumer group中的consumer數量和partition數量，可以分為以下3種情況：

1. 若consumer group中的consumer數量少於partition數量，則至少有1個consumer會消費多個partition數據
2. 若consumer group中的consumer數量多於partition數量，則會有部分consumer無法消費該topic中任何一條消息
3. 若consumer group中的consumer數量等於partition數量，則正好一個consumer消費一個partition數據

測試如下，topic1中有3個partition分別為0,1,2：

• 當group1中只有1個consumer1時，該consumer1可消費這3個partition的所有數據

• 增加1個consumer2後，consumer1消費2個partition數據，consumer2消費1個partition數據

• 再增加1個consumer3後，consumer 1,2,3 分別消費 partition 1,2,3

• 再增加1個consumer4後，3個consumer可分別消費1個partition，另1個consumer4不能消費topic1任何數據

• 此時關閉consumer1，剩下的consumer可分別消費1個partition的數據

• 再關閉consumer2，剩下的consumer3可消費2個partition，consumer4可消費1個partition

• 再關閉consumer3，剩下的consumer4可消費3個partition

consumer rebalance的控制策略是由每個consumer通過Zookeeper完成的。

參考文章：

• Apache Kafka
• Kafka數據可靠性深度解讀
• Kafka深度解析

推薦閱讀：