【轉】KAFKA分布式訊息系統

標籤：

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

 

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

 

註：本文中發行者（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的訂閱Server Load Balancer。

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. 串流應用

原文連結：http://blog.chinaunix.net/uid-20196318-id-2420884.html

【轉】KAFKA分布式訊息系統