==是什麼 ==
簡單的說，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 ==
Paper論文http://research.microsoft.com/en-us/um/people/srikanth/netdb11/netdb11papers/netdb11-final12.pdf