Kafka中的Leader選舉是什么

本篇內容主要講解“Kafka中的Leader選舉是什么”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Kafka中的Leader選舉是什么”吧!

創(chuàng)新互聯(lián)公司是一家業(yè)務范圍包括IDC托管業(yè)務,網(wǎng)站空間、主機租用、主機托管，四川、重慶、廣東電信服務器租用,德陽服務器托管，成都網(wǎng)通服務器托管,成都服務器租用,業(yè)務范圍遍及中國大陸、港澳臺以及歐美等多個國家及地區(qū)的互聯(lián)網(wǎng)數(shù)據(jù)服務公司。

一條消息只有被ISR中所有Follower都從Leader復制過去才會被認為已提交。這樣就避免了部分數(shù)據(jù)被寫進了Leader，還沒來得及被任何Follower復制就宕機了，而造成數(shù)據(jù)丟失。而對于Producer而言，它可以選擇是否等待消息commit，這可以通過request.required.acks來設置。這種機制確保了只要ISR中有一個或者以上的follower，一條被commit的消息就不會丟失。

什么是ISR？

有一個很重要的問題是當Leader宕機了，怎樣在Follower中選舉出新的Leader，因為Follower可能落后很多或者直接crash了，所以必須確保選擇最新的Follower作為新的Leader。一個基本的原則就是，如果Leader不在了，新的Leader必須擁有原來的Leader commit的所有消息。這就需要做一個折中，如果Leader在一個消息被commit前等待更多的Follower確認，那么在它掛掉之后就有更多的Follower可以成為新的Leader，但這也會造成吞吐率的下降。

一種非常常用的選舉Leader的方式是“少數(shù)服從多數(shù)“，Kafka并不是采用這種方式。這種模式下，如果我們有2f+1個副本，那么在commit之前必須保證有f+1個replica復制完消息，同時為了保證能正確選舉出新的Leader，失敗的副本數(shù)不能超過f個。這種方式有個很大的優(yōu)勢，系統(tǒng)的延遲取決于最快的幾臺機器，也就是說比如副本數(shù)為3，那么延遲就取決于最快的那個Follower而不是最慢的那個?！吧贁?shù)服從多數(shù)”的方式也有一些劣勢，為了保證Leader選舉的正常進行，它所能容忍的失敗的Follower數(shù)比較少，如果要容忍1個Follower掛掉，那么至少要3個以上的副本，如果要容忍2個Follower掛掉，必須要有5個以上的副本。也就是說，在生產(chǎn)環(huán)境下為了保證較高的容錯率，必須要有大量的副本，而大量的副本又會在大數(shù)據(jù)量下導致性能的急劇下降。這種算法更多用在Zookeeper這種共享集群配置的系統(tǒng)中而很少在需要大量數(shù)據(jù)的系統(tǒng)中使用的原因。HDFS的HA功能也是基于“少數(shù)服從多數(shù)”的方式，但是其數(shù)據(jù)存儲并不是采用這樣的方式。

實際上，Leader選舉的算法非常多，比如Zookeeper的Zab、Raft以及Viewstamped Replication。而Kafka所使用的Leader選舉算法更像是微軟的PacificA算法。

Kafka在Zookeeper中為每一個Partition動態(tài)的維護了一個ISR，這個ISR里的所有replica都跟上了Leader，只有ISR里的成員才能有被選為Leader的可能（unclean.leader.election.enable=false）。在這種模式下，對于f+1個副本，一個Kafka Topic能在保證不丟失已經(jīng)commit消息的前提下容忍f個副本的失敗，在大多數(shù)使用場景下，這種模式是十分有利的。事實上，為了容忍f個副本的失敗，“少數(shù)服從多數(shù)”的方式和ISR在commit前需要等待的副本的數(shù)量是一樣的，但是ISR需要的總的副本的個數(shù)幾乎是“少數(shù)服從多數(shù)”的方式的一半。

