Kafka簡介

1.概念

    Kafka是眾多MQ當中的一個，且是開源的應用廣泛的元件，是Apache的頂級專案。

Kafka是一個分散式釋出-訂閱訊息系統（放資訊取資訊）和一個強大的佇列。使用scala語言編寫，非常適合離線（不及時取）和線上（及時取）訊息消費。kafka訊息保留在磁碟上，並在叢集內複製以防止資料丟失。同時它Kafka與Flink，Spark等計算框架元件有非常好的整合，應用於實時流式資料分析。Kafka擅長收資訊、存資訊、取資訊和消費資訊，如橋樑和中轉站的角色。

2.歷史

    Kafka起源於國內的Linkedin（領英）公司。 Linkedin是一家類似於獵聘、Boss直聘的招聘和社交網站，是一家科技驅動的典型的2C公司。2C（個人）客戶的訴求是非常個性化的，想解決個性化的使用者體驗，必須去用量化資料盤點所有的資訊。這個資訊來自各個系統，要大量的採集，那麼下游消費就會遇到很多瓶頸。 起初，LinkedIn需要收集各個業務系統和應用的指標資料來進行資料分析，原先是使用“自定義開發”系統來實現，但這期間需要採集的數 據量非常大，而且內容很複雜，除需要採集作業系統的基礎指標（例如記憶體、 CPU、磁碟、網路等）外，還要採集很多和業務相關的資料指標。隨著資料量的增長，業務需求的複雜度提高，“自定義開發”系統的問題越來越多（耦合變強），效率也越來越低。於是，LinkedIn團隊開發了一個既滿足實時處理需求，又可支援水平擴充套件（分散式）的訊息系統——Kafka，它有較高的吞吐量特性。

3.優勢

    ①可靠性：分散式，分割槽，複製（多副本資料不丟）和容錯。 

    ②可擴充套件性：kafka訊息傳遞系統輕鬆縮放（加減機器數量），無需停機。 

    ③耐用性：kafka使用分散式提交日誌，這意味著訊息會盡可能快速的儲存在磁碟上，因此它是持久的。 

    ④效能：kafka對於釋出（放到佇列裡）和訂閱（消費）訊息都具有高吞吐量。即使儲存許多TB的訊息，它也爆出穩定效能。 

    kafka非常快：保證零停機和零資料丟失。

4.應用場景

1、指標分析：Kafka通常用於操作監控資料。這涉及聚合來自分散式應用程式的統計資訊，以產生運算元據的集中反饋。（實時監控看板）

2、日誌聚合解決方法：kafka可用於跨組織從多個伺服器收集日誌，並使他們以標準的合適提供方式提供給多個伺服器。 上游的資訊發給Kafka佇列，下游統一消費。如果上游壓力比較大，可以用flume來彙總。

3、流式處理：流式處理框架（spark，storm，flink）從主題中讀取資料，對其進行處理，並將處理後的資料寫入新的主題（Topic），供使用者和應用程式使用，kafka的強耐久性（即持久化即落盤）在流處理的上下文中也非常的有用（增加了資料的健壯性魯棒性）。

5.Kafka的基本概念

（1）代理（Broker）：在Kafka叢集中，一個Kafka程式（Kafka程式又稱為Kafka例項）被稱為一個代理 （Broker）節點。代理節點是訊息佇列中的常用概念，通常，在部署分散式Kafka叢集時，一臺伺服器上部署一個Kafka例項。Kafka裡面有很多很多元件，不同的代理程式，互相之間有些冗餘存放的動作，通過Zookeeper對後設資料做全域性的管控，保證所有資料是處在一致性協調下的。這裡可理解為IPO中的P。

（2）生產者（Producer）：在Kafka系統中，生產者通常被稱為Producer。Producer將訊息記錄傳送到 Kafka叢集指定的主題（Topic）中進行儲存，同時生產者（Producer）也能通過自定義演算法決定訊息記錄傳送到哪個分割槽（Partition）。 這個是人為寫程式碼干預的方式，如果相關的訊息記錄都傳送給某個Partition，那麼後續在消費的時候可以通過具象的Partition集中獲取，儘量偏於集中化處理（磁頭順序讀取比跳著讀要快得多），不要儘量打撒帶來額外的管理和協調開銷。這是一種優化的手段。 輸入的途徑是什麼？有資料庫、審計日誌（對敏感資料）、服務日誌（ 應用程式設計中隨時寫日誌列印日誌是個好習慣，其開銷對效能的影響跟後續的賦能加持來比的話是微乎其微的）、移動APP日誌、其他日誌，可以看出 訊息佇列對日誌的應用是非常廣泛的。 Topic概念可以理解為類似郵件的標題。 這裡生產者可理解為IPO中的I。

（3）消費者（Consumer）：從Kafka叢集指定的主題（Topic）中讀取訊息記錄。在讀取Topic資料時，需要設定消費者組名（GroupId），如果不設定，則Kafka消費者會預設生成一個消費組名稱。

