快速理解Kafka分布式訊息佇列框架

==是什麼==

簡單的說，kafka是由linkedin開發的乙個分布式的訊息佇列系統(message queue)

目標scope（解決什麼問題）

既有的訊息佇列框架或者對訊息傳送的可靠性提供了較高的保證，由此帶來較大的負擔，不能滿足海量高吞吐率的要求；或者完全面向實時訊息處理系統，對於批量離線處理的場合無法提供足夠的快取和永續性要求。

==如何實現==

kafka的集群有多個broker伺服器組成，每個型別的訊息被定義為topic，同一topic內部的訊息按照一定的key和演算法被分割槽(partition)儲存在不同的broker上，訊息生產者producer和消費者consumer可以在多個broker上生產/消費topic

核心思想

以高效率作為第一設計原則，kafka的結構設計在很多方面都做了激進的取捨。

=極簡的資料結構和應用模式 =

訊息佇列是以log檔案的形式儲存，訊息生產者只能將訊息新增到既有的檔案尾部，沒有任何id資訊用於訊息的定位，完全依靠檔案內的位移，因此訊息的使用者只能依靠檔案位移順序讀取訊息，這樣也就不需要維護複雜的支援隨即讀取的索引結構。

kafka broker完全不維護和協調多使用者使用訊息的行為模式，使用者自己維護位移用來索引訊息。

最小的併發訪問單位就是partition分割槽，同一使用者組內的所有使用者（可以理解為同乙個應用的所有併發程序）只能有乙個訪問同一分割槽，同時分割槽的個數是固定的，不支援動態調整。這樣最大簡化了多程序/分布式client之間對訊息處理訪問的併發控制的複雜度，當然也帶來一定的使用模式上的限制（比如最大併發度完全取決於預先規劃的partition的個數）

此外分割槽也帶來乙個問題就是訊息只是分割槽內部有序而不是全域性有序的。如果需要全域性有序，應用需要自己靠別的機制來保證。

使用pull模式派發訊息，訊息的使用情況，比如是否還有consumer沒有讀取，是否重複讀取(改進中)等，在broker端也完全不跟蹤維護，訊息的過期處理簡單的由定時器定時刪除（比如保留7天），由此簡化各種訊息跟蹤維護的開銷。

=採取各種方式最大化資料傳輸效率 =

比如生產者和消費者可以批量讀寫訊息減少rpc開銷

使用zero copy方式在核心層直接將檔案內容傳送給網路socket，避免應用層資料拷貝

使用合理的壓縮格式等

=激進的記憶體管理模式 =

基本的意思就是不管理。。。kafka不在jvm程序內部維護訊息cache，訊息直接從檔案中讀寫，完全依賴作業系統在檔案系統層面的cache，避免在jvm中管理cache帶來的額外資料結構開銷和gc帶來的效能代價。基於批量處理和順序讀寫的應用模式，最大化利用檔案系統的cache機制和規避檔案讀寫相對記憶體讀寫的效能代價。

= ha =

kafka在0.8之前message是沒有備份容錯機制的，producer的工作模式是fire and forget，如果乙個broker失效，那麼相關topic分割槽的相關訊息也就丟失了。這種設計的原因在於最初的應用模式，如日誌/使用者行為等訊息的處理，對資料的健壯性方面要求不高，可以容忍部分資料的缺失。採用fire and forget 模式，不需要等待broker ack，有利於提高producer的吞吐率。

不過在0.8版本中，新增了資料replica的機制，乙個訊息分割槽的多個replica分布在不同的broker上，由leader replica負責日常讀寫，通過zookeeper監督failover，不同的分割槽的leader replica均衡負載到不同的broker上。在這種情況下，producer可以選擇不等待leader replica的ack，部分ack，或者完全備份完畢後ack等不同的ack機制。這三種機制，效能依次遞減 (producer吞吐量降低1-3倍)，資料健壯性則依次遞增。

== links ==

專案主頁

*******

快速理解Kafka分布式訊息佇列框架

快速理解Kafka分布式訊息佇列框架

快速理解Kafka分布式訊息佇列框架

Kafka分布式訊息系統

相關推薦