這篇文章將為大家詳細(xì)講解有關(guān)Kafka如何實(shí)現(xiàn)副本同步，小編覺得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

網(wǎng)站建設(shè)哪家好，找成都創(chuàng)新互聯(lián)！專注于網(wǎng)頁設(shè)計(jì)、網(wǎng)站建設(shè)、微信開發(fā)、小程序設(shè)計(jì)、集團(tuán)企業(yè)網(wǎng)站建設(shè)等服務(wù)項(xiàng)目。為回饋新老客戶創(chuàng)新互聯(lián)還提供了雞西免費(fèi)建站歡迎大家使用！

follower副本同步的過程大致就是向leader發(fā)起獲取數(shù)據(jù)請(qǐng)求，leader給出響應(yīng)并返回?cái)?shù)據(jù)，然后follower副本更新自己的HW和LEO值，并且follower的請(qǐng)求數(shù)據(jù)過程中，leader也會(huì)更新自己的HW和LE，在這里注意一下，leder副本除了維護(hù)自己的HW和LEO值以外，還維護(hù)了一份各個(gè)follower副本的LEO值，這里我們就暫時(shí)叫他RemoteLEO。

再總結(jié)一下，follower副本的同步過程無非就是從leader副本獲取數(shù)據(jù)寫入log，然后更新HW和LEO的值。

HW、LEO更新機(jī)制

假設(shè)我們新的kafka集群剛剛建立，沒有任何生產(chǎn)者，沒有消息，follower此時(shí)向leader發(fā)起fetch數(shù)據(jù)的請(qǐng)求，leader發(fā)現(xiàn)沒有數(shù)據(jù)會(huì)將該請(qǐng)求暫時(shí)存在purgatory(用于臨時(shí)存放暫時(shí)無法被處理的請(qǐng)求，但是這些請(qǐng)求有超時(shí)設(shè)置，如果超時(shí)則強(qiáng)制完成)中。Leader和follower的初始狀態(tài)如下：

此時(shí)，假設(shè)生產(chǎn)者向kafka某個(gè)topic的分區(qū)發(fā)送了一條消息，leader副本會(huì)將自己的LEO值+1，HW值不變，RemoteLEO值不變。狀態(tài)圖如下：

kafka在接受到生產(chǎn)者的消息后，主要經(jīng)歷下述過程（這里假設(shè)follower暫時(shí)無發(fā)出fetch數(shù)據(jù)的請(qǐng)求）：

1. leader將數(shù)據(jù)寫入底層日志，并更新自己的LEO值

2. leader會(huì)嘗試更新自己的HW值，因?yàn)榇藭r(shí)RemoteLEO值為0，LEO值為1，兩者之間取較小的值，所以HW的值依然是0，不進(jìn)行更新

當(dāng)寫入消息后，假設(shè)follower發(fā)出了fetch數(shù)據(jù)請(qǐng)求，因?yàn)橛行碌臄?shù)據(jù)產(chǎn)生，所以leader會(huì)將新的數(shù)據(jù)響應(yīng)給follower，follower在接收到新的數(shù)據(jù)以后，會(huì)將數(shù)據(jù)寫入底層日志并且更新自己的LEO。狀態(tài)圖如下：

follower從發(fā)起fetch數(shù)據(jù)請(qǐng)求，到響應(yīng)完成，leader和follower主要會(huì)經(jīng)歷下述過程：

1. follower發(fā)起fetch數(shù)據(jù)的請(qǐng)求，并且在請(qǐng)求中會(huì)攜帶自己自己的fetch offset因?yàn)榇藭r(shí)follower中沒有任何數(shù)據(jù)，所以fetch offset為0

2. leader在收到請(qǐng)求后，讀取底層的log數(shù)據(jù)

3. leader會(huì)嘗試更新RemoteLEO，因?yàn)閒ollower請(qǐng)求中的fetch offset為0，所以不做更新

4. leader會(huì)嘗試更新HW，比較LEO和RemoteLEO兩者的大小，取較小的值，因此HW的值依然為0，不做更新

5. leader此時(shí)會(huì)把數(shù)據(jù)和HW值響應(yīng)給follower

6. follower收到響應(yīng)以后，會(huì)將數(shù)據(jù)寫入底層log日志，并更新其LEO

7. follower嘗試更新其HW值，比較自身的LEO值和響應(yīng)中的HW，兩者取較小的值，因此HW值依然為0，不做更新

以上步驟，一次fetch數(shù)據(jù)請(qǐng)求已全部完成，leader的HW、LEO、RemoteLEO均沒有做出更新，follower將數(shù)據(jù)寫入了底層日志并且更新了LEO。那么關(guān)于HW的更新則需要伴隨再一次的fetch數(shù)據(jù)請(qǐng)求更新才能成功。正是因?yàn)镠W需要兩次fetch請(qǐng)求才能更新，因此kafka利用水印進(jìn)行follower同步會(huì)產(chǎn)生數(shù)據(jù)丟失、數(shù)據(jù)不一致的問題(這個(gè)下一節(jié)講)。下面讓我們看一下第二次fetch請(qǐng)求后的結(jié)果狀態(tài)圖。

在經(jīng)歷過第二次fetch數(shù)據(jù)請(qǐng)求后，leader中的RemoteLEO和HW會(huì)成功更新為1，follower中的HW也會(huì)更新為1。狀態(tài)圖如下：

follower第二次發(fā)起fetch數(shù)據(jù)請(qǐng)求，到響應(yīng)完成，leader和follower經(jīng)歷的過程和第一次沒什么區(qū)別，只是請(qǐng)求和響應(yīng)中的數(shù)據(jù)發(fā)生了變化：

1. follower再次發(fā)起fetch數(shù)據(jù)請(qǐng)求，這一次攜帶的fetch offset為1而不再是0

2. leader在收到請(qǐng)求后，讀取底層log日志

3. leader嘗試更新RemoteLEO，這一次本地的LEO和fectch offset都為1，因此RemoteLEO成功更新為1

4. leader嘗試更新HW，比較LEO和RemoteLEO，兩者的值均為1，因此HW也成功更新為1

5. leader此時(shí)會(huì)把數(shù)據(jù)（實(shí)際上這次沒有數(shù)據(jù)，）和HW值響應(yīng)給follower

6. follower收到響應(yīng)后，因?yàn)榇舜螞]有數(shù)據(jù)過來，所以不再寫底層log日志，LEO也不會(huì)發(fā)生更新

7. follower嘗試更新HW，比較自身的LEO和響應(yīng)中HW，因?yàn)閮烧叨紴?，所以follower的HW成功更新。

LEO、HW更新關(guān)鍵點(diǎn)

Leader

• Leader LEO：消息寫入底層log后便發(fā)生更新

• Leader RemoteLEO：需要比較本地的RemoteLEO和fetch offset的值，兩者取較小

• Leader HW：需要比較RemoteLEO和LEO的值，兩者取較小

更新順序：有數(shù)據(jù)寫入底層日志LEO更新，其次會(huì)嘗試更新RemoteLEO，再嘗試更新HW

Follower

• Follower LEO：取決于response中是否有日志數(shù)據(jù)

• Follower HW：response中的HW和LEO進(jìn)行比較，兩者取較小

關(guān)于“Kafka如何實(shí)現(xiàn)副本同步”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。