[[391488]]

什么是高可用

「高可用性」，指系統(tǒng)無間斷地執(zhí)行其功能的能力，代表系統(tǒng)的可用性程度

Kafka從0.8版本開始提供了高可用機制，可保障一個或多個Broker宕機后，其他Broker能繼續(xù)提供服務(wù)

備份機制

Kafka允許同一個Partition存在多個消息副本，每個Partition的副本通常由1個Leader及0個以上的Follower組成，生產(chǎn)者將消息直接發(fā)往對應(yīng)Partition的Leader，F(xiàn)ollower會周期地向Leader發(fā)送同步請求

同一Partition的Replica不應(yīng)存儲在同一個Broker上，因為一旦該Broker宕機，對應(yīng)Partition的所有Replica都無法工作，這就達(dá)不到高可用的效果

所以Kafka會盡量將所有的Partition以及各Partition的副本均勻地分配到整個集群的各個Broker上

「如下圖舉個例子：」

ISR機制

「ISR 副本集合」

ISR 中的副本都是與 Leader 同步的副本，相反，不在 ISR 中的追隨者副本就被認(rèn)為是與 Leader 不同步的

這里的保持同步不是指與Leader數(shù)據(jù)保持完全一致，只需在replica.lag.time.max.ms時間內(nèi)與Leader保持有效連接

Follower周期性地向Leader發(fā)送FetchRequest請求，發(fā)送時間間隔配置在replica.fetch.wait.max.ms中，默認(rèn)值為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立即返回結(jié)果，默認(rèn)值500 
    private final int minBytes;   // Follower容忍的最小返回數(shù)據(jù)大?。寒?dāng)Leader有足夠數(shù)據(jù)時立即返回，兜底等待maxWait返回，默認(rèn)值1 
    private final Map<TopicAndPartition, PartitionFetchInfo> requestInfo;  // Follower中各Partititon對應(yīng)的LEO及獲取數(shù)量 
} 

各Partition的Leader負(fù)責(zé)維護(hù)ISR列表并將ISR的變更同步至ZooKeeper，被移出ISR的Follower會繼續(xù)向Leader發(fā)FetchRequest請求，試圖再次跟上Leader重新進(jìn)入ISR

ISR中所有副本都跟上了Leader，通常只有ISR里的成員才可能被選為Leader

「Unclean領(lǐng)導(dǎo)者選舉」

當(dāng)Kafka中unclean.leader.election.enable配置為true(默認(rèn)值為false)且ISR中所有副本均宕機的情況下，才允許ISR外的副本被選為Leader，此時會丟失部分已應(yīng)答的數(shù)據(jù)

開啟 Unclean 領(lǐng)導(dǎo)者選舉可能會造成數(shù)據(jù)丟失，但好處是，它使得分區(qū) Leader 副本一直存在，不至于停止對外提供服務(wù)，因此提升了高可用性，反之，禁止 Unclean 領(lǐng)導(dǎo)者選舉的好處在于維護(hù)了數(shù)據(jù)的一致性，避免了消息丟失，但犧牲了高可用性

ACK機制

生產(chǎn)者發(fā)送消息中包含acks字段，該字段代表Leader應(yīng)答生產(chǎn)者前Leader收到的應(yīng)答數(shù)

• 「acks=0」

生產(chǎn)者無需等待服務(wù)端的任何確認(rèn)，消息被添加到生產(chǎn)者套接字緩沖區(qū)后就視為已發(fā)送，因此acks=0不能保證服務(wù)端已收到消息

• 「acks=1」

只要 Partition Leader 接收到消息而且寫入本地磁盤了，就認(rèn)為成功了，不管它其他的 Follower 有沒有同步過去這條消息了

• 「acks=all」

Leader將等待ISR中的所有副本確認(rèn)后再做出應(yīng)答，因此只要ISR中任何一個副本還存活著，這條應(yīng)答過的消息就不會丟失

acks=all是可用性最高的選擇，但等待Follower應(yīng)答引入了額外的響應(yīng)時間。Leader需要等待ISR中所有副本做出應(yīng)答，此時響應(yīng)時間取決于ISR中最慢的那臺機器

如果說 Partition Leader 剛接收到了消息，但是結(jié)果 Follower 沒有收到消息，此時 Leader 宕機了，那么客戶端會感知到這個消息沒發(fā)送成功，他會重試再次發(fā)送消息過去

Broker有個配置項min.insync.replicas(默認(rèn)值為1)代表了正常寫入生產(chǎn)者數(shù)據(jù)所需要的最少ISR個數(shù)

當(dāng)ISR中的副本數(shù)量小于min.insync.replicas時，Leader停止寫入生產(chǎn)者生產(chǎn)的消息，并向生產(chǎn)者拋出NotEnoughReplicas異常，阻塞等待更多的Follower趕上并重新進(jìn)入ISR

被Leader應(yīng)答的消息都至少有min.insync.replicas個副本，因此能夠容忍min.insync.replicas-1個副本同時宕機

「結(jié)論：」

發(fā)送的acks=1和0消息會出現(xiàn)丟失情況，為不丟失消息可配置生產(chǎn)者acks=all & min.insync.replicas >= 2

故障恢復(fù)機制

「Kafka從0.8版本開始引入了一套Leader選舉及失敗恢復(fù)機制」

首先需要在集群所有Broker中選出一個Controller，負(fù)責(zé)各Partition的Leader選舉以及Replica的重新分配

• 當(dāng)出現(xiàn)Leader故障后，Controller會將Leader/Follower的變動通知到需為此作出響應(yīng)的Broker。

Kafka使用ZooKeeper存儲Broker、Topic等狀態(tài)數(shù)據(jù)，Kafka集群中的Controller和Broker會在ZooKeeper指定節(jié)點上注冊Watcher(事件監(jiān)聽器)，以便在特定事件觸發(fā)時，由ZooKeeper將事件通知到對應(yīng)Broker

Broker

「當(dāng)Broker發(fā)生故障后，由Controller負(fù)責(zé)選舉受影響Partition的新Leader并通知到相關(guān)Broker」

• 當(dāng)Broker出現(xiàn)故障與ZooKeeper斷開連接后，該Broker在ZooKeeper對應(yīng)的znode會自動被刪除，ZooKeeper會觸發(fā)Controller注冊在該節(jié)點的Watcher;
• Controller從ZooKeeper的/brokers/ids節(jié)點上獲取宕機Broker上的所有Partition;
• Controller再從ZooKeeper的/brokers/topics獲取所有Partition當(dāng)前的ISR;
• 對于宕機Broker是Leader的Partition，Controller從ISR中選擇幸存的Broker作為新Leader;
• 最后Controller通過LeaderAndIsrRequest請求向的Broker發(fā)送LeaderAndISRRequest請求。
  

Controller

集群中的Controller也會出現(xiàn)故障，因此Kafka讓所有Broker都在ZooKeeper的Controller節(jié)點上注冊一個Watcher

Controller發(fā)生故障時對應(yīng)的Controller臨時節(jié)點會自動刪除，此時注冊在其上的Watcher會被觸發(fā)，所有活著的Broker都會去競選成為新的Controller(即創(chuàng)建新的Controller節(jié)點，由ZooKeeper保證只會有一個創(chuàng)建成功)

競選成功者即為新的Controller