from: http://www.jasongj.com/2015/01/02/Kafka%E6%B7%B1%E5%BA%A6%E8%A7%A3%E6%9E%90/

一種非常常用的選舉leader的方式是“majority vote”（“少數服從多數”），但Kafka並未采用這種方式。這種模式下，如果我們有2f+1個replica（包含leader和follower），那在commit之前必須保證有f+1個replica復制完消息，為了保證正確選出新的leader，fail的replica不能超過f個。因為在剩下的任意f+1個replica裏，至少有一個replica包含有最新的所有消息。這種方式有個很大的優勢，系統的latency只取決於最快的幾臺server，也就是說，如果replication factor是3，那latency就取決於最快的那個follower而非最慢那個。majority vote也有一些劣勢，為了保證leader election的正常進行，它所能容忍的fail的follower個數比較少。如果要容忍1個follower掛掉，必須要有3個以上的replica，如果要容忍2個follower掛掉，必須要有5個以上的replica。也就是說，在生產環境下為了保證較高的容錯程度，必須要有大量的replica，而大量的replica又會在大數據量下導致性能的急劇下降。這就是這種算法更多用在Zookeeper這種共享集群配置的系統中而很少在需要存儲大量數據的系統中使用的原因。例如HDFS的HA feature是基於majority-vote-based journal，但是它的數據存儲並沒有使用這種expensive的方式。

實際上，leader election算法非常多，比如Zookeper的Zab, Raft和Viewstamped Replication。而Kafka所使用的leader election算法更像微軟的PacificA算法。
　　Kafka在Zookeeper中動態維護了一個ISR（in-sync replicas） set，這個set裏的所有replica都跟上了leader，只有ISR裏的成員才有被選為leader的可能。在這種模式下，對於f+1個replica，一個Kafka topic能在保證不丟失已經ommit的消息的前提下容忍f個replica的失敗。在大多數使用場景中，這種模式是非常有利的。事實上，為了容忍f個replica的失敗，majority vote和ISR在commit前需要等待的replica數量是一樣的，但是ISR需要的總的replica的個數幾乎是majority vote的一半。

leader 選舉機制