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

五柳-先生發表於2015-11-17

==是什麼 ==

 

簡單的說,Kafka是由Linkedin開發的一個分散式的訊息佇列系統(Message Queue)

 

目標Scope(解決什麼問題)

 

kafka開發的主要初衷目標是構建一個用來處理海量日誌,使用者行為和網站運營統計等的資料處理框架。在結合了資料探勘,行為分析,運營監控等需求的情況下,需要能夠滿足各種實時線上和批量離線處理應用場合對低延遲和批量吞吐效能的要求。從需求的根本上來說,高吞吐率是第一要求,其次是實時性和永續性。

 

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

 

而多數針對大資料開發應用的日誌收集處理系統(e.g. scribe, flume)則通常更適合批量離線處理場合,對實時線上處理的場合支援不夠。

 

總體而言,kafka試圖提供一個同時滿足線上和離線處理海量資料的訊息派發系統。

 

==如何實現 ==

 

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

 

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

 

核心思想

 

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

 

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

 

20130927100307765.png

 

 

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

 

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

 

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

 

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

 

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

 

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

 

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

使用Zero Copy方式在核心層直接將檔案內容傳送給網路Socket,避免應用層資料拷貝

使用合理的壓縮格式等

 

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

 

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

 

= HA =

 

kafka0.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 replicaAck,部分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

http://www.open-open.com/lib/view/open1396274536028.html

相關文章