Kafka基礎入門篇

LNMPRG原始碼研究發表於2021-10-09
Kafka

作者：王江華 地址：https://mp.weixin.qq.com/s/do...

image.png

1、kafka簡介
Kafka 是一個分散式的基於釋出/訂閱模式的訊息佇列（Message Queue），主要應用與大資料實時處理領域。其主要設計目標如下：

  • 以時間複雜度為O(1)的方式提供訊息持久化能力，即使對TB級以上資料也能保證常數時間的訪問效能
  • 高吞吐率。即使在非常廉價的機器上也能做到單機支援每秒100K條訊息的傳輸
  • 支援Kafka Server間的訊息分割槽，及分散式消費，同時保證每個partition內的訊息順序傳輸，同時支援離線資料處理和實時資料處理

2、為什麼要用訊息系統

Kafka 本質上是一個 MQ（Message Queue），使用訊息佇列的好處？

  • 解耦：允許我們獨立修改佇列兩邊的處理過程而互不影響。
  • 冗餘：有些情況下，我們在處理資料的過程會失敗造成資料丟失。訊息佇列把資料進行持久化直到它們已經被完全處理，通過這一方式規避了資料丟失風險, 確保你的資料被安全的儲存直到你使用完畢
  • 峰值處理能力：不會因為突發的流量請求導致系統崩潰，訊息佇列能夠使服務頂住突發的訪問壓力, 有助於解決生產訊息和消費訊息的處理速度不一致的情況
  • 非同步通訊：訊息佇列允許使用者把訊息放入佇列但不立即處理它, 等待後續進行消費處理。

3、kafka基礎知識

下面給出 Kafka 一些重要概念，讓大家對 Kafka 有個整體的認識和感知

  • Producer：即訊息生產者，向 Kafka Broker 發訊息的客戶端。
  • Consumer：即訊息消費者，從 Kafka Broker 讀訊息的客戶端。
  • Consumer Group：即消費者組，消費者組內每個消費者負責消費不同分割槽的資料，以提高消費能力。一個分割槽只能由組內一個消費者消費，不同消費者組之間互不影響。
  • Broker：一臺 Kafka 機器就是一個 Broker。一個叢集是由多個 Broker 組成的且一個 Broker 可以容納多個 Topic。
  • Topic：可以簡單理解為佇列，Topic 將訊息分類，生產者和消費者面向的都是同一個 Topic。
  • Partition：為了實現Topic擴充套件性，提高併發能力，一個非常大的 Topic 可以分佈到多個 Broker 上，一個 Topic 可以分為多個 Partition 進行儲存，每個 Partition 是一個有序的佇列。
  • Replica：即副本，為實現資料備份的功能，保證叢集中的某個節點發生故障時，該節點上的 Partition 資料不丟失，且 Kafka 仍然能夠繼續工作，為此Kafka提供了副本機制，一個 Topic 的每個 Partition 都有若干個副本，一個 Leader 副本和若干個 Follower 副本。
  • Leader：即每個分割槽多個副本的主副本，生產者傳送資料的物件，以及消費者消費資料的物件，都是 Leader。
  • Follower：即每個分割槽多個副本的從副本，會實時從 Leader 副本中同步資料，並保持和 Leader 資料的同步。Leader 發生故障時，某個 Follower 還會被選舉併成為新的 Leader , 且不能跟 Leader 在同一個broker上, 防止崩潰資料可恢復。
  • Offset：消費者消費的位置資訊，監控資料消費到什麼位置，當消費者掛掉再重新恢復的時候，可以從消費位置繼續消費。
  • ZooKeeper服務：Kafka 叢集能夠正常工作，需要依賴於 ZooKeeper，ZooKeeper 幫助 Kafka 儲存和管理叢集後設資料資訊。在最新版本中, 已經慢慢要脫離 ZooKeeper。

image.png

image.png

4、kafka叢集架構

4.1 工作流程

