Kafka架構原理，也就這麼回事

【51CTO.com原創稿件】本文主要講解 Kafka 是什麼、Kafka 的架構包括工作流程和存儲機制，以及生產者和消費者。

圖片來自 Pexels

最終大家會掌握 Kafka 中最重要的概念，分別是 Broker、Producer、Consumer、Consumer Group、Topic、Partition、Replica、Leader、Follower，這是學會和理解 Kafka 的基礎和必備內容。

定義

Kafka 是一個分佈式的基於發佈/訂閱模式的消息隊列(Message Queue)，主要應用與大數據實時處理領域。

消息隊列

Kafka 本質上是一個 MQ(Message Queue)，使用消息隊列的好處?(面試會問)

• 解耦：允許我們獨立的擴展或修改隊列兩邊的處理過程。
• 可恢復性：即使一個處理消息的進程掛掉，加入隊列中的消息仍然可以在系統恢復後被處理。
• 緩衝：有助於解決生產消息和消費消息的處理速度不一致的情況。
• 靈活性&峰值處理能力：不會因為突發的超負荷的請求而完全崩潰，消息隊列能夠使關鍵組件頂住突發的訪問壓力。
• 異步通信：消息隊列允許用戶把消息放入隊列但不立即處理它。

發佈/訂閱模式

一對多，生產者將消息發佈到 Topic 中，有多個消費者訂閱該主題，發佈到 Topic 的消息會被所有訂閱者消費，被消費的數據不會立即從 Topic 清除。

架構

Kafka 存儲的消息來自任意多被稱為 Producer 生產者的進程。數據從而可以被髮布到不同的 Topic 主題下的不同 Partition 分區。

在一個分區內，這些消息被索引並連同時間戳存儲在一起。其它被稱為 Consumer 消費者的進程可以從分區訂閱消息。

Kafka 運行在一個由一臺或多臺服務器組成的集群上，並且分區可以跨集群結點分佈。

下面給出 Kafka 一些重要概念，讓大家對 Kafka 有個整體的認識和感知，後面還會詳細的解析每一個概念的作用以及更深入的原理：

• Producer： 消息生產者，向 Kafka Broker 發消息的客戶端。
• Consumer：消息消費者，從 Kafka Broker 取消息的客戶端。
• Consumer Group：消費者組(CG)，消費者組內每個消費者負責消費不同分區的數據，提高消費能力。一個分區只能由組內一個消費者消費，消費者組之間互不影響。所有的消費者都屬於某個消費者組，即消費者組是邏輯上的一個訂閱者。
• Broker：一臺 Kafka 機器就是一個 Broker。一個集群由多個 Broker 組成。一個 Broker 可以容納多個 Topic。
• Topic：可以理解為一個隊列，Topic 將消息分類，生產者和消費者面向的是同一個 Topic。
• Partition：為了實現擴展性，提高併發能力，一個非常大的 Topic 可以分佈到多個 Broker (即服務器)上，一個 Topic 可以分為多個 Partition，每個 Partition 是一個 有序的隊列。
• Replica：副本，為實現備份的功能，保證集群中的某個節點發生故障時，該節點上的 Partition 數據不丟失，且 Kafka 仍然能夠繼續工作，Kafka 提供了副本機制，一個 Topic 的每個分區都有若干個副本，一個 Leader 和若干個 Follower。
• Leader：每個分區多個副本的“主”副本，生產者發送數據的對象，以及消費者消費數據的對象，都是 Leader。
• Follower：每個分區多個副本的“從”副本，實時從 Leader 中同步數據，保持和 Leader 數據的同步。Leader 發生故障時，某個 Follower 還會成為新的 Leader。
• Offset：消費者消費的位置信息，監控數據消費到什麼位置，當消費者掛掉再重新恢復的時候，可以從消費位置繼續消費。
• Zookeeper：Kafka 集群能夠正常工作，需要依賴於 Zookeeper，Zookeeper 幫助 Kafka 存儲和管理集群信息。

工作流程

Kafka集群將 Record 流存儲在稱為 Topic 的類別中，每個記錄由一個鍵、一個值和一個時間戳組成。

Kafka 是一個分佈式流平臺，這到底是什麼意思?

• 發佈和訂閱記錄流，類似於消息隊列或企業消息傳遞系統。
• 以容錯的持久方式存儲記錄流。
• 處理記錄流。

Kafka 中消息是以 Topic 進行分類的，生產者生產消息，消費者消費消息，面向的都是同一個 Topic。

Topic 是邏輯上的概念，而 Partition 是物理上的概念，每個 Partition 對應於一個 log 文件，該 log 文件中存儲的就是 Producer 生產的數據。

Producer 生產的數據會不斷追加到該 log 文件末端，且每條數據都有自己的 Offset。

消費者組中的每個消費者，都會實時記錄自己消費到了哪個 Offset，以便出錯恢復時，從上次的位置繼續消費。

存儲機制

由於生產者生產的消息會不斷追加到 log 文件末尾，為防止 log 文件過大導致數據定位效率低下，Kafka 採取了分片和索引機制。

