1、簡介

　　kafka是用於構建實時資料管道和資料流的應用程式。具有實時橫向擴充套件、高吞吐量、支援大量堆積具有容錯性和速度快等特點。它是一個高效能分散式訊息系統。通常一個分散式流資料平臺它具有三個特點：

1. 釋出和訂閱功能，類似於訊息系統
2. 以容錯的方式記錄流
3. 處理流

Kafka通常用於構建在系統或應用之間的實時資料流管道、構建實時流應用程式用於轉換和響應資料流。

1.1 簡介

　　kafka對訊息儲存時根據Topic進行歸類，傳送訊息者成為Producer,訊息接受者成為Consumer,此外kafka叢集有多個kafka例項組成，每個例項server成為broker。無論是kafka叢集，還是producer和consumer都依賴於zookeeper來保證系統可用性叢集儲存一些meta資訊。

1. 同時為釋出和訂閱提供高吞吐量。據瞭解，Kafka每秒可以生產約25萬訊息（50 MB），每秒處理55萬訊息（110 MB）。
2. 可進行持久化操作。將訊息持久化到磁碟，因此可用於批量消費，例如ETL，以及實時應用程式。通過將資料持久化到硬碟以及複製防止資料丟失。
3. 分散式系統，易於向外擴充套件。所有的生產者和消費者都會有多個，均為分散式的。無需停機即可擴充套件機器。
4. 訊息被處理的狀態是在消費端維護，而不是由伺服器端維護。當失敗時能自動平衡。
5. 支援線上和離線的場景。

1.2 基本概念

　　主題（topic）：就是訊息的分類，生產者將訊息傳送到特定主題，消費者訂閱該主題或者主題的分割槽來進行消費。

　　訊息：就是資料，一個固定長度的訊息頭和一個可變長度的訊息體組成。

　　分割槽和副本：一個主題可以分成多個分割槽，每個分割槽由一系列有序、不可變的訊息組成，是一個有序佇列。每個分割槽在物理上對應一個資料夾，分割槽的命名規則為主題名稱後接“-”連線符，之後再接分割槽編號，分割槽編號從0開始，表示第一個分割槽。如下圖主題3有2個分割槽，編號0、1；

　　每個分割槽中只有一個副本對外提供服務，可以看到上圖的Leader標示的那樣。我們通過zookeeper檢視，如下圖：

欄位的含義：

Leader副本和Follower副本：同一個分割槽的多個副本目的就是為了冗餘提高可用性，所以就必須保證副本的一致性，那麼Kafka會選擇分割槽內的一個副本作為Leader副本，而其他副本作為Follower副本，只有Leader副本處理讀寫請求。Follower副本只是從Leader上覆制資料。

偏移量：釋出到分割槽的訊息會追加到日誌檔案的尾部，每條訊息在日誌檔案中的位置都會對應一個按序遞增的偏移量。不過偏移量不表示訊息在磁碟上的位置，而且kafka幾乎不允許對訊息進行隨機讀寫，消費者可以指定偏移量的的起始位置進行消費。

日誌段：日誌又被劃分為多個日誌段，日誌段是kafka日誌物件分片的最小單位。與日誌物件一樣，日誌段也是邏輯概念。一個日誌段對應磁碟上一個具體日誌檔案和兩個索引檔案，日誌以.log結尾，兩個索引以.index和.timeindex結尾，表示訊息偏移量索引檔案和訊息時間戳索引檔案。

代理：其實就是Kafka服務，一個Kafka服務叫做一個例項，也就是一個代理。一個叢集通常包含多臺代理，每個代理有一個非負整數的id，且在整個叢集中id值是唯一的。

生產者：也就是傳送訊息的客戶端

消費者和消費者組：消費者通過拉的方式獲取資料，每一個消費者都屬於一個消費者組，我們可以為每個消費者指定一個組。如果不指定則屬於預設消費者組test-consumer-group。同時每個消費者也有一個唯一id，如果沒有指定則kafka會為其自動生成一個。同一個主題的訊息只能被消費者組中的一個消費者訊息，但不同消費者組中的消費者可以消費這條訊息。

ISR：Kafka在Zookeeper中動態維護一個ISR，也就是儲存同步的副本列表，該列表中儲存的是與Leader副本保持訊息同步的所有副本對應的代理節點id。如果一個Follower宕機或者其落後太多，則該Follower副本節點將從ISR列表中移除。

