Kafka中的Leader選舉是什么

本篇內容主要講解“Kafka中的Leader選舉是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Kafka中的Leader選舉是什么”吧!

一條消息只有被ISR中所有Follower都從Leader復制過去才會被認為已提交。這樣就避免了部分數據被寫進了Leader，還沒來得及被任何Follower復制就宕機了，而造成數據丟失。而對于Producer而言，它可以選擇是否等待消息commit，這可以通過request.required.acks來設置。這種機制確保了只要ISR中有一個或者以上的follower，一條被commit的消息就不會丟失。

什么是ISR？

有一個很重要的問題是當Leader宕機了，怎樣在Follower中選舉出新的Leader，因為Follower可能落后很多或者直接crash了，所以必須確保選擇最新的Follower作為新的Leader。一個基本的原則就是，如果Leader不在了，新的Leader必須擁有原來的Leader commit的所有消息。這就需要做一個折中，如果Leader在一個消息被commit前等待更多的Follower確認，那么在它掛掉之后就有更多的Follower可以成為新的Leader，但這也會造成吞吐率的下降。

一種非常常用的選舉Leader的方式是“少數服從多數“，Kafka并不是采用這種方式。這種模式下，如果我們有2f+1個副本，那么在commit之前必須保證有f+1個replica復制完消息，同時為了保證能正確選舉出新的Leader，失敗的副本數不能超過f個。這種方式有個很大的優勢，系統的延遲取決于最快的幾臺機器，也就是說比如副本數為3，那么延遲就取決于最快的那個Follower而不是最慢的那個。“少數服從多數”的方式也有一些劣勢，為了保證Leader選舉的正常進行，它所能容忍的失敗的Follower數比較少，如果要容忍1個Follower掛掉，那么至少要3個以上的副本，如果要容忍2個Follower掛掉，必須要有5個以上的副本。也就是說，在生產環境下為了保證較高的容錯率，必須要有大量的副本，而大量的副本又會在大數據量下導致性能的急劇下降。這種算法更多用在Zookeeper這種共享集群配置的系統中而很少在需要大量數據的系統中使用的原因。HDFS的HA功能也是基于“少數服從多數”的方式，但是其數據存儲并不是采用這樣的方式。

實際上，Leader選舉的算法非常多，比如Zookeeper的Zab、Raft以及Viewstamped Replication。而Kafka所使用的Leader選舉算法更像是微軟的PacificA算法。

Kafka在Zookeeper中為每一個Partition動態的維護了一個ISR，這個ISR里的所有replica都跟上了Leader，只有ISR里的成員才能有被選為Leader的可能（unclean.leader.election.enable=false）。在這種模式下，對于f+1個副本，一個Kafka Topic能在保證不丟失已經commit消息的前提下容忍f個副本的失敗，在大多數使用場景下，這種模式是十分有利的。事實上，為了容忍f個副本的失敗，“少數服從多數”的方式和ISR在commit前需要等待的副本的數量是一樣的，但是ISR需要的總的副本的個數幾乎是“少數服從多數”的方式的一半。

上文提到，在ISR中至少有一個Follower時，Kafka可以確保已經commit的數據不丟失，但如果某一個Partition的所有replica都掛了，就無法保證數據不丟失了。這種情況下有兩種可行的方案：

• 等待ISR中任意一個replica“活”過來，并且選它作為Leader

• 選擇第一個“活”過來的replica（并不一定是在ISR中）作為Leader

這就需要在可用性和一致性當中作出一個簡單的抉擇。如果一定要等待ISR中的replica“活”過來，那不可用的時間就可能會相對較長。而且如果ISR中所有的replica都無法“活”過來了，或者數據丟失了，這個Partition將永遠不可用。選擇第一個“活”過來的replica作為Leader，而這個replica不是ISR中的replica，那即使它并不保障已經包含了所有已commit的消息，它也會成為Leader而作為Consumer的數據源。默認情況下，Kafka采用第二種策略，即unclean.leader.election.enable=true，也可以將此參數設置為false來啟用第一種策略。

unclean.leader.election.enable這個參數對于leader的選舉、系統的可用性以及數據的可靠性都有至關重要的影響。下面我們來分析下幾種典型的場景。

如果上圖所示，假設某個Partition中的副本數為3，replica-0, replica-1, replica-2分別存放在Broker0, Broker1和Broker2中。AR=(0,1,2)，ISR=(0,1)。 設置request.required.acks=-1, min.insync.replicas=2，unclean.leader.election.enable=false。這里將Broker0中的副本也稱之為Broker0起初Broker0為Leader，Broker1為Follower。

• 當ISR中的replica-0出現crash的情況時，Broker1選舉為新的Leader[ISR=(1)]，因為受min.insync.replicas=2影響，write不能服務，但是read能繼續正常服務。此種情況恢復方案：

1. 嘗試恢復(重啟)replica-0，如果能起來，系統正常；2. 如果replica-0不能恢復，需要將min.insync.replicas設置為1，恢復write功能。

• 當ISR中的replica-0出現crash，緊接著replica-1也出現了crash, 此時[ISR=(1),leader=-1],不能對外提供服務，此種情況恢復方案：

1. 嘗試恢復replica-0和replica-1，如果都能起來，則系統恢復正常；

2. 如果replica-0起來，而replica-1不能起來，這時候仍然不能選出Leader，因為當設置unclean.leader.election.enable=false時，leader只能從ISR中選舉，當ISR中所有副本都失效之后，需要ISR中最后失效的那個副本能恢復之后才能選舉Leader，即replica-0先失效，replica-1后失效，需要replica-1恢復后才能選舉Leader。保守的方案建議設置unclean.leader.election.enable=true，但是這樣會有丟失數據的情況發生，這樣可以恢復read服務。同樣需要將min.insync.replicas設置為1，恢復write功能；

3. replica-1恢復，replica-0不能恢復，這個情況上面遇到過，read服務可用，需要將min.insync.replicas設置為1，恢復write功能；

4. replica-0和replica-1都不能恢復，這種情況可以參考情形2.

• 當ISR中的replica-0，replica-1同時宕機，此時[ISR=(0,1)]，不能對外提供服務，此種情況恢復方案：嘗試恢復replica-0和replica-1，當其中任意一個副本恢復正常時，對外可以提供read服務。直到2個副本恢復正常，write功能才能恢復，或者將將min.insync.replicas設置為1。

到此，相信大家對“Kafka中的Leader選舉是什么”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！