它將每個 Partition 分為多個 Segment，每個 Segment 對應兩個文件：“.index” 索引文件和 “.log” 數據文件。

這些文件位於同一文件下，該文件夾的命名規則為：topic 名-分區號。例如，first 這個 topic 有三分分區，則其對應的文件夾為 first-0，first-1，first-2。

<code># ls /root/data/kafka/first-0         00000000000000009014.index     00000000000000009014.log 00000000000000009014.timeindex 00000000000000009014.snapshot    leader-epoch-checkpoint /<code>

index 和 log 文件以當前 Segment 的第一條消息的 Offset 命名。下圖為 index 文件和 log 文件的結構示意圖：

“.index” 文件存儲大量的索引信息，“.log” 文件存儲大量的數據，索引文件中的元數據指向對應數據文件中 Message 的物理偏移量。

生產者

分區策略

分區原因：

• 方便在集群中擴展，每個 Partition 可以通過調整以適應它所在的機器，而一個 Topic 又可以有多個 Partition 組成，因此可以以 Partition 為單位讀寫了。
• 可以提高併發，因此可以以 Partition 為單位讀寫了。

分區原則：我們需要將 Producer 發送的數據封裝成一個 ProducerRecord 對象。

該對象需要指定一些參數：

• topic：string 類型，NotNull。
• partition：int 類型，可選。
• timestamp：long 類型，可選。
• key：string 類型，可選。
• value：string 類型，可選。
• headers：array 類型，Nullable。

①指明 Partition 的情況下，直接將給定的 Value 作為 Partition 的值。

②沒有指明 Partition 但有 Key 的情況下，將 Key 的 Hash 值與分區數取餘得到 Partition 值。

③既沒有 Partition 有沒有 Key 的情況下，第一次調用時隨機生成一個整數(後面每次調用都在這個整數上自增)，將這個值與可用的分區數取餘，得到 Partition 值，也就是常說的 Round-Robin 輪詢算法。

數據可靠性保證

為保證 Producer 發送的數據，能可靠地發送到指定的 Topic，Topic 的每個 Partition 收到 Producer 發送的數據後，都需要向 Producer 發送 ACK(ACKnowledge 確認收到)。

如果 Producer 收到 ACK，就會進行下一輪的發送，否則重新發送數據。

①副本數據同步策略

何時發送 ACK?確保有 Follower 與 Leader 同步完成，Leader 再發送 ACK，這樣才能保證 Leader 掛掉之後，能在 Follower 中選舉出新的 Leader 而不丟數據。

多少個 Follower 同步完成後發送 ACK?全部 Follower 同步完成，再發送 ACK。

②ISR

採用第二種方案，所有 Follower 完成同步，Producer 才能繼續發送數據，設想有一個 Follower 因為某種原因出現故障，那 Leader 就要一直等到它完成同步。

這個問題怎麼解決?Leader維護了一個動態的 in-sync replica set(ISR)：和 Leader 保持同步的 Follower 集合。

當 ISR 集合中的 Follower 完成數據的同步之後，Leader 就會給 Follower 發送 ACK。

如果 Follower 長時間未向 Leader 同步數據，則該 Follower 將被踢出 ISR 集合，該時間閾值由 replica.lag.time.max.ms 參數設定。Leader 發生故障後，就會從 ISR 中選舉出新的 Leader。

③ACK 應答機制

對於某些不太重要的數據，對數據的可靠性要求不是很高，能夠容忍數據的少量丟失，所以沒必要等 ISR 中的 Follower 全部接受成功。

所以 Kafka 為用戶提供了三種可靠性級別，用戶根據可靠性和延遲的要求進行權衡，選擇以下的配置。

Ack 參數配置：

• 0：Producer 不等待 Broker 的 ACK，這提供了最低延遲，Broker 一收到數據還沒有寫入磁盤就已經返回，當 Broker 故障時有可能丟失數據。
• 1：Producer 等待 Broker 的 ACK，Partition 的 Leader 落盤成功後返回 ACK，如果在 Follower 同步成功之前 Leader 故障，那麼將會丟失數據。
• -1(all)：Producer 等待 Broker 的 ACK，Partition 的 Leader 和 Follower 全部落盤成功後才返回 ACK。但是在 Broker 發送 ACK 時，Leader 發生故障，則會造成數據重複。

④故障處理細節

LEO：每個副本最大的 Offset。HW：消費者能見到的最大的 Offset，ISR 隊列中最小的 LEO。

Follower 故障：Follower 發生故障後會被臨時踢出 ISR 集合，待該 Follower 恢復後，Follower 會 讀取本地磁盤記錄的上次的 HW，並將 log 文件高於 HW 的部分截取掉，從 HW 開始向 Leader 進行同步數據操作。

等該 Follower 的 LEO 大於等於該 Partition 的 HW，即 Follower 追上 Leader 後，就可以重新加入 ISR 了。

