柚子快報(bào)激活碼778899分享：分布式 Kafka數(shù)據(jù)同步

http://yzkb.51969.com/

Kafka中所有消息是通過Topic為單位進(jìn)行管理，每個topic被分為多個分區(qū)，分區(qū)是是按照Segments存儲文件塊。每個分區(qū)日志是存儲在磁盤上的日志序列，Kafka可以保證分區(qū)內(nèi)消息的有序性。其中Leader負(fù)責(zé)對應(yīng)分區(qū)的讀寫、Follower負(fù)責(zé)同步分區(qū)的數(shù)據(jù)，0.11 版本之前Kafka使用highwatermarker（高水位）機(jī)制保證數(shù)據(jù)的同步，但是基于高水位的同步數(shù)據(jù)可能會導(dǎo)致數(shù)據(jù)的丟失，不一致以及亂序。

要了解kafka數(shù)據(jù)同步機(jī)制，首先要了解如下概念

LEO：log end offset 標(biāo)識的是每個分區(qū)日志中最后一條消息的下一個位置，分區(qū)的每個副本都有自己的LEO.HW:：high watermarker稱為高水位線，所有分區(qū)的小于等于HW的數(shù)據(jù)都是已備份的,當(dāng)所有節(jié)點(diǎn)都備份成功，Leader會更新水位線。ISR：In-sync-replicas，kafka的leader會維護(hù)一份處于同步的副本集合，如果在`replica.lag.time.max.ms`時間內(nèi)系統(tǒng)沒有發(fā)送fetch請求，或者已然在發(fā)送請求，但是在該限定時間內(nèi)沒有趕上Leader的數(shù)據(jù)就被剔除ISR列表。在Kafka-0.9.0版本剔除`replica.lag.max.messages`消息個數(shù)限定，因?yàn)檫@個會導(dǎo)致其他的Broker節(jié)點(diǎn)頻繁的加入和退出ISR。

高水位會出現(xiàn)的問題???

1、可能會出現(xiàn)數(shù)據(jù)不一致

BrokerA為follower，BrokerB為Leader假設(shè)BrokerA中的HW=1，BrokerB中的HW=2，此時BrokerA和B同時宕機(jī)此時BrokerA先重啟了，此時BrokerA成為了Leader，同時BrokerA接收到了新請求，寫入了新的消息日志m3，BrokerA的HW+1，HW=12當(dāng)BrokerB啟動后，會向BrokerA發(fā)消息進(jìn)行數(shù)據(jù)同步，由于只會更新高于水位線的數(shù)據(jù)，而此時BrokerA和BrokerB水位線一致，所以BrokerB不會更新數(shù)據(jù)，BrokerA與BrokerB中數(shù)據(jù)不一致

?2、可能會出現(xiàn)數(shù)據(jù)丟失

BrokerA為follower，BrokerB為LeaderBrokerA讀取到m2消息，此時只是BrokerA只是拷貝了消息，需要等待BrokerB確認(rèn)提交m2消息，所以此時BrokerA的HW仍為1BrokerA還未等待BrokerB的確定提交，發(fā)生了宕機(jī)，當(dāng)BrokerA重啟后，發(fā)現(xiàn)BrokerB也宕機(jī)了，此時BrokerA成為了Leader，發(fā)現(xiàn)自己的HW=1，所以會截?cái)啻笥贖W的數(shù)據(jù)，此時m2消息丟失

由于0.11版本之前Kafka的副本備份機(jī)依賴HW存數(shù)據(jù)不一致問題和丟失數(shù)據(jù)問題，因此在0.11版本引入了 Leader Epoch同步機(jī)制解決這個問題。任意一個Leader持有一個LeaderEpoch。LeaderEpoch是一個由Controller管理的32位數(shù)字，存儲在Zookeeper的分區(qū)狀態(tài)信息中，會傳遞給每個新的Leader。Leader接受Producer請求數(shù)據(jù)上使用LeaderEpoch標(biāo)記每個Message。然后，該LeaderEpoch編號將通過復(fù)制協(xié)議傳播，并用于替換HW標(biāo)記，作為消息截?cái)嗟膮⒖键c(diǎn)，以下為Leader Epoch具體執(zhí)行流程

