Kafka[1]是linkedin用於日誌處理的分散式訊息佇列，linkedin的日誌資料容量大，但對可靠性要求不高，其日誌資料主要包括使用者行為（登入、瀏覽、點選、分享、喜歡）以及系統執行日誌（CPU、記憶體、磁碟、網路、系統及程序狀態）。

當前很多的訊息佇列服務提供可靠交付保證，並預設是即時消費（不適合離線）。高可靠交付對linkedin的日誌不是必須的，故可通過降低可靠性來提高效能，同時通過構建分散式的叢集，允許訊息在系統中累積，使得kafka同時支援離線和線上日誌處理。

注：本文中釋出者（publisher）與生產者（producer）可以互換，訂閱者（subscriber）與消費者（consumer）可以互換。

Kafka的架構如下圖所示：

Kafka儲存策略

1.kafka以topic來進行訊息管理，每個topic包含多個part（ition），每個part對應一個邏輯log，有多個segment組成。

2.每個segment中儲存多條訊息（見下圖），訊息id由其邏輯位置決定，即從訊息id可直接定位到訊息的儲存位置，避免id到位置的額外對映。

3.每個part在記憶體中對應一個index，記錄每個segment中的第一條訊息偏移。

4.釋出者發到某個topic的訊息會被均勻的分佈到多個part上（隨機或根據使用者指定的回撥函式進行分佈），broker收到釋出訊息往對應part的最後一個segment上新增該訊息，當某個segment上的訊息條數達到配置值或訊息釋出時間超過閾值時，segment上的訊息會被flush到磁碟，只有flush到磁碟上的訊息訂閱者才能訂閱到，segment達到一定的大小後將不會再往該segment寫資料，broker會建立新的segment。

釋出與訂閱介面

釋出訊息時，kafka client先構造一條訊息，將訊息加入到訊息集set中（kafka支援批量釋出，可以往訊息集合中新增多條訊息，一次行釋出），send訊息時，client需指定訊息所屬的topic。

訂閱訊息時，kafka client需指定topic以及partition num（每個partition對應一個邏輯日誌流，如topic代表某個產品線，partition代表產品線的日誌按天切分的結果），client訂閱後，就可迭代讀取訊息，如果沒有訊息，client會阻塞直到有新的訊息釋出。consumer可以累積確認接收到的訊息，當其確認了某個offset的訊息，意味著之前的訊息也都已成功接收到，此時broker會更新zookeeper上地offset registry（後面會講到）。

高效的資料傳輸

1.釋出者每次可釋出多條訊息（將訊息加到一個訊息集合中釋出）， sub每次迭代一條訊息。

2.不建立單獨的cache，使用系統的page cache。釋出者順序釋出，訂閱者通常比釋出者滯後一點點，直接使用linux的page cache效果也比較後，同時減少了cache管理及垃圾收集的開銷。

3.使用sendfile優化網路傳輸，減少一次記憶體拷貝。

無狀態broker

1.Broker沒有副本機制，一旦broker宕機，該broker的訊息將都不可用。

2.Broker不儲存訂閱者的狀態，由訂閱者自己儲存。

3.無狀態導致訊息的刪除成為難題（可能刪除的訊息正在被訂閱），kafka採用基於時間的SLA(服務水平保證)，訊息儲存一定時間（通常為7天）後會被刪除。

4.訊息訂閱者可以rewind back到任意位置重新進行消費，當訂閱者故障時，可以選擇最小的offset進行重新讀取消費訊息。

Consumer group

1.允許consumer group（包含多個consumer，如一個叢集同時消費）對一個topic進行消費，不同的consumer group之間獨立訂閱。

2.為了對減小一個consumer group中不同consumer之間的分散式協調開銷，指定partition為最小的並行消費單位，即一個group內的consumer只能消費不同的partition。

Zookeeper 協調控制

1.管理broker與consumer的動態加入與離開。

2.觸發負載均衡，當broker或consumer加入或離開時會觸發負載均衡演算法，使得一

   個consumer group內的多個consumer的訂閱負載平衡。

3.維護消費關係及每個partion的消費資訊。

Zookeeper上的細節：

1.每個broker啟動後會在zookeeper上註冊一個臨時的broker registry，包含broker的ip地址和埠號，所儲存的topics和partitions資訊。

2.每個consumer啟動後會在zookeeper上註冊一個臨時的consumer registry：包含consumer所屬的consumer group以及訂閱的topics。

3.每個consumer group關聯一個臨時的owner registry和一個持久的offset registry。對於被訂閱的每個partition包含一個owner registry，內容為訂閱這個partition的consumer id；同時包含一個offset registry，內容為上一次訂閱的offset。

訊息交付保證

1.kafka對訊息的重複、丟失、錯誤以及順序型沒有嚴格的要求。

2.kafka提供at-least-once delivery,即當consumer宕機後，有些訊息可能會被重複delivery。

3.因每個partition只會被consumer group內的一個consumer消費，故kafka保證每個partition內的訊息會被順序的訂閱。

4.Kafka為每條訊息為每條訊息計算CRC校驗，用於錯誤檢測，crc校驗不通過的訊息會直接被丟棄掉。

Linkedin的應用環境

如下圖，左邊的應用於日誌資料的線上實時處理，右邊的應用於日誌資料的離線分析（現將日誌pull至hadoop或DWH中）。

Kafka的效能

測試環境： 2 Linux machines, each with 8 2GHz cores,  16GB  of  memory,  6  disks  with  RAID  10.  The  two machines  are  connected  with  a  1Gb  network link.  One  of  the machines was used as the broker and the other machine was used as the producer or the consumer.

測試評價(by me)：（1）環境過於簡單，不足以說明問題。（2）對於producer持續的波動沒有進行分析。（3）只有兩臺機器zookeeper都省了？？

測試結果：如下圖，完勝其他的message queue，單條訊息傳送（每條200bytes）,能到50000messages/sec，50條batch方式傳送，平均為400000messages/sec.

Kafka未來研究方向

1. 資料壓縮（節省網路頻寬及儲存空間）

2. Broker多副本

3. 流式處理應用

參考資料