Leader 故障：Leader 發生故障後，會從 ISR 中選出一個新的 Leader，之後，為保證多個副本之間的數據一致性，其餘的 Follower 會先將各自的 log 文件高於 HW 的部分截掉，然後從新的 Leader 同步數據。

注意：這隻能保證副本之間的數據一致性，並不能保證數據不丟失或者不重複。

Exactly Once 語義

將服務器的 ACK 級別設置為 -1，可以保證 Producer 到 Server 之間不會丟失數據，即 At Least Once 語義。

相對的，將服務器 ACK 級別設置為 0，可以保證生產者每條消息只會被髮送一次，即 At Most Once 語義。

At Least Once 可以保證數據不丟失，但是不能保證數據不重複;相對的，At Most Once 可以保證數據不重複，但是不能保證數據不丟失。

但是，對於一些非常重要的信息，比如交易數據，下游數據消費者要求數據既不重複也不丟失，即 Exactly Once 語義。

0.11 版本的 Kafka，引入了冪等性：Producer 不論向 Server 發送多少重複數據，Server 端都只會持久化一條。

即：

<code>At Least Once + 冪等性 = Exactly Once /<code>

要啟用冪等性，只需要將 Producer 的參數中 enable.idompotence 設置為 true 即可。

開啟冪等性的 Producer 在初始化時會被分配一個 PID，發往同一 Partition 的消息會附帶 Sequence Number。

而 Borker 端會對

但是 PID 重啟後就會變化，同時不同的 Partition 也具有不同主鍵，所以冪等性無法保證跨分區會話的 Exactly Once。

消費者

消費方式

Consumer 採用 Pull(拉取)模式從 Broker 中讀取數據。

Consumer 採用 Push(推送)模式，Broker 給 Consumer 推送消息的速率是由 Broker 決定的，很難適應消費速率不同的消費者。

它的目標是儘可能以最快速度傳遞消息，但是這樣很容易造成 Consumer 來不及處理消息，典型的表現就是拒絕服務以及網絡擁塞。

而 Pull 模式則可以根據 Consumer 的消費能力以適當的速率消費消息。Pull 模式不足之處是，如果 Kafka 沒有數據，消費者可能會陷入循環中，一直返回空數據。

因為消費者從 Broker 主動拉取數據，需要維護一個長輪詢，針對這一點， Kafka 的消費者在消費數據時會傳入一個時長參數 timeout。

如果當前沒有數據可供消費，Consumer 會等待一段時間之後再返回，這段時長即為 timeout。

分區分配策略

一個 Consumer Group 中有多個 Consumer，一個 Topic 有多個 Partition，所以必然會涉及到 Partition 的分配問題，即確定哪個 Partition 由哪個 Consumer 來消費。

Kafka 有兩種分配策略，一個是 RoundRobin，一個是 Range，默認為Range，當消費者組內消費者發生變化時，會觸發分區分配策略(方法重新分配)。

①RoundRobin

RoundRobin 輪詢方式將分區所有作為一個整體進行 Hash 排序，消費者組內分配分區個數最大差別為 1，是按照組來分的，可以解決多個消費者消費數據不均衡的問題。

但是，當消費者組內訂閱不同主題時，可能造成消費混亂，如下圖所示，Consumer0 訂閱主題 A，Consumer1 訂閱主題 B。

將 A、B 主題的分區排序後分配給消費者組，TopicB 分區中的數據可能分配到 Consumer0 中。

②Range

Range 方式是按照主題來分的，不會產生輪詢方式的消費混亂問題。

但是，如下圖所示，Consumer0、Consumer1 同時訂閱了主題 A 和 B，可能造成消息分配不對等問題，當消費者組內訂閱的主題越多，分區分配可能越不均衡。

Offset 的維護

由於 Consumer 在消費過程中可能會出現斷電宕機等故障，Consumer 恢復後，需要從故障前的位置繼續消費。

所以 Consumer 需要實時記錄自己消費到了哪個 Offset，以便故障恢復後繼續消費。

Kafka 0.9 版本之前，Consumer 默認將 Offset 保存在 Zookeeper 中，從 0.9 版本開始，Consumer 默認將 Offset 保存在 Kafka 一個內置的 Topic 中，該 Topic 為 __consumer_offsets。

總結

上面和大家一起深入探討了 Kafka 的架構，比較偏重理論和基礎，這是掌握 Kafka 的必要內容，接下來我會以代碼和實例的方式，更新 Kafka 有關 API 以及事務、攔截器、監控等高級篇，讓大家徹底理解並且會用 Kafka。

簡介：就職於中科星圖股份有限公司(北京)，研發部後端技術組。個人擅長 Python/Java 開發，瞭解前端基礎;熟練掌握 MySQL，MongoDB，瞭解 Redis;熟悉 Linux 開發環境，掌握 Shell 編程，有良好的 Git 源碼管理習慣;精通 Nginx ，Flask、Swagger 開發框架;有 Docker+Kubernetes 雲服務開發經驗。對人工智能、雲原生技術有較大的興趣。

閱讀更多 51CTO 的文章

關鍵字: 大數據 原理 這麼回事