Lead Epoch實(shí)現(xiàn)原理

?改進(jìn)消息格式，每個消息集都帶有一個4字節(jié)的Leader Epoch號。在每個日志目錄中，會創(chuàng)建一個新的Leader Epoch Sequence文件，以此用來Leader Epoch的序列與消息的Start Offset。它也緩存在每個副本中，也緩存在內(nèi)存中。當(dāng)Follower變成Leader時，它會將新的Leader Epoch和副本的LEO添加到Leader Epoch Sequence序列文件的末尾并刷新數(shù)據(jù)。給Leader產(chǎn)生的每個新消息集都帶有新的“Leader Epoch”標(biāo)記。Leader變成Followe時，會先從本地的Leader Epoch Sequence文件中加載數(shù)據(jù)，將數(shù)據(jù)存儲在內(nèi)存中，給相應(yīng)的分區(qū)的Leader發(fā)送epoch 請求，該請求包含最新的EpochID,StartOffset信息.Leader接收到信息以后返回該EpochID所對應(yīng)的LastOffset信息。該信息可能是最新EpochID的StartOffset或者是當(dāng)前EpochID的Log End Offset信息。以此用來更新數(shù)據(jù)或者截?cái)鄶?shù)據(jù)

同步情形

Follower的Leader Epoch中的startOffset比Leader的?。篎ollower會向Leader發(fā)送epoch請求，Leadr會依次響應(yīng)給Follower比Fllower大Leader Epoch?Sequence，F(xiàn)ollower更新本地的LEDFollower的Leader Epoch的信息startOffset信息比Leader返回的LastOffset要大，F(xiàn)ollower回去重置自己的Leader Epoch文件，將Offset修改為Leader的LastOffset信息，并且截?cái)嘧约旱娜罩拘畔ⅰＷ⒁猓篎ollower在提取過程中，如果LeaderEpoch消息集大于其最新的LeaderEpoch，則會在其LeaderEpochSequence中添加新的LeaderEpoch和起始偏移量，并將Epoch數(shù)據(jù)文件刷新到磁盤。同時將Fetch的日志信息刷新到本地日志文件。

?Lead Epoch 如何解決HW的數(shù)據(jù)不一致與數(shù)據(jù)丟失

1、解決數(shù)據(jù)丟失

BrokeA為Follower，Epoch ：[0,0]，BrokerB為Leader Epoch：[0,0]BrokerA讀取到m2消息，此時只是BrokerA只是拷貝了消息，需要等待BrokerB確認(rèn)提交m2消息，此時BrokerA發(fā)生了宕機(jī)BrokerA啟動后，發(fā)現(xiàn)BrokerB發(fā)生了宕機(jī)，此時BrokerA變成了Leader，并接受了新的消息m3后，BrokerA它會將新的Leader Epoch和副本的LEO添加到Leader Epoch Sequence序列文件的末尾并刷新數(shù)據(jù)，此時Epoch：[1,2]BrokerB啟動后，會向BrokerA發(fā)送epoch請求，由于BrokerB（Follower）的epoch小于BrokerA(Leader)的，leader會更新follower的epoch值，F(xiàn)ollower會從最新的epoch的startOffset開始更新數(shù)據(jù)

2、解決數(shù)據(jù)不一致

BrokerA為follower Epoch：[0,0]，BrokerB為Leader Epoch：[0,0]此時BrokerA和B同時宕機(jī)此時BrokerA先重啟了，此時BrokerA成為了Leader，同時BrokerA接收到了新請求，寫入了新的消息日志m3，此時BrokerA的Epoch：[1,1]當(dāng)BrokerB啟動后，會向BrokerA發(fā)Epoch請求，Leader返回Epoch為1的數(shù)據(jù)，即[1,1],BrokerB發(fā)現(xiàn)BrokerA是從offset=1開始更新，于是截?cái)嘧约旱谋镜豲ffset為1的數(shù)據(jù)，并將leader的offset>=1的數(shù)據(jù)更新到本地，并更新本地的Epoch為[1,1]

柚子快報(bào)激活碼778899分享：分布式 Kafka數(shù)據(jù)同步

http://yzkb.51969.com/

參考閱讀