微服務想搞好，消息中間件不能少，Kafka 基礎入門介紹

一切還得從微服務說起

現在微服務流行，很多公司起項目都是分佈式微服務，但是你想過沒有，不是把一個單體拆開了，用域名去相互調就叫微服務。好的微服務架構設計模式裏要求每個服務的自治性，這樣服務拆成微服務後才能穩定。

怎麼才能讓每個服務儘量達到自治性呢？這就需要領域事件、事件溯源、CQRS、Saga 這些設計模式，不好意思一下子說了很多概念，以後慢慢給大家解釋。

這幾個模式裏邊有個關鍵點—需要通過把領域事件發佈給遠程的其他服務，完成數據同步。這就需要消息中間件了，消息中間件這塊我瞭解的也不深，公司裏用 RocketMQ，不過付費版和開源版差別很大。

聽說 Rocket MQ 很多概念也來自 Kafka，學會它其他的消息中間件基本也大差不差的都會了，今天分享一篇 Kafka 的基礎入門文章給大家，以下文章轉自公衆號 -- 華仔聊技術。作者對 Kafka 頗有研究，大家一起學習一下。

文章大綱

kafka 簡介

Kafka 是一個分佈式的基於發佈 / 訂閱模式的消息隊列（Message Queue），主要應用與大數據實時處理領域。其主要設計目標如下：

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

爲什麼要用消息系統

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

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

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。

Kafka 分區

Kafka 和 Zookeeper 的關係

kafka 集羣架構

工作流程

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

Kafka 的工作流程

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

存儲機制

Kafka 存儲機制

此時 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 文件的結構示意圖：

index 文件和 log 文件的結構示意圖

Replica - 副本

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

Kafka 集羣副本

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, 以支持高併發的讀寫。

總結

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

華仔聊技術 聊聊後端技術架構以及中間件源碼

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/VcnJRjPfSfCxoVFURjUx_g