Kafka(一)：Kafka概述

1、 簡介

Apache kafka 是一個快速、可擴展的、高吞吐的、可容錯的分佈式“發佈-訂閱”消息系統，使用Scala與Java語言編寫，能夠將消息從一個端點傳遞到另一個端點，較之傳統的消息中間件（比如ActiveMQ、RabbitMQ），kafka具有高吞吐量、內置分區、支持消息副本和高容錯的特性，非常適合大規模消息處理應用程序。
kafka官網：http://kafka.apache.org/

2、應用場景

2.1、 用戶的活動追蹤

用戶在網站的活動（網頁遊覽，搜索或其他用戶的操作信息）發佈到不同的話題中心，這些消息可實時處理，實時監測，也可加載到 Hadoop 或離線處理數據倉庫。這昌“用戶畫像”的一種實現方式

2.2、 日誌聚合

• 日誌採集客戶端在採集到日誌數據後，定時寫入 Kafka 隊列。
• Kafka 消息隊列，負責日誌數據的接收、存儲和轉發。
• 日誌處理應用從 Kafka 訂閱相應主題的日誌，當 kafka 中具有了該主題的日誌消息後會馬上發佈給日誌處理應用，由該應用消費這些日誌數據。

2.3、 限流削峯

限流削鋒也是消息隊列中的常用場景，一般在秒殺或團搶活動中使用廣泛。在秒殺活動中，爲防止流量過大而引發的系統宕機，一般需要在應用前端加入消息隊列。

3、 特性

3.1、可擴展

在不需要下線的情況下進行擴容，partition存儲在多個機器上。

3.2、持久存儲

消息直接持久化在磁盤上，並且消息還會備份到其他服務器上，防止丟失。

3.3、kafka 高吞吐率實現

Kafka 與其它 MQ 相比，其最大的特點就是高吞吐量。爲了增加存儲能力，Kafka 將所有的消息都寫入到了低速大容的硬盤。按理說，這將導致性能損失，但實際上，kafka 持超高的吞吐率，性能並未受到影響。其主要採用瞭如下的方式實現了高吞吐率。

順序讀寫

partition 的消息是順序讀寫的，這使得讀寫操作不需要硬盤磁頭的尋道時間，只需很少的扇區旋轉時間，所以速度遠快於隨機讀寫。

零拷貝

生產者、消費者對於 kafka 中消息的操作採用零拷貝實現，無需經過用戶緩存，大大提高了 IO 速度。

批量發送

Kafka 允許使用批量消息發送模式。先將消息緩存在內存中，然後再將消息批量發送出去。而發送的策略可以是緩存滿，或消息數量到達閾值，或定時發送等。批量發送大大減少了服務端的 I/O 次數。

消息壓縮

Kafka 支持對消息集合進行壓縮，以減少傳輸的消息量，減輕網絡傳輸壓力。Producer壓縮之後，Consumer 進行解壓。雖然增加了 CPU 的工作量，但在對大消息處理上，瓶頸在網絡上而不是 CPU，所以這個成本是值得的。

4、系統架構圖

5、名詞解釋

• topic（主題）

在kafka中，使用一個類別屬性來劃分消息的所屬類，劃分消息的這個類稱爲topic。它相當於消息的分類標籤，是一個邏輯概念。同一個topic的不同partition，可以分佈在不同的broker上。

對於傳統的消息隊列而言，一般會刪除已經被消費的消息，而Kafka集羣會保留所有的消息，不管消息是否被消費。但是由於受磁盤限制，不可能一直保留，所以Kafka提供了刪除舊數據的兩種策略：基於時間、基於Partition文件大小。

• partition（分區）

partition是一個物理概念，每個topic中的消息分成一個或多個分區，每個分區是一個FIFO有序的隊列，且每個分區在物理上都對應着一個文件夾，該文件夾下存儲這個分區所有消息和索引文件。但是不同的分區之間消息是無序的。如果 topic 有多個 partition，消費消息時就不能保證消息的順序。在需要嚴格保證消息的消費順序的場景下，需要將partition 數目設爲 1。一般情況下，一個 topic 的 partition 數量是 broker 的整數倍。

• segment（段）

隨着消息的快速增加，partition 會變得越來越大。這樣對於消息文件的維護以及已經被消費的消息的清理帶來嚴重的影響。爲了解決這個問題，將 partition 進一步細分爲了若干的 segment，每個 segment 文件的大小相等。這樣便於 old segment 的刪除，有利於提高磁盤的利用率。每個 partition 只需要支持對 segment 文件的順序讀寫就行。segment文件大小及生命週期可在 server.properties 配置文件中配置。

• broker

Kafka集羣包含一個或多個服務器，每個服務器節點稱爲一個broker。broker存儲topic的partition消息。broker 與 partition 間的關係如下所述：

（1）如果某 topic 有 N 個 partition，集羣有 N 個 broker，那麼每個 broker 存儲該 topic的一個 partition。
（2）如果某 topic 有 N 個 partition，集羣有(N+M)個 broker，那麼其中有 N 個 broker存儲該topic 的一個 partition，剩下的 M 個 broker 不存儲該 topic 的 partition 消息。
（3）如果某 topic 有 N 個 partition，集羣中 broker 數目少於 N 個，那麼一個 broker 存儲該 topic的一個或多個 partition。在實際生產環境中，儘量避免這種情況的發生，這種情況容易導致 Kafka 集羣消息不均衡。

• producer（生產者）

即消息的發佈者，其會將某 topic 的消息發佈到相應的 partition 中。生產者發送的消息，存儲到一個 partition 中，生產者也可以指定消息存儲的 partition。Kafka 支持消息的負載均衡，例如生產者生成了兩條消息，topic 有兩個 partition，那麼 Kafka 將在兩個partition 上分別存儲一條消息。

