Kafka怎么保證高可用

這篇文章主要講解了“Kafka怎么保證高可用”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“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

感謝各位的閱讀，以上就是“Kafka怎么保證高可用”的內容了，經過本文的學習后，相信大家對Kafka怎么保證高可用這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！