1 kafka簡介

2 為什么要用消息系統

3 kafka基礎知識

4 kafka集群架構

5 總結

1 kafka簡介

其主要設計目標如下：

以時間復雜度為O(1)的方式提供消息持久化能力，即使對TB級以上數據也能保證常數時間的訪問性能

高吞吐率。即使在非常廉價的機器上也能做到單機支持每秒100K條消息的傳輸

支持Kafka Server間的消息分區，及分布式消費，同時保證每個partition內的消息順序傳輸，同時支持離線數據處理和實時數據處理

基于 Spring Boot + MyBatis Plus + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/ruoyi-vue-pro

視頻教程：https://doc.iocoder.cn/video/

2 為什么要用消息系統

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

解耦：允許我們獨立修改隊列兩邊的處理過程而互不影響。

冗余：有些情況下，我們在處理數據的過程會失敗造成數據丟失。消息隊列把數據進行持久化直到它們已經被完全處理，通過這一方式規避了數據丟失風險, 確保你的數據被安全的保存直到你使用完畢

峰值處理能力：不會因為突發的流量請求導致系統崩潰，消息隊列能夠使服務頂住突發的訪問壓力, 有助于解決生產消息和消費消息的處理速度不一致的情況

異步通信：消息隊列允許用戶把消息放入隊列但不立即處理它, 等待后續進行消費處理。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 實現的后臺管理系統 + 用戶小程序，支持 RBAC 動態權限、多租戶、數據權限、工作流、三方登錄、支付、短信、商城等功能

項目地址：https://github.com/YunaiV/yudao-cloud

視頻教程：https://doc.iocoder.cn/video/

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。

4 kafka集群架構

工作流程

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

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

存儲機制

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

index, log, snapshot, timeindex 文件以當前 Segment 的第一條消息的 Offset 命名。其中 “.index” 文件存儲大量的索引信息，“.log” 文件存儲大量的數據，索引文件中的元數據指向對應數據文件中 Message 的物理偏移量。

下圖為index 文件和 log 文件的結構示意圖：

Replica - 副本

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

Controller

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

Offset 的維護

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

5 總結

上面和大家一起深入探討了 Kafka 的簡介, 基礎知識和集群架構，后續會從Kafka 三高(高性能, 高可用, 高并發)方面來詳細闡述其巧妙的設計思想。