這是一道非常經(jīng)典的 Kafka 問題，是關于 Leader 在“異?！鼻闆r下的選舉問題。

背景

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

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

如下圖所示：

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

不同步的 Follower 節(jié)點

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

也就是說，F(xiàn)ollower Partition 還未從 Leader Partition 中同步到最新的數(shù)據(jù)，Leader Partition 就突然宕機了，這就產(chǎn)生了不同的 Follower 節(jié)點了。

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

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

升級 VS 不升級

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

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

所以，不同步的 Follower 節(jié)點是升級為 Leader 或不升級為 Leader 都有其優(yōu)點和缺點。

使用者的選擇權

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

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

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

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