本文介紹linkedin開源的kafka，久仰大名了，按照其官方文檔做些翻譯和二次創作。對應可以檢視整份官方文檔。
topics，維護的消息源種類（更像是業務上的資料種類/分類）
producer，給kafka的某個topic釋出消息的程序
consumer，訂閱和處理topic的消息的程序
broker，組成kafka叢集的server
kafka為每個topic維護了如下一份被分區了的log
每份log有序，不可變，不斷被append。分區中的消息會被配置設定一個有序的id，稱為offset。
kafka内保留的消息是有時間限制的，超出設定的時間段的話，消息就不保留了。kafka的性能與資料容量是成正比的。
offset能友善consumer來取資料，自由度比較大（或者說這種緩存性質的消息隊列，友善消費者讀取一定視窗内的消息，也算一種回放功能吧）。
分區一方面是為了增大消息的容量（可以分布在多個分區上存，而不會限制在單台機器存儲大小裡），二方面可以類似看成一種并行度。
partitition分布在不同機器上，且可以設定備份數以達到容錯。
每份partition都有一個扮演leader角色的server和幾個扮演follower角色的server。leader來負責對這份分區的讀寫請求。
follower被動複制leader動作。leader挂了的話會有follower自動成為新的leader。
各個server都會各自扮演某份分區的leader和其他幾份分區的followe，如此的話整個叢集上的機器相對負載比較好些。
生産者選擇釋出資料給topic，負責選擇topic的哪個partition，把消息寫進去。
選擇方法和政策有多種。
傳統的消息模型有兩種模型，隊列模型和釋出-訂閱模式。
1. 隊列形式中，一群消費者可能從server那邊讀消息，而每條消息會流向他們中的一個。
2. 釋出-訂閱模式中，消息會廣播到所有它的消費者們那。
kafka是使用consumer group這個概念（下面把它翻譯為"消費組"），把兩者結合了。。
消費者給自己标志了一個消費組名，每條新釋出到topic的消息會被傳遞給訂閱它的消費組裡的消費者執行個體，這些消費者執行個體可以是不同的程序，存在在不同的機器上。
如果所有的消費者在同一個消費組裡，那麼這相當于是一個隊列模型的場景。
如果所有的消費者都屬于不同的消費組，那麼這相當于是一個釋出-訂閱模式的場景，所有消息會廣播到所有消費者們。
下圖展示的是兩台server組成的kafka叢集，共4個分區，兩個消費組，a、b消費組各有2個、4個消費者，他們對應訂閱了不同的分區。
此外，kafka比傳統的消息系統具備更強的有序性保證。下面會展開說明。
傳統的隊列形式的消息系統，在server端是有序儲存着消息的。但當有多個消費者來并發取queue裡的消息的時候，由于每個queue裡的消息是異步輸送給消費者，雖然輸出是有序的（隊列裡排好隊輸出的），當消息到達消費者那頭的時候，就不保證順序了。如果單個消費者來取，可以保證有序，某些中庸的解決辦法還是會喪失一定并行度。
kafka是怎麼做到更好的并行且有序的呢？kafkad的"分區"其實是一種并行度的概念，即在topic内，kafka的消費者程序池能得到有序性保證和負載均衡。這是因為在topic内設定了多個分區，使得topic對應的消費組裡的消費者們各自可以獨享一個分區。如此的話，每個消費者是其消費的分區的唯一reader，在單個reader下當然保證了有序這件事。而且多個分區也使得負載可以比較平衡。需要注意的是，消費者不能比分區數多。
kafka能保證的幾件事情，
1. 生産者向topic分區發來的消息能按序添加進來。即先送來的消息在log裡面有更小的offset。
2. 消費者執行個體能在log裡（第一張圖裡）看到有序的消息。
3. 一個擁有n個分區的topic，系統能容忍n-1台server失敗，而不丢失寫到了log裡的消息資料。
更多設計上的内容不在這裡闡述。
kafka作為消息隊列，優勢在更好的吞吐，内置分區，副本數，容錯這幾個特性，是以适合大規模消息處理應用。
mq有很多，就不具體比較了。
kafka原本的一個應用場景，就是跟蹤使用者浏覽頁面、搜尋及其他行為，以釋出-訂閱的模式實時記錄到對應的topic裡。
那麼這些結果被訂閱者拿到後，就可以做進一步的實時處理，或實時監控，或放到hadoop/離線資料倉庫裡處理。
行為追蹤經常會有很大的吞吐量。
作為操作記錄的監控子產品來使用，即彙集記錄一些操作資訊，可以了解為運維性質的資料監控吧。
日志收集方面，其實開源産品有很多，包括scribe、apache flume。如果談kafka的優勢的話，其實還是離不開他的容錯、高吞吐性能方面的設計層面的特點吧。具體就不分析了。
參考我之前寫的分布式日志收集系統apache flume的設計介紹
這個場景可能比較多，也很好了解。儲存收集流資料，以提供之後對接的storm或其他流式計算架構進行處理。
為分布式系統的一些commit log（記錄檔）做容錯意義的備份，我是這麼了解的，類似于hdfsnamenode的log。對比bookkeeper，其實就是做這件事的。bookkeeper在hadoop hdfs namenode ha方案裡，用于記錄namenode的記錄檔(一時想不起叫什麼log了，反正不記錄namenode的image資料)。
參考我之前寫的bookkeeper設計介紹及其在hadoop2.0 namenode ha方案中的使用分析
全文完 :)