亚洲A一区二区,国产亚洲亚洲亚洲,日本精品久久久久久久久免费

作者 | 蔡柱梁
審校 | 重樓

目標

了解 Kafka 的重要概念
搭建 Kafka 服務端
使用SpringBoot 實現簡單的 Demo

1 了解 Kafka 的重要概念

Kafka 是使用 Scala 語言開發的一個多分區、多副本且基于 ZooKeeper 協調的分布式消息系統。目前，它的定位是一個分布式流式處理平臺。
Kafka 在我們工作中最常扮演的三個角色：

消息系統

Kafka 和傳統的消息中間件一樣具有系統解耦、冗余存儲、流量削峰、異步通信等功能。

存儲系統

Kafka 會將消息持久化到磁盤，并且有多副本機制，有效降低了數據丟失的風險。有時，我們也可以使用它來存儲數據，只需要把對應的數據保留策略設置成為“永久”即可。

流式處理平臺

Kafka 不僅為很多流式處理框架（如：Storm、Spark、Flink 等）提供了可靠的數據來源，還提供了一個完整的流式處理類庫。

1.1 基本概念

上圖（圖出自于《深入理解Kafka核心設計與實踐原理》）體現了 Kafka 的整體架構，Producer 發送消息，Kafka 將元數據存儲在 ZK 中并交由ZK 管理，Consumer 通過拉模式獲取消息。

Producer

生產者，消息的投遞方，負責創建消息并投遞到 Kafka 中。

Broker

Kafka 服務實例

Consumer

消費者，處理消息的一方
上面的概念都是物理層面上的，但是在實際使用過程中還有很多邏輯方面的定義，這些概念也是需要了解的。如果不了解，就算勉強寫出了代碼，但是自己還是一臉懵不知道自己都定義了什么，它們都有什么意義，估計離生產故障就不遠了。
接下來我們再去了解三個重要的邏輯概念：

Topic（主題）

生產者創建消息是要發送給特定的主題的，而消費者拉取消息也是要指定主題的。消息就是通過主題來歸類的。

Partition（分區）

一個Topic 可以有多個 Patition，而一個 Partition 只屬于一個 Topic。同一個 Topic 下，不同 Partition 存儲的消息是不同的。

Offset（偏移量）

Kafka 的消息是可以持久化并反復消費的，這是因為在每個分區中，當有消息寫入就會像追加日志那樣順序寫入（順序IO的寫入性能是十分好的），通過Offset 來記錄對應消息所在的位置。因此，Offset 是消息在 Partition 中的唯一標識，并且能看出同一個 Partition 內的消息的先后順序，我們稱之為 “Kafka 保證消息在分區內是有序的”。
為了更好，更直觀體現上面三者的關系，我們先一起看下圖（圖出自于《深入理解Kafka核心設計與實踐原理》）

該圖展示了一個擁有4個 Partition 的 Topic，而分區里面的阿拉伯數字就是 Offset（也表示著一條消息），虛線部分代表新消息可以插入的位置。每條消息在發送到 Broker 之前，會先計算當前消息應該發送到哪個 Partition。因此，只要我們設置合理，消息可以均勻地分配在不同的 Partition 上，當發現請求數量激增時，我們也可以考慮通過適當增加 Partition（Broker 也要增加）的方式，從而降低每個 Broker 的 I/O 壓力。
另外，為了降低消息丟失的風險，Kafka 為 Partition 引進了多副本（Replica）機制，通過增加副本數量來提高容災能力。副本之間采用的是“一主多從”的設計，其中 Leader 負責讀寫請求，Follower 則僅負責同步 Leader 的消息（這種設計方式，大家應該要意識到會存在同步滯后的問題），并且副本處于不同的 Broker 中，當 Leader 出現故障（一般是因為其所在的 Broker 出現故障導致的）時，就從 Follower 中重新選舉出新的 Leader 提供服務。當選出新的 Leader 并恢復服務后，Consumer 可以通過之前自己保存的 Offset 來繼續拉取消息消費。
結合到目前為止我們所知道的知識點，一起看下 4 個 Broker 的 Kafka 集群中，某一個 Topic 有三個 Partition，其副本因子為 3（副本因子為3就是每個 Partition 有 3 個副本，一個 Leader，兩個 Follower）的架構圖（圖出自于《深入理解Kafka核心設計與實踐原理》）。

1.2 Message 與 Partition

在 1.1 小節中，我們已經知道一條消息只會存在一個 Partition中（只管 Leader，不管 Follower），而 Offset 則是消息在 Partition 中的唯一標識。而在本章節，我們將一起更深入地了解消息與 Partition 的關系，還有副本間同步數據所衍生的一些概念。
上面有提到 Kafka 的多副本機制是 Leader 提供讀寫，而 Flower 是需要同步 Leader 的數據的，那么具體是怎樣的呢？請看下圖（單主題單分區3副本）：

當Producer 不斷往 Leader 寫入消息時，Flower 會不斷去 Leader 拉取消息，但是每臺機器的性能會有出入，所以同步也有差異，正如上圖這般。對于 Consumer 而言，只有 HW 之前的消息是可見可拉取消費的，這樣做有個好處就是當發生故障轉移時，Consumer 的 Offset 也不會發生數組越界的問題。這種做法是 Kafka 權衡利弊后給出的數據可靠性與性能平衡的方案，即不采取同步復制（性能差，對于高并發場景是災難般的設計），也不采取異步復制（完全異步，數據丟失問題突出）。
當然，對于Producer 而言就是消息丟失了，有時我們需要確保消息百分百投遞，這樣不就有問題了嗎？不急，Kafka 可以在 Producer 的配置上配置 acks=-1 + min.insync.replicas=n（n 大于 1），這樣配置后，只有消息被寫入所有副本后，Kafka 服務端才會返回 ack 給 Producer。
下面來梳理下上面提及的幾個概念：