1.3 Topics/logs

　　一個Topic可以認為是一類訊息，每個topic將被分成多個partition(區),每個partition在儲存層面是append log檔案。任何釋出到此partition的訊息都會被直接追加到log檔案的尾部，每條訊息在檔案中的位置稱為offset（偏移量），offset為一個long型數字，它是唯一標記一條訊息。它唯一的標記一條訊息。

1.４ 在kafka中為什麼幾乎不允許對訊息進行“隨機讀寫”

　　原因：每條訊息在檔案中的位置稱為offset（偏移量），offset為一個long型數字。kafka並沒有提供其他額外的索引機制來儲存offset。
　　kafka和JMS（Java Message Service）實現(activeMQ)不同的是:即使訊息被消費,訊息仍然不會被立即刪除。日誌檔案將會根據broker中的配置要求,保留一定的時間之後刪除;比如log檔案保留2天,那麼兩天後,檔案會被清除,無論其中的訊息是否被消費.kafka通過這種簡單的手段,來釋放磁碟空間,以及減少訊息消費之後對檔案內容改動的磁碟IO開支.
　　對於consumer而言,它需要儲存消費訊息的offset,對於offset的儲存和使用,有consumer來控制;當consumer正常消費訊息時,offset將會”線性”的向前驅動,即訊息將依次順序被消費.事實上consumer可以使用任意順序消費訊息,它只需要將offset重置為任意值。
　　partitions的設計目的有多個.最根本原因是kafka基於檔案儲存.通過分割槽,可以將日誌內容分散到多個server上,來避免檔案尺寸達到單機磁碟的上限,每個partiton都會被當前server(kafka例項)儲存;可以將一個topic切分多任意多個partitions,來訊息儲存/消費的效率.此外越多的partitions意味著可以容納更多的consumer,有效提升併發消費的能力.

1.５ Distribution

　　一個Topic的多個partitions,被分佈在kafka叢集中的多個server上;每個server(kafka例項)負責partitions中訊息的讀寫操作;此外kafka還可以配置partitions需要備份的個數(replicas),每個partition將會被備份到多臺機器上,以提高可用性.
　　基於replicated方案,那麼就意味著需要對多個備份進行排程;每個partition都有一個server為”leader”;leader負責所有的讀寫操作,如果leader失效,那麼將會有其他follower來接管(成為新的leader);follower只是單調的和leader跟進,同步訊息即可..由此可見作為leader的server承載了全部的請求壓力,因此從叢集的整體考慮,有多少個partitions就意味著有多少個”leader”,kafka會將”leader”均衡的分散在每個例項上,來確保整體的效能穩定.

Producers
　　Producer將訊息釋出到指定的Topic中,同時Producer也能決定將此訊息歸屬於哪個partition;比如基於”round-robin”方式或者通過其他的一些演算法等.

Consumers
　　本質上kafka只支援Topic.每個consumer屬於一個consumer group;反過來說,每個group中可以有多個consumer.傳送到Topic的訊息,只會被訂閱此Topic的每個group中的一個consumer消費.
　　如果所有的consumer都具有相同的group,這種情況和queue模式很像;訊息將會在consumers之間負載均衡.
　　如果所有的consumer都具有不同的group,那這就是”釋出-訂閱”;訊息將會廣播給所有的消費者.
　　在kafka中,一個partition中的訊息只會被group中的一個consumer消費;每個group中consumer訊息消費互相獨立;我們可以認為一個group是一個”訂閱”者,一個Topic中的每個partions,只會被一個”訂閱者”中的一個consumer消費,不過一個consumer可以消費多個partitions中的訊息.kafka只能保證一個partition中的訊息被某個consumer消費時,訊息是順序的.事實上,從Topic角度來說,訊息仍不是有序的.
　　kafka的設計原理決定,對於一個topic,同一個group中不能有多於partitions個數的consumer同時消費,否則將意味著某些consumer將無法得到訊息.

Guarantees

　　1) 傳送到partitions中的訊息將會按照它接收的順序追加到日誌中

　　2) 對於消費者而言,它們消費訊息的順序和日誌中訊息順序一致.

　　3) 如果Topic的”replicationfactor”為N,那麼允許N-1個kafka例項失效.