>[info]原文地址：https://kafka.apache.org/intro.html #### **介紹** Apache Kafka是一個分布式流平臺【distributed streaming platform】。這到底是什么意思呢？ 我們認為一個流平臺有3個核心能力： 1. 它允許你發布和訂閱數據流【streams of records】。在這個方面它類似于一個消息隊列，或者像企業級消息系統。 2. 它允許你以一種可容錯的方式來存儲數據流。 3. 它允許你當數據出現時就能處理數據流。 Kafka在什么場景有優勢？ 它被用于2大類別的應用中： 1. 在系統或應用之間，構建實時流數據通道來可靠的獲取數據。 2. 構建實時流應用，來傳輸數據流，或者對數據流做出響應。 為了了解Kafka是如何做到這些的，讓我們深究下去，從底層探索Kafka的能力。 首先介紹一些概念： * Kafka作為集群運行在1個或多個服務器上。 * Kafka集群將數據流存儲在被稱為**主題**的類別中。 * 每一個數據記錄都包含一個key，一個value，和一個timestamp。 Kafka有4個核心API： [生產者API](https://kafka.apache.org/documentation.html#producerapi)：允許一個程序向一個或多個Kafka主題發布一個數據流。 [消費者API](https://kafka.apache.org/documentation.html#consumerapi)：允許一個程序訂閱一個或多個主題，并且能對產生過來的數據流進行處理。 [流API【Streams API】](https://kafka.apache.org/documentation/streams)：允許一個程序扮演一個流處理器【stream processor】，它可以從一個或多個主題中消費一個輸入流，并產生一個輸出流通向一個或多個輸出主題，有效的將輸入流轉化為輸出流。 [連接器API【Connector API】](https://kafka.apache.org/documentation.html#connect)：允許構建和運行可重用的發布者或者消費者，將Kafka主題連至已存在的應用中，或者數據系統中。比如說，一個和關系型數據庫相連的連接器，就可以捕獲一個表的每一次變化。  在Kafka中，客戶端和服務器之間的通信，使用的是一個簡單的，高性能的，語言無關的[TCP協議](https://kafka.apache.org/protocol.html)。這個協議有版本控制，并且保持對老版本的向后兼容性。我們提供了Kafka的一個Java客戶端，但是客戶端其實可以支持[多種語言](https://cwiki.apache.org/confluence/display/KAFKA/Clients)。 #### **主題和日志** 我們首先深入了解一下Kafka關于數據流的核心概念 -- 主題【topic】 一個主題標識了一個被發布的數據類別。在Kafka中，主題總是有多個訂閱者；也就是說，一個主題可以有0個，1個，或多個消費者訂閱寫入該主題中的數據。 對于每一個主題，Kafka集群都會維護一個分區日志，就像下面這樣：  每一個分區都是一個有序的，不可更改的記錄序列。它被持續的追加，是一個結構化的日志。分區中的記錄每一個都分配了一個按次序的id編號，被稱作**偏移**【offset】，它唯一指定了分區內的每一條記錄。 Kafka集群保存所有發布的數據 -- 無論它們是否被消費過 -- 使用了一個可配置的保存時長。例如，如果保存策略被設置為2天，那么在數據被發布2天內，它是可以被消費的，過了這2天，它就會被拋棄以釋放空間。Kafka關于數據大小方面的性能實際上是恒定的，所以長時間存儲數據并不是問題。  實際上，每一個消費者基本數據中僅保存元數據，即該消費者在日志中的偏移或者位置。這個偏移由消費者自己控制：按理來說，一個消費者在讀取記錄時，會線性前進它的偏移，但是，在實際情況中，由于位置是由消費者控制的，它可以以任何喜歡的順序消費數據。比如一個消費者可以重置到舊的偏移來重新處理數據，或者跳過最近的一系列數據，直接從當前數據處開始消費。 這些特性組合起來，意味著Kafka的消費者是非常廉價的 -- 他們可以來去自如，而對集群或者其它消費者并沒有太大影響。例如，你可以使用我們的命令行工具去讀取任何主題的尾部內容。而不需要更改被其他消費者已經消費過的數據。 在日志中的分區服務于多個目的。首先，它們允許日志規模擴展到超出單臺服務器的限制。而每一個單獨分區必須適合托管它的服務器，但一個主題可以有很多個分區，所以它能夠處理任意數量的數據。其次，它們扮演的是并行單元。【Second they act as the unit of parallelism—more on that in a bit.】 #### **分布式** 日志的各個分區，分布在Kafka集群的各個服務器上，每一個服務器處理數據，并請求一個共享的分區。為了實現容錯，每個分區都會擁有冗余副本，副本的數量根據可容錯的服務器數量，這個數字是可配置的。 每個分區都有一個服務器扮演“隊長”【leader】，并且0個或多個服務器扮演“追隨者”【followers】。隊長處理所有針對分區的讀取，和寫入請求，而追隨者則是被動的復制隊長行為。如果隊長宕機，其中一個追隨者將會自動變為新的隊長。每一個服務器都會為它托管的一些分區扮演隊長，而為其它服務器上的分區扮演追隨者，所以在集群中，負載被很好的均衡了。 #### **生產者** 生產者向他們選擇的主題發布數據。它負責選擇哪個記錄指派給主題內的哪個分區。這個可以用輪詢調度方式簡單的實現負載平衡。或者也可以根據一些語義分區函數（例如基于記錄中的一些key）來完成。馬上將會看到更多關于分區的使用！ #### **消費者** 消費者使用一個**消費者群組【consumer group】**名字給他們自己打標簽，每一個發布到主題的記錄，都會派發給每一個訂閱消費者群組中的一個消費者實體。消費者實體可以在不同的進程中，或者在不同的機器上。 如果所有消費者實體有相同的消費者群組，那么記錄將會在這些消費者實體中進行有效的負載均衡。 如果所有消費者實體有不同的消費者群組，那么每一個記錄都會被廣播給所有消費者進程。  一個2服務器的Kafka集群，托管4個分區（P0-P3）以及2個消費者群組，群組A有2個消費者實體，群組B有4個。 然而，更常見的，我們發現主題只有少量的消費者群組，每個“邏輯訂閱者”一個群組。為了擴展性和容錯，每個群組由多個消費者實體組成，這只是發布-訂閱語義上的概念。其中訂閱者指的是消費者集群，而不是一個單獨進程。 在Kafka中實現消費的方式，是在消費者實體上劃分日志中的分區，以實現在每一個時間點，每一個實體都是一個“公平共享”分區的獨占者。在群組中維持成員的過程由Kafka協議動態處理。如果新的實體加入群組，他們將會從群組中其它成員手上接管一些分區；如果一個實體消亡，它的分區將會分發給剩余的實體。 Kafka只提供一個分區內記錄的總順序，而不是主題中的不同分區之間。每個分區排序結合上按key進行數據分區的能力對大多數程序是足夠的。然而，如果你要求所有記錄的總順序，只有該主題僅有一個分區時才能滿足要求，但這就意味著每一個消費群組只能有一個消費者進程。 #### **保證【Guarantees】** Kafka在高層上給出如下保證： * 生產者發送給一個特定主題分區的消息，將會按照它們發送的順序進行追加。即：如果一個記錄M1和一個記錄M2都由同一個生產者發送，并且M1先發送，那么M1就會比M2擁有更小的偏移，并在日志中更早出現。 * 一個消費者實體瀏覽記錄的順序，就是記錄被存儲在日志中的順序。 * 對于一個伴隨復制因子為N的主題，我們可以最多容忍N-1個服務器宕機，不會丟失提交給日志的任何記錄。 關于這些保證的更多細節，在文檔的設計章節將會給出。 #### **Kafka作為一個消息系統** Kafka流式概念相比于一個傳統的企業級消息系統如何呢？ 傳統的消息處理有2中模型：[ 隊列](http://en.wikipedia.org/wiki/Message_queue) 和 [發布-訂閱](http://en.wikipedia.org/wiki/Message_queue)。在隊列模型中，一個消費者池可以從一個服務器讀取，并且每一條記錄都會送達至他們中的一個消費者；在發布-訂閱模型中，記錄被廣播給所有的消費者。這2種模型都有利有弊。隊列模型的優勢是，允許你根據多個消費者實體劃分數據處理，可以擴展你的處理進程。但不幸的是，隊列不是多訂閱者 -- 一旦一個處理進程讀取了數據，那么這個數據就消失了。發布-訂閱模型允許你向多個處理進程廣播數據，但是無法擴展處理進程，因為每一個消息都會送達所有的訂閱者。 在Kafka中消費者群組的概念囊括了這2種概念。作為一個隊列，消費者群組允許你根據處理者集合（消費者群組中的成員）來劃分處理。作為發布-訂閱模型，Kafka允許你將消息廣播給多個消費者群組。 >[success]自我理解：比如有6個消費者實體：A1，A2，A3，B1，B2，B3。其中A1，A2，A3消費者關注日志中的同一段數據P1段；B1，B2，B3關注日志中的另一段數據P2段。那么就可以將A1，B1打標簽為G1群組，將A2，B2打標簽為G2群組，將A3，B3打標簽為G3群組；同時將日志分區為2個區【等于群組中成員的個數】。當P1區數據到來時，Kafka就會將P1數據廣播給3個群組中的A1，A2，A3，這相當于傳統的發布-訂閱模型；并且它們3個消費者可以同時處理P1區數據，因為它們隸屬不同群組，這就相當于傳統的隊列模型。 Kafka模型的優勢是每一個主題都有這些屬性 -- 它可以擴展處理，同時也支持多個訂閱者 -- 就再沒有必要選擇這個或選擇另一個。 相比于傳統消息系統，Kafka還擁有更強的順序保證。 一個傳統的消息隊列模型，在服務器上按順序存儲記錄，如果多個消費者從這個隊列中消費，服務器將會按照數據存儲的順序來交出它們。然而，即使服務器按順序交出記錄，這些數據也是異步的傳輸給消費者，所以它們送給不同消費者的順序可能是不同的。這實際上就意味著記錄的有序性在并行消費時丟失了。消息系統通常通過“獨占消費者”的概念繞過這個問題，即允許僅一個進程在隊列上進行消費，當然了這就意味著沒有了并行處理。 Kafka做的更好。通過一個并行化的概念 -- 分區 -- 在主題內部，Kafka可以提供有序保證，以及在一個消費者進程池上的負載均衡。這是通過將主題中的分區指派給群組中的消費者達成的，以實現每一個分區僅被群組中的一個消費者消費。通過這種處理，我們確信消費者是那個分區唯一讀者，并按序消費數據。因為有很多分區，所以即使在很多消費者實體的情況下依然能負載均衡。但是要注意，消費者群組中的實體數量不能多于分區的數量。 #### **Kafka作為一個存儲系統** 任何一個允許發布消息和消費消息分離開的隊列，實際上都扮演了正在傳輸的消息的存儲系統。不同的是，Kafka是一個非常好的存儲系統。 寫入Kafka中的數據會被寫入到硬盤中，并且復制副本實現容錯。Kafka允許生產者等待確認，以便一個寫入直到完全復制，并且保證即使服務器寫入失敗也能繼續，才認為該次寫入完成。