一條消息只有被ISR中所有Follower都從Leader複製過去纔會被認爲已提交。這樣就避免了部分數據被寫進了Leader，還沒來得及被任何Follower複製就宕機了，而造成數據丟失。而對於Producer而言，它可以選擇是否等待消息commit，這可以通過request.required.acks來設置。這種機制確保了只要ISR中有一個或者以上的follower，一條被commit的消息就不會丟失。
什麼是ISR？參考這裏：【大數據嗶嗶集20210123】別問，問就是Kafka高可靠
有一個很重要的問題是當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能繼續正常服務。此種情況恢復方案：
- 嘗試恢復(重啓)replica-0，如果能起來，系統正常；2. 如果replica-0不能恢復，需要將min.insync.replicas設置爲1，恢復write功能。
- 當ISR中的replica-0出現crash，緊接着replica-1也出現了crash, 此時[ISR=(1),leader=-1],不能對外提供服務，此種情況恢復方案：
- 嘗試恢復replica-0和replica-1，如果都能起來，則系統恢復正常；
- 如果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功能；
- replica-1恢復，replica-0不能恢復，這個情況上面遇到過，read服務可用，需要將min.insync.replicas設置爲1，恢復write功能；
- replica-0和replica-1都不能恢復，這種情況可以參考情形2.
- 當ISR中的replica-0，replica-1同時宕機，此時[ISR=(0,1)]，不能對外提供服務，此種情況恢復方案：嘗試恢復replica-0和replica-1，當其中任意一個副本恢復正常時，對外可以提供read服務。直到2個副本恢復正常，write功能才能恢復，或者將將min.insync.replicas設置爲1。
歡迎關注，《大數據成神之路》系列文章
歡迎關注，《大數據成神之路》系列文章
歡迎關注，《大數據成神之路》系列文章