上文提到，在ISR中至少有一個Follower時，Kafka可以確保已經(jīng)commit的數(shù)據(jù)不丟失，但如果某一個Partition的所有replica都掛了，就無法保證數(shù)據(jù)不丟失了。這種情況下有兩種可行的方案：

  • 等待ISR中任意一個replica“活”過來，并且選它作為Leader

  • 選擇第一個“活”過來的replica（并不一定是在ISR中）作為Leader

這就需要在可用性和一致性當中作出一個簡單的抉擇。如果一定要等待ISR中的replica“活”過來，那不可用的時間就可能會相對較長。而且如果ISR中所有的replica都無法“活”過來了，或者數(shù)據(jù)丟失了，這個Partition將永遠不可用。選擇第一個“活”過來的replica作為Leader，而這個replica不是ISR中的replica，那即使它并不保障已經(jīng)包含了所有已commit的消息，它也會成為Leader而作為Consumer的數(shù)據(jù)源。默認情況下，Kafka采用第二種策略，即unclean.leader.election.enable=true，也可以將此參數(shù)設置為false來啟用第一種策略。

unclean.leader.election.enable這個參數(shù)對于leader的選舉、系統(tǒng)的可用性以及數(shù)據(jù)的可靠性都有至關重要的影響。下面我們來分析下幾種典型的場景。

Kafka中的Leader選舉是什么

如果上圖所示，假設某個Partition中的副本數(shù)為3，replica-0, replica-1, replica-2分別存放在Broker0, Broker1和Broker2中。AR=(0,1,2)，ISR=(0,1)。 設置request.required.acks=-1, min.insync.replicas=2，unclean.leader.election.enable=false。這里將Broker0中的副本也稱之為Broker0起初Broker0為Leader，Broker1為Follower。

  • 當ISR中的replica-0出現(xiàn)crash的情況時，Broker1選舉為新的Leader[ISR=(1)]，因為受min.insync.replicas=2影響，write不能服務，但是read能繼續(xù)正常服務。此種情況恢復方案：

  1. 嘗試恢復(重啟)replica-0，如果能起來，系統(tǒng)正常；2. 如果replica-0不能恢復，需要將min.insync.replicas設置為1，恢復write功能。

  • 當ISR中的replica-0出現(xiàn)crash，緊接著replica-1也出現(xiàn)了crash, 此時[ISR=(1),leader=-1],不能對外提供服務，此種情況恢復方案：

  1. 嘗試恢復replica-0和replica-1，如果都能起來，則系統(tǒng)恢復正常；

  1. 如果replica-0起來，而replica-1不能起來，這時候仍然不能選出Leader，因為當設置unclean.leader.election.enable=false時，leader只能從ISR中選舉，當ISR中所有副本都失效之后，需要ISR中最后失效的那個副本能恢復之后才能選舉Leader，即replica-0先失效，replica-1后失效，需要replica-1恢復后才能選舉Leader。保守的方案建議設置unclean.leader.election.enable=true，但是這樣會有丟失數(shù)據(jù)的情況發(fā)生，這樣可以恢復read服務。同樣需要將min.insync.replicas設置為1，恢復write功能；

  2. replica-1恢復，replica-0不能恢復，這個情況上面遇到過，read服務可用，需要將min.insync.replicas設置為1，恢復write功能；

  3. replica-0和replica-1都不能恢復，這種情況可以參考情形2.

  • 當ISR中的replica-0，replica-1同時宕機，此時[ISR=(0,1)]，不能對外提供服務，此種情況恢復方案：嘗試恢復replica-0和replica-1，當其中任意一個副本恢復正常時，對外可以提供read服務。直到2個副本恢復正常，write功能才能恢復，或者將將min.insync.replicas設置為1。

到此，相信大家對“Kafka中的Leader選舉是什么”有了更深的了解，不妨來實際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續(xù)學習！

網(wǎng)頁題目：Kafka中的Leader選舉是什么
URL分享：http://muchs.cn/article42/gddcec.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站建設、網(wǎng)站收錄、網(wǎng)站設計、電子商務、外貿(mào)建站、網(wǎng)站維護

廣告

聲明：本網(wǎng)站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)

綿陽服務器托管