快速理解Kafka分佈式消息隊列框架

轉載自：http://blog.csdn.net/colorant/article/details/12081909

==是什麼 ==

 

簡單的說，Kafka是由Linkedin開發的一個分佈式的消息隊列系統(Message Queue)

 

目標Scope（解決什麼問題）

 

kafka開發的主要初衷目標是構建一個用來處理海量日誌，用戶行爲和網站運營統計等的數據處理框架。在結合了數據挖掘，行爲分析，運營監控等需求的狀況下，須要可以知足各類實時在線和批量離線處理應用場合對低延遲和批量吞吐性能的要求。從需求的根本上來講，高吞吐率是第一要求，其次是實時性和持久性。

 

既有的消息隊列框架或者對消息傳送的可靠性提供了較高的保證，由此帶來較大的負擔，不能知足海量高吞吐率的要求；或者徹底面向實時消息處理系統，對於批量離線處理的場合沒法提供足夠的緩存和持久性要求。

 

而多數針對大數據開發應用的日誌收集處理系統(e.g. scribe, flume)則一般更適合批量離線處理場合，對實時在線處理的場合支持不夠。

 

整體而言，kafka試圖提供一個同時知足在線和離線處理海量數據的消息派發系統。

 

==如何實現 ==

 

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 ==

 

項目主頁http://kafka.apache.org/

Paper論文http://research.microsoft.com/en-us/um/people/srikanth/netdb11/netdb11papers/netdb11-final12.pdf