Kafka 的副本機制

Kafka 的高可用實現(xiàn)主要依賴副本機制。

Broker 和 Partition 的關(guān)系

在分析副本機制之前，先來看一下 Broker 和 Partition 之間的關(guān)系。Broker 在英文中是代理、經(jīng)紀(jì)人的意思，對應(yīng)到 Kafka 集群中，是一個 Kafka 服務(wù)器節(jié)點，Kafka 集群由多個 Broker 組成，也就是對應(yīng)多個 Kafka 節(jié)點。

Kafka 是典型的發(fā)布訂閱模式，存在 Topic 的概念，一個 Broker 可以容納多個 Topic，也就是一臺服務(wù)器可以傳輸多個 Topic 數(shù)據(jù)。

不過 Topic 是一個邏輯概念，和物理上如何存儲無關(guān)，Kafka 為了實現(xiàn)可擴展性，將一個 Topic 分散到多個 Partition 中，這里的 Partition 就是一個物理概念，對應(yīng)的是具體某個 Broker 上的磁盤文件。

從 Partition 的角度，Kafka 保證消息在 Partition 內(nèi)部有序，所以 Partition 是一段連續(xù)的存儲，不能跨多個 Broker 存在，如果是在同一個 Broker 上，也不能掛載到多個磁盤。從 Broker 的角度，一個 Broker 可以有多個 Topic，對應(yīng)多個 Partition。

除此之外，Partition 還可以細分為一個或者多個 Segment，也就是數(shù)據(jù)塊，每個 Segment 都對應(yīng)一個 index 索引文件，以及一個 log 數(shù)據(jù)文件。對 Partition 的進一步拆分，使得 Kafka 對 分區(qū)的管理更加靈活。

Replication副本 之間如何同步數(shù)據(jù)

基于 Kafka 的系統(tǒng)設(shè)計，你可以思考一下，如果沒有副本，那么當(dāng)某個 Kafka Broker 掛掉，或者某臺服務(wù)器宕機（可能部署了多個 Broker），存儲在其上的消息就不能被正常消費，導(dǎo)致系統(tǒng)可用性降低，或者出現(xiàn)數(shù)據(jù)丟失，這不符合分布式高可用的要求，出現(xiàn)單點故障，也不滿足 Kafka 數(shù)據(jù)傳輸持久性和投遞語義的設(shè)計目標(biāo)。

Kafka 中有一個配置參數(shù) replication-factor（副本因子），可以調(diào)整對應(yīng)分區(qū)下副本的數(shù)量，注意副本因子數(shù)包含原來的 Partition，如果需要有 2 個副本，則要配置為 3。

假設(shè)現(xiàn)在有一個訂單的 Topic，配置分區(qū)數(shù)為 3，如果配置 replication-factor 為 3，那么對應(yīng)的有三個分區(qū)，每個分區(qū)都有 3 個副本。

在有多個副本的情況下，不同副本之間如何分工呢？

每個分區(qū)下配置多個副本，多個副本之間為了協(xié)調(diào)，就必須有一定的同步機制。

Kafka 中同一個分區(qū)下的不同副本，有不同的角色關(guān)系，分為 Leader Replication 和 Follower Replication。

• Leader 負責(zé)處理所有 Producer、Consumer 的請求，進行讀寫處理
• Follower 作為數(shù)據(jù)備份，不處理來自客戶端的請求。

Follower 不接受讀寫請求，那么數(shù)據(jù)來自哪里呢？

它會通過 Fetch Request 方式，拉取 Leader 副本的數(shù)據(jù)進行同步。

Fetch ，在 Kafka 中，會為數(shù)據(jù)同步開辟一個單獨的線程，稱為 ReplicaFetcherThread，該線程會主動從 Leader 批量拉取數(shù)據(jù)，這樣可以高性能的實現(xiàn)數(shù)據(jù)同步。

Replication 分配有哪些約定

Kafka 中分區(qū)副本數(shù)的配置，既要考慮提高系統(tǒng)可用性，又要盡量減少機器資源浪費。

一方面，為了更好地做負載均衡，Kafka 會將所有的 Partition 均勻地分配到整個集群上；

另一方面，為了提高 Kafka 的系統(tǒng)容錯能力，一個 Partition 的副本，也要分散到不同的 Broker 上，否則就去了副本的意義。

一般來說，為了盡可能地提升服務(wù)的可用性和容錯率，Kafka 的分區(qū)和副本分配遵循如下的原則：

• 一個 Topic 的 Partition 數(shù)量大于 Broker 的數(shù)量，使 Partition 盡量均勻分配到整個集群上；
• 同一個分區(qū)，所有的副本要盡量均勻分配到集群中的多臺 Broker 上，盡可能保證同一個 分區(qū)下的主從副本，分配到不同的 Broker 上。

Leader Replication 如何選舉

一旦牽扯到數(shù)據(jù)同步，就必然會有 Leader 節(jié)點宕機以后重新選擇的問題。引入 Replication 機制之后，同一個 Partition 可能會有多個副本，如果Leader掛掉，需要在這些副本之間選出一個 新的Leader。

Kafka 數(shù)據(jù)同步中有一個 ISR（In-Sync Replicas，副本同步隊列）的概念，Leader 節(jié)點在返回 ACK 響應(yīng)時，會關(guān)注 ISR 中節(jié)點的同步狀態(tài)，所以這個隊列里的所有副本，都和 Leader 保持一致。

Kafka 的 ISR 依賴 ZooKeeper 進行管理，ISR 副本同步隊列中的節(jié)點，擁有優(yōu)先選舉的權(quán)利，因為 ISR 里的節(jié)點和 Leader 保持一致，如果必須滿足一致性，只有 ISR 里的成員才能被選為 Leader。

如果某個 Broker 掛掉，Kafka 會從 ISR 列表中選擇一個分區(qū)作為新的 Leader 副本。

• 如果 ISR 列表是空的，這時候有兩個策略，一個是直接拋出 NoReplicaOnlineException 異常，保證一致性；
• 另外一個是從其他副本中選擇一個作為 Leader，則可能會丟失數(shù)據(jù)，具體需要根據(jù)業(yè)務(wù)場景進行配置。

所有的副本都掛了怎么辦

現(xiàn)在考慮一個極端情況，如果一個分區(qū)下的所有副本都掛掉了，那如何處理呢？

在這種情況下，Kafka 需要等待某個副本恢復(fù)服務(wù)，具體可以有兩種方案：

• 等待 ISR 中的某個副本恢復(fù)正常，作為新的 Leader；
  方案一優(yōu)先保證數(shù)據(jù)一致性

• 等待任一個 副本恢復(fù)正常，作為新的 Leader。
  方案二優(yōu)先保證服務(wù)可用性

在第二種方案下，由于選擇的 Leader 節(jié)點可能不是來自 ISR，所以可能會存在數(shù)據(jù)丟失，不能保證已經(jīng)包含全部 Commit 的信息；
如果選擇第一種方案，會保證數(shù)據(jù)不丟失，但是如果全部的 ISR 節(jié)點都徹底宕機，系統(tǒng)就無法對外提供服務(wù)了，對應(yīng)的分區(qū)會徹底不可用。

在實際配置中，可以根據(jù)不同的業(yè)務(wù)場景選擇不同的方案。