（4）消費者組（Consumer Group）：消費者程式在讀取Kafka系統Topic中的資料時，通常會使用多個執行緒來執行。一個消費者組可以包含一個或多個消費者程式，使用多分割槽或多執行緒模式可以極大提高讀取資料的效率。 當 資訊流特別大的時候都會用分組的方式實現，是種分門別類地進行提效處理的方法。

（5）主題（Topic）：Kafka系統通過主題來區分不同業務型別的訊息記錄。

        每一個主題（Topic）中可以有一個或多個分割槽（Partition）。在Kafka系統的設計思想中，分割槽是基於物理層面上的，不同的分割槽對應不同的資料檔案。

        Kafka通過分割槽來支援物理層面上的併發讀寫，以提高Kafka叢集的吞吐量。可以理解為放不同磁碟，這樣就有多個機械手讀取資料。

        每個分割槽（Partition）內部的訊息記錄都是有序的，每個訊息都有一個連續的偏移量序號（Offset）。

        一個分割槽之對應一個代理節點（Broker），一個代理節點可以管理多個分割槽。

（6）記錄（Record）：被實際寫入到Kafka叢集並且可以被消費者應用程式讀取的資料，被稱為記錄 （Record）。每條記錄包含一個鍵（Key），值（Value）和時間戳（TimeStamp）。假如下游有10個系統要消費這個Record，那麼等10個系統都消費完，就刪掉了（訊息佇列不是永久的儲存，而只是一個臨時的Buffer）。

（7）副本數（Replication）：在Kafka系統中，每個主題（Topic）在建立時會要求指定它的副本數，預設是1（有資料丟失風險），通過副本（Replication）機制來保證Kafka分散式叢集的高可用性。

    在建立Topic時，Topic的副本系數應如下設定：

    當叢集內節點數量大於等於3，則Topic的副本系數可以設定為3；

    當叢集內節點數量小於3時，則Topic的副本系數值可以設定為小於等於叢集數量值。

    通常情況下，當叢集數量大於等於3時，為了保證叢集資料不丟失，會將副本系數設定為3。 多個副本中，只有一個是 leader ，而其他的都是 follower 副本。僅有 leader 副本可以對外提供服務， 所有的讀寫請求都是由leader 副本進行處理的。follower 副本僅有一個功能，那就是從leader 副本拉取訊息，儘量讓自己跟leader 副本的內容一致。如果follower副本也提供服務，那麼可能會出現 類似資料庫事務中的幻讀、髒讀。Leader副本掛掉後， 選擇最新的那個follower 副本作為leader。

  （8）偏移量 （Offset ）：任何釋出到此partition 的訊息都會被直接追加到log 檔案的尾部（分割槽的隊尾），每條訊息在

檔案中的位置稱為offset （偏移量），offset（增量的追加記錄） 是一個long 型別數字，它唯一標識了一條訊息，消費者通過（offset ，partition ，topic ）跟蹤記錄。 Offset本質上的設計理念是用 儘量少的後設資料表達方式，能夠讓人精準快速的找到要的那條Record。資料庫中用的是RowID（全量位置資訊記錄），行號很長佔用空間大，不擅長做大資料場景的設計。

6.Kafka訊息語義（場景）

    在Kafka中，單個代理（Broker）節點可能會出現當機，或者生產者（Producer）在向Kafka叢集的 Topic傳送訊息時出現網路故障。Kafka生產者在處理這類異常行為時會有以下幾種不同的語義。

    ①至少一次：如果在Kafka中設定ACKS=ALL，則意味著寫入的訊息至少有一條。如果生產者 （Producer）等待Kafka叢集服務端確認發生超市，或者收到服務端響應的錯誤碼，則會觸發重 試機制。若時Kafka Broker節點在傳送確認之前失敗了，但是訊息卻成功寫入到了Kafka叢集 Topic，由於失敗再次觸發重試機制導致訊息被重寫，最終導致結果不正確。可以消費側再去重。

    ②至多一次：生產者（Producer）在傳送訊息到Kafka叢集主題（Topic）時，最多允許訊息成功寫 入一次，這樣可避免資料重複。 丟了也沒辦法。

    ③精準一次：這是最符合要求的，但是也是最困難的。因為它需要訊息傳遞系統與生產者和消費者 的應用程式之間進行配合。在成功讀取一條訊息後，如果使用者將Kafka的偏移量（Offset）的值回 退到原點，則使用者會從回退的偏移量開始讀取訊息，一直讀取到最新的訊息未知。

7.Kafka架構與原理

一個典型的kafka 叢集中包含若干個Producer ，若干個Broker ，若干個Consumer ，以及一個zookeeper 叢集；kafka 通過zookeeper 管理叢集配置，選舉leader ，以及在Consumer Group 發生變化時 進行Rebalance （負載均 衡）；Producer 使

用push 模式將訊息釋出到Broker ；Consumer 使用pull 模式從Broker 中訂閱並消費訊息。