一條消息隻有被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。