這是一道非常經典的 Kafka 問題，是關于 Leader 在“異常”情況下的選舉問題。

背景

我們知道 Kafka 中的 Partition（分區）是存儲消息的最終介質，但 Partition 又有兩種分類：

• Leader Partition：主分區，負責數據寫入和讀取。
• Follower Partition：副本分區，用于數據備份和主節點宕機之后的分區選舉，保證了 Kafka 服務的高可用。

如下圖所示：

其中，Leader Partition 是用來處理生產者和消費者請求的，而 Follower Partition 是用來保證 Kafka 集群的高可用的，也就是當 Leader Partition 宕機之后，會通過某種算法將其中一個 Follower Partition 升級為 Leader Partition 繼續運行。

不同步的 Follower 節點

在分布式系統下，數據一致性問題是一個令人頭疼的問題，那么這個問題在 Kafka Leader Partition 和 Follower Partition 中也存在，例如以下場景：

也就是說，Follower Partition 還未從 Leader Partition 中同步到最新的數據，Leader Partition 就突然宕機了，這就產生了不同的 Follower 節點了。

小知識點：數據一致性問題是指在一個系統中，不同部分的數據在邏輯上應該保持一致，但實際情況卻出現了矛盾或不匹配的現象。

那問題來了，如果有不同步的 Follower Partition 要升級為 Leader 會發生什么問題？

升級 VS 不升級

當出現不同步的 Follower Partition，而 Leader Partition 有意外宕機的場景，此時我們有兩種選擇：

• 將不同步的 Follower 節點升級為 Leader 節點：但這樣就會造成數據丟失的問題，但好處是此時集群可以繼續運行。
• 不同步的 Follower 不自動升級 Leader 節點：等待原 Leader 恢復再繼續運行，此時不會導致數據丟失，但可能要等待很久才能恢復 Kafka 服務的正常運行，因為 Leader 宕機可能要更新內存芯片之后才能運行，而這個時間是比較久的。

所以，不同步的 Follower 節點是升級為 Leader 或不升級為 Leader 都有其優點和缺點。

使用者的選擇權

而在這種情況下，Kafka 就把這個選擇權給使用者了，此時我們可以通過配置 Broker（或集群）的“unclean.leader.election.enable”屬性來決定到底要不要升級不同步的 Follower 節點為 Leader 節點，這個屬性有以下兩個值可以設置：

• true：如果此屬性設置為 true，那么即使是不完全同步的 Follower Partition 也會升級為 Leader，此時犧牲了一定的數據一致性（數據丟失風險），保證了 Kafka 服務的高可用。
• false：如果此屬性設置為 false，就表示不會將不完全同步的 Follower Partition 升級為 Leader，會等待原 Leader 重新上線之后才能繼續運行 Kafka 服務。此時保證了數據的一致性，但犧牲了 Kafka 服務的可用性。

unclean.leader.election.enable 的默認值為 true。

因此，如果是對數據丟失不敏感的系統可以使用 unclean.leader.election.enable=true，如果對數據丟失敏感的，例如銀行系統等可以使用 unclean.leader.election.enable=false 保證數據的一致性。