轉自：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 ==
Paper論文http://research.microsoft.com/en-us/um/people/srikanth/netdb11/netdb11papers/netdb11-final12.pdf