Kafka如何保證高可用？有圖有真相
什么是高可用
「高可用性」，指系統無間斷地執行其功能的能力，代表系統的可用性程度
Kafka從0.8版本開始提供了高可用機制，可保障一個或多個Broker宕機后，其他Broker能繼續提供服務
備份機制
Kafka允許同一個Partition存在多個消息副本，每個Partition的副本通常由1個Leader及0個以上的Follower組成，生產者將消息直接發往對應Partition的Leader，Follower會周期地向Leader發送同步請求
同一Partition的Replica不應存儲在同一個Broker上，因為一旦該Broker宕機，對應Partition的所有Replica都無法工作，這就達不到高可用的效果
所以Kafka會盡量將所有的Partition以及各Partition的副本均勻地分配到整個集群的各個Broker上
「如下圖舉個例子：」
ISR機制
「ISR 副本集合」
ISR 中的副本都是與 Leader 同步的副本，相反，不在 ISR 中的追隨者副本就被認為是與 Leader 不同步的
這里的保持同步不是指與Leader數據保持完全一致，只需在replica.lag.time.max.ms時間內與Leader保持有效連接
Follower周期性地向Leader發送FetchRequest請求，發送時間間隔配置在replica.fetch.wait.max.ms中，默認值為500
- public class FetchRequest {
- private final short versionId;
- private final int correlationId;
- private final String clientId;
- private final int replicaId;
- private final int maxWait; // Follower容忍的最大等待時間: 到點Leader立即返回結果，默認值500
- private final int minBytes; // Follower容忍的最小返回數據大小：當Leader有足夠數據時立即返回，兜底等待maxWait返回，默認值1
- private final Map<TopicAndPartition, PartitionFetchInfo> requestInfo; // Follower中各Partititon對應的LEO及獲取數量
- }
各Partition的Leader負責維護ISR列表并將ISR的變更同步至ZooKeeper，被移出ISR的Follower會繼續向Leader發FetchRequest請求，試圖再次跟上Leader重新進入ISR
ISR中所有副本都跟上了Leader，通常只有ISR里的成員才可能被選為Leader
「Unclean領導者選舉」
當Kafka中unclean.leader.election.enable配置為true(默認值為false)且ISR中所有副本均宕機的情況下，才允許ISR外的副本被選為Leader，此時會丟失部分已應答的數據
開啟 Unclean 領導者選舉可能會造成數據丟失，但好處是，它使得分區 Leader 副本一直存在，不至于停止對外提供服務，因此提升了高可用性，反之，禁止 Unclean 領導者選舉的好處在于維護了數據的一致性，避免了消息丟失，但犧牲了高可用性
ACK機制
生產者發送消息中包含acks字段，該字段代表Leader應答生產者前Leader收到的應答數
- 「acks=0」
生產者無需等待服務端的任何確認，消息被添加到生產者套接字緩沖區后就視為已發送，因此acks=0不能保證服務端已收到消息
- 「acks=1」
只要 Partition Leader 接收到消息而且寫入本地磁盤了，就認為成功了，不管它其他的 Follower 有沒有同步過去這條消息了
- 「acks=all」
Leader將等待ISR中的所有副本確認后再做出應答，因此只要ISR中任何一個副本還存活著，這條應答過的消息就不會丟失
acks=all是可用性最高的選擇，但等待Follower應答引入了額外的響應時間。Leader需要等待ISR中所有副本做出應答，此時響應時間取決于ISR中最慢的那臺機器
如果說 Partition Leader 剛接收到了消息，但是結果 Follower 沒有收到消息，此時 Leader 宕機了，那么客戶端會感知到這個消息沒發送成功，他會重試再次發送消息過去
Broker有個配置項min.insync.replicas(默認值為1)代表了正常寫入生產者數據所需要的最少ISR個數
當ISR中的副本數量小于min.insync.replicas時，Leader停止寫入生產者生產的消息，并向生產者拋出NotEnoughReplicas異常，阻塞等待更多的Follower趕上并重新進入ISR
被Leader應答的消息都至少有min.insync.replicas個副本，因此能夠容忍min.insync.replicas-1個副本同時宕機
「結論：」
發送的acks=1和0消息會出現丟失情況，為不丟失消息可配置生產者acks=all & min.insync.replicas >= 2
故障恢復機制
「Kafka從0.8版本開始引入了一套Leader選舉及失敗恢復機制」
首先需要在集群所有Broker中選出一個Controller，負責各Partition的Leader選舉以及Replica的重新分配
- 當出現Leader故障后，Controller會將Leader/Follower的變動通知到需為此作出響應的Broker。
Kafka使用ZooKeeper存儲Broker、Topic等狀態數據，Kafka集群中的Controller和Broker會在ZooKeeper指定節點上注冊Watcher(事件監聽器)，以便在特定事件觸發時，由ZooKeeper將事件通知到對應Broker
Broker
「當Broker發生故障后，由Controller負責選舉受影響Partition的新Leader并通知到相關Broker」
- 當Broker出現故障與ZooKeeper斷開連接后，該Broker在ZooKeeper對應的znode會自動被刪除，ZooKeeper會觸發Controller注冊在該節點的Watcher;
- Controller從ZooKeeper的/brokers/ids節點上獲取宕機Broker上的所有Partition;
- Controller再從ZooKeeper的/brokers/topics獲取所有Partition當前的ISR;
- 對于宕機Broker是Leader的Partition，Controller從ISR中選擇幸存的Broker作為新Leader;
- 最后Controller通過LeaderAndIsrRequest請求向的Broker發送LeaderAndISRRequest請求。
Controller
集群中的Controller也會出現故障，因此Kafka讓所有Broker都在ZooKeeper的Controller節點上注冊一個Watcher
Controller發生故障時對應的Controller臨時節點會自動刪除，此時注冊在其上的Watcher會被觸發，所有活著的Broker都會去競選成為新的Controller(即創建新的Controller節點，由ZooKeeper保證只會有一個創建成功)
競選成功者即為新的Controller
