本文介紹LinkedIn開源的Kafka，久仰大名了，依照其官方文檔做些翻譯和二次創作。相應能夠查看整份官方文檔。

基本術語

topics。維護的消息源種類（更像是業務上的數據種類/分類）

producer。給kafka的某個topic公布消息的進程

consumer，訂閱和處理topic的消息的進程

broker。組成kafka集群的server

Topic和日誌

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

為分布式系統的一些commit log（操作日誌）做容錯意義的備份，我是這麽理解的，類似於HDFSnamenode的log。對照BookKeeper，事實上就是做這件事的。

BookKeeper在Hadoop HDFS Namenode HA方案裏，用於記錄namenode的操作日誌(一時想不起叫什麽log了，反正不記錄namenode的image數據)。

全文完 :)

Kafka介紹