Kafka怎么保證高可用

這篇文章主要講解了“Kafka怎么保證高可用”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請(qǐng)大家跟著小編的思路慢慢深入，一起來研究和學(xué)習(xí)“Kafka怎么保證高可用”吧！

什么是高可用

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

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

備份機(jī)制

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

同一Partition的Replica不應(yīng)存儲(chǔ)在同一個(gè)Broker上，因?yàn)橐坏┰揃roker宕機(jī)，對(duì)應(yīng)Partition的所有Replica都無法工作，這就達(dá)不到高可用的效果

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

「如下圖舉個(gè)例子：」

ISR機(jī)制

「ISR 副本集合」

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

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

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

各Partition的Leader負(fù)責(zé)維護(hù)ISR列表并將ISR的變更同步至ZooKeeper，被移出ISR的Follower會(huì)繼續(xù)向Leader發(fā)FetchRequest請(qǐng)求，試圖再次跟上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中所有副本均宕機(jī)的情況下，才允許ISR外的副本被選為Leader，此時(shí)會(huì)丟失部分已應(yīng)答的數(shù)據(jù)

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

ACK機(jī)制

生產(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中任何一個(gè)副本還存活著，這條應(yīng)答過的消息就不會(huì)丟失

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

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

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

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

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

「結(jié)論：」

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

故障恢復(fù)機(jī)制

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

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

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

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

Broker

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

• 當(dāng)Broker出現(xiàn)故障與ZooKeeper斷開連接后，該Broker在ZooKeeper對(duì)應(yīng)的znode會(huì)自動(dòng)被刪除，ZooKeeper會(huì)觸發(fā)Controller注冊在該節(jié)點(diǎn)的Watcher;

• Controller從ZooKeeper的/brokers/ids節(jié)點(diǎn)上獲取宕機(jī)Broker上的所有Partition;

• Controller再從ZooKeeper的/brokers/topics獲取所有Partition當(dāng)前的ISR;

• 對(duì)于宕機(jī)Broker是Leader的Partition，Controller從ISR中選擇幸存的Broker作為新Leader;

• 最后Controller通過LeaderAndIsrRequest請(qǐng)求向的Broker發(fā)送LeaderAndISRRequest請(qǐng)求。

  
  

Controller

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

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

競選成功者即為新的Controller

感謝各位的閱讀，以上就是“Kafka怎么保證高可用”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)Kafka怎么保證高可用這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是億速云，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！