在瞭解kafka叢集之前, 我們先來了解下kafka的工作流程, Kafka叢集會將訊息流儲存在 Topic 的中，每條記錄會由一個Key、一個Value和一個時間戳組成。
image.png

Kafka 中訊息是以 Topic 進行分類的，生產者生產訊息，消費者消費訊息，讀取和消費的都是同一個 Topic。但是Topic 是邏輯上的概念， Partition 是物理上的概念，每個 Partition 對應一個 log 檔案，該 log 檔案中儲存的就是 Producer 生產的資料。Producer 端生產的資料會不斷順序追加到該 log 檔案末尾，並且每條資料都會記錄有自己的 Offset。 而消費者組中的每個消費者，也都會實時記錄當前自己消費到了哪個 Offset，方便在崩潰恢復時，可以繼續從上次的 Offset 位置消費。

4.2儲存機制

image.png

此時 Producer 端生產的訊息會不斷追加到 log 檔案末尾，這樣檔案就會越來越大, 為了防止 log 檔案過大導致資料定位效率低下，那麼Kafka 採取了分片和索引機制。它將每個 Partition 分為多個 Segment，每個 Segment 對應4個檔案：“.index” 索引檔案, “.log” 資料檔案, “.snapshot” 快照檔案, “.timeindex” 時間索引檔案。這些檔案都位於同一資料夾下面，該資料夾的命名規則為：topic 名稱-分割槽號。例如, heartbeat心跳上報服務 這個 topic 有三個分割槽，則其對應的資料夾為 heartbeat-0，heartbeat-1，heartbeat-2這樣。
image.png

index, log, snapshot, timeindex 檔案以當前 Segment 的第一條訊息的 Offset 命名。其中 “.index” 檔案儲存大量的索引資訊，“.log” 檔案儲存大量的資料，索引檔案中的後設資料指向對應資料檔案中 Message 的物理偏移量。

下圖為index 檔案和 log 檔案的結構示意圖：
image.png

4.3 Replica - 副本

kafka中的 Partition 為了保證資料安全，每個 Partition 可以設定多個副本。此時我們對分割槽0,1,2分別設定3個副本（注:設定兩個副本是比較合適的）。而且每個副本都是有"角色"之分的，它們會選取一個副本作為 Leader 副本，而其他的作為 Follower 副本，我們的 Producer 端在傳送資料的時候，只能傳送到Leader Partition裡面 ，然後Follower Partition會去Leader那自行同步資料, Consumer 消費資料的時候，也只能從 Leader 副本那去消費資料的。
image.png
image.png

4.4 Controller

Kafka Controller，其實就是一個 Kafka 叢集中一臺 Broker，它除了具有普通Broker 的訊息傳送、消費、同步功能之外，還需承擔一些額外的工作。Kafka 使用公平競選的方式來確定 Controller ，最先在 ZooKeeper 成功建立臨時節點 /controller 的Broker會成為 Controller ，一般而言，Kafka叢集中第一臺啟動的 Broker 會成為Controller，並將自身 Broker 編號等資訊寫入ZooKeeper臨時節點/controller。

4.5 Offset 的維護

Consumer 在消費過程中可能會出現斷電當機等故障，在 Consumer 恢復後，需要從故障前的 Offset 位置繼續消費。所以 Consumer 需要實時記錄自己消費到了哪個 Offset，以便故障恢復後繼續消費。在 Kafka 0.9 版本之前，Consumer 預設將 Offset 儲存在 ZooKeeper 中，但是從 0.9 版本開始，Consumer 預設將 Offset 儲存在 Kafka 一個內建的 Topic 中，該 Topic 為 __consumer_offsets, 以支援高併發的讀寫。

4、總結

上面和大家一起深入探討了 Kafka 的簡介, 基礎知識和叢集架構，下一篇會從Kafka 三高(高效能, 高可用, 高併發)方面來詳細闡述其巧妙的設計思想。 大家期待.....

相關文章