• consumer（消費者）

可以從 broker 中讀取消息。一個消費者可以消費多個 topic 的消息。但對於某一個 topic 的消息，消費者只會消費同一個 partition 中的消息。

• Replicas of partition（分區副本）

副本是一個分區的備份。副本不會被消費者消費，副本只用於防止消息丟失，即消費者不從爲 follower 的 partition 中消費消息，而是從爲 leader 的 partition 中讀取消息。

如上圖所示：

  topic1有4個partiion，且每個partiion有3個備份

  topic2有3個partiion，且每個partiion有2個備份

  topic3有4個partiion，且每個partiion有4個備份

• Partition Leader

每個 partition 有多個副本，其中有且僅有一個作爲 Leader，Leader 是當前負責消息讀寫的 partition。

• Partition Follower

所有寫請求都通過 Leader 路由，消息變更會廣播給所有 Follower，Follower 與 Leader保持消息同步。如果 Leader 失效，則從 Follower 中選舉出一個新的 Leader。當 Follower 卡住或者同步太慢，Leader 會把這個 Follower 從 ISR 列表（In Sync Replicas）中刪除。

注意，Partition Leader 的選舉不是由 zookeeper 完成的，而是由 Broker Controller 完成的。Leader 與 Follower 是主備關係，而非主從。

• Partition offset

分區偏移量。每條消息都有一個當前 Partition 下唯一的 64 字節的 offset，它是相對於當前分區第一條消息的偏移量。

當 consumer 從 partition 拉取了若干消息後，consumer 會將這些消息中最大的 offset 提交給 broker，表示當前 partition 已經消費到了該 offset 所標識的消息。

• Broker Controller

Kafka 集羣中多個 broker 中，有一個會被選舉爲 controller，負責管理整個集羣中partition和 replicas 的狀態。只有 Broker Controller 會向 zookeeper 中註冊 Watcher，其他 broker 無需註冊。即 zookeeper 僅需監聽 Broker Controller 的狀態變化即可。
腦裂，由假死引發的。

• ISR

ISR，In-Sync Replicas，是指副本同步列表。爲了增強 kafka 的高可用性，我們會爲partition創建副本。所有的副本統稱爲 Assigned Replicas，即 AR。初始時 leader 與所有 follower 都在ISR 列表，即初始時 ISR = AR。ISR 中的 partition 是要從 leader 同步消息的。但同步會有延遲，只要延遲超過了閾值 replica.lag.time.max.ms，就會把 follower剔除出 ISR，移入OSR(Outof-Sync Replicas)列表。即，AR = ISR + OSR。

Kafka在Zookeeper中動態維護了一個ISR（in-sync replicas） set，這個set裏的所有replica都跟上了leader，只有ISR裏的成員纔有被選爲leader的可能。

注：ISR中包括：leader和follower。

• HW 與 LEO

HW，HighWatermark，高水位，表示 Consumer 可以消費到的最高 partition 偏移量。HW保證了 Kafka 集羣中消息的一致性。

LEO，Log End Offset，日誌最後消息的偏移量。消息在 Kafka 中是被寫入到日誌文件中的，這是當前最後一個消息在 Partition 中的偏移量。

對於 Leader 中新寫入的消息，必須等待 ISR 中的所有 Follower 全部同步完畢後，HW的值纔會被更新，並寫入到 ISR 中，此時該消息才能被消費。

下圖是一張關於 HW 上漲原理的示意圖。

• consumer group

consumer group 是 kafka 提供的可擴展且具有容錯性的消費者機制。組內可以有多個消費者，它們共享一個公共的 ID，即 group ID。組內的所有消費者協調在一起來消費訂閱主題的所有分區。

組中 consumer 數量與 partition 數量的對應關係如下。

• zookeeper

用來保障分佈式應用一致性的中間件。

Zookeeper 負責維護和協調 broker。當 Kafka 系統中新增了 broker 或者某個 broker 發生故障失效時，由ZooKeeper通知Producer和Consumer。Producer和Consumer會依據Zookeeper的 broker 狀態信息與 broker 協調消息的發佈和訂閱任務。當然，zk 還負責Broker Controller的選舉。

需要注意，從 Kafka 0.9 開始 offset 的管理與保存機制發生了很大的變化——zookeeper中不再保存和管理 offset 了。

• Coordinator

Coordinator 一般指的是運行在每個 broker 上的 group Coordinator，用於管理Consumer Group 中的各個成員，主要用於 offset 位移管理和 Rebalance，可以同時管理多個消費者組。

• Rebalance

再均衡。當發生以下情況時，partition 的所有權在消費者間轉移，這個過程稱爲再均衡Rebalance。在 Rebalance 期間 broker 集羣中不可用的。所以，Kafka 無法保證 AP。
1）消費者組中新添加消費者
2）消費者關閉、崩潰或取消訂閱後離開羣組
3） 當向一個 Topic 添加新的 partition
4） 當有 broker 掛了，即有 partition 掛了

• offset commit

Consumer 在消費過消息後需要將其消費的消息的 offset 提交給 broker，以讓 broker 記錄下哪些消息是消費過的。記錄已消費過的 offset 值有什麼用呢？除了用於標識哪些消息將來要被刪除外，還有一個很重要的作用：在發生再均衡時不會引發消息的重複消費。

其實，若消費者與 broker 集羣一直處於正常運行狀態，那麼每個 partition 中記錄的offset沒什麼用處。但若發生再均衡，則在完成再均衡後，每個消費者可能分配到新的partition，而不是之前處理過的那個 partition。爲了繼續之前的工作，消費者需要讀取每個 partition 最後一次提交的 offset，然後從 offset 指定的地方繼續處理。__consumer_offset