Kafka如何實現(xiàn)副本同步

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

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

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

HW、LEO更新機制

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

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

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

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

2. leader會嘗試更新自己的HW值，因為此時RemoteLEO值為0，LEO值為1，兩者之間取較小的值，所以HW的值依然是0，不進(jìn)行更新

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

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

1. follower發(fā)起fetch數(shù)據(jù)的請求，并且在請求中會攜帶自己自己的fetch offset因為此時follower中沒有任何數(shù)據(jù)，所以fetch offset為0

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

3. leader會嘗試更新RemoteLEO，因為follower請求中的fetch offset為0，所以不做更新

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

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

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

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

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

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

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

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

2. leader在收到請求后，讀取底層log日志

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

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

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

6. follower收到響應(yīng)后，因為此次沒有數(shù)據(jù)過來，所以不再寫底層log日志，LEO也不會發(fā)生更新

7. follower嘗試更新HW，比較自身的LEO和響應(yīng)中HW，因為兩者都為1，所以follower的HW成功更新。

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

Leader

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

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

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

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

Follower

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

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

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