1、Kafka概覽

Apache下的項目Kafka(卡夫卡)是一個分布式流處理平臺，它的流行是因為卡夫卡系統的設計和操作簡單，能充分利用磁盤的順序讀寫特性。kafka每秒鐘能有百萬條消息的吞吐量，因此很適合實時的數據流處理。例如kafka在線日誌收集系統可作為flume的實時消息sink端，再通過kafka的消費者將消息實時寫入hbase數據庫中。

卡夫卡以topic分類對記錄進行存儲，每個記錄包含key-value和timestamp。

1.1卡夫卡系統的組件、角色

broker: 每個正在運行的kafka節點

producer：消息生產者

consumer：消息的消費者

consumer group：消費者組，同一個消費者組只能有一個consumer能消費消息

kafka server ：也叫作broker, 已部署kafka的服務器, 以broker.id來區分不同的服務器

topic：主題, 主題中的每條消息包括key-value和timestamp。可以定義多個topic，每個topic又可以劃分為多個分區

partition：topic下的消息分區，通過key取哈希後把消息映射分發到一個指定的分區，每個分區都映射到broker上的一個目錄。一般每個分區存儲在一個broker上

replica：副本， 每個分區按照生產者的消息達到順序存放。每個分區副本都有一個leader

leader replica：leader角色的分區副本，leader角色的分區處理消息的讀寫請求. Leader和follower位於不同的broker.

follower replica：follower角色的分區副本，負責從Leader拉取數據到本地，實現分區副本的創建

zookeeper：嚴格來說這不是kafka的組件。但是在Kafka集群中, 很有必要通過Zookeeper管理kafka集群的配置、選舉leader，以及在Consumer Group發生變化時進行rebalance。下面說一下kafka的哪些組件需要註冊到zookeeper——

為什麽要註冊到zk集群？
1，Kafka集群通過Zookeeper來管理kafka的配置，選舉leader；
2，在Consumer Group發生變化時進行rebalance
3，所有的topic與broker的對應關系都由zk維護

kafka的哪些組件需要註冊到zookeeper？
（1）Broker註冊到zk
每個broker啟動時，都會註冊到zk中，把自身的broker.id通知給zk。待zk創建此節點後，kafka會把這個broker的主機名和端口號記錄到此節點

（2）Topic註冊到zk
當broker啟動時，會到對應topic節點下註冊自己的broker.id到對應分區的isr列表中；當broker退出時，zk會自動更新其對應的topic分區的ISR列表，並決定是否需要做消費者的rebalance

（3）Consumer註冊到zk
一旦有新的消費者組註冊到zk，zk會創建專用的節點來保存相關信息。如果zk發現消費者增加或減少，會自動觸發消費者的負載均衡。
（註意，producer不註冊到zk）

消息如何被消費的？

Producer使用push模式將消息發布到broker，Consumer使用pull模式從broker訂閱並消費消息；producer通過聯系zk獲取leader角色的消息分區碼，把消息寫到leader

Producer使用push模式將消息發布到broker
+————+
| broker |
+————+
| |
\/
PULL
| |
\/
Consumer使用pull模式從broker訂閱並消費消息

1.2 卡夫卡的副本機制簡介

由於Producer和Consumer都只會與Leader角色的分區副本相連，所以kafka需要以集群的組織形式提供主題下的消息高可用。kafka支持主備復制，所以消息具備高可用和持久性。

一個分區可以有多個副本，這些副本保存在不同的broker上。每個分區的副本中都會有一個作為Leader。當一個broker失敗時，Leader在這臺broker上的分區都會變得不可用，kafka會自動移除Leader，再其他副本中選一個作為新的Leader。

在通常情況下，增加分區可以提供kafka集群的吞吐量。然而，也應該意識到集群的總分區數或是單臺服務器上的分區數過多，會增加不可用及延遲的風險。

（更正：圖中Broker1中的topic1-part1和Broker2中的topic1-part1都是從topic1-part2復制過來的,所以要改成topic1-part2 ）

1.3 卡夫卡創建副本的2種模式——同步復制和異步復制

Kafka動態維護了一個同步狀態的副本的集合（a set of In-Sync Replicas），簡稱ISR，在這個集合中的節點都是和leader保持高度一致的，任何一條消息只有被這個集合中的每個節點讀取並追加到日誌中，才會向外部通知說“這個消息已經被提交”。

只有當消息被所有的副本加入到日誌中時，才算是“committed”，只有committed的消息才會發送給consumer，這樣就不用擔心一旦leader down掉了消息會丟失。

消息從leader復制到follower, 我們可以通過決定Producer是否等待消息被提交的通知(ack)來區分同步復制和異步復制。

同步復制流程：

1.producer聯系zk識別leader

2.向leader發送消息

3.leadr收到消息寫入到本地log

4.follower從leader pull消息

5.follower向本地寫入log

6.follower向leader發送ack消息

7.leader收到所有follower的ack消息

8.leader向producer回傳ack

異步復制流程：

和同步復制的區別在於，leader寫入本地log之後，

直接向client回傳ack消息，不需要等待所有follower復制完成。

既然卡夫卡支持副本模式，那麽其中一個Broker裏的掛掉，一個新的leader就能通過ISR機制推選出來，繼續處理讀寫請求。

1.4 卡夫卡判斷一個broker節點是否存活，依據2個條件：

1.節點必須可以維護和ZooKeeper的連接，Zookeeper通過心跳機制檢查每個節點的連接。

2. 如果節點是個follower,他必須能及時的同步leader的寫操作，延時不能太久。

Leader會追蹤所有“同步中”的節點，一旦一個down掉了，或是卡住了，或是延時太久，leader就會把它移除

kafka 分區和副本以及kafaka 執行流程，以及消息的高可用