Kafka基于HW備份恢復(fù)弊端的分析是怎樣的

這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)Kafka基于HW備份恢復(fù)弊端的分析是怎樣的，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

創(chuàng)新互聯(lián)云計算的互聯(lián)網(wǎng)服務(wù)提供商,擁有超過13年的服務(wù)器租用、服務(wù)器機(jī)柜租賃、云服務(wù)器、虛擬主機(jī)、網(wǎng)站系統(tǒng)開發(fā)經(jīng)驗(yàn)，已先后獲得國家工業(yè)和信息化部頒發(fā)的互聯(lián)網(wǎng)數(shù)據(jù)中心業(yè)務(wù)許可證。專業(yè)提供云主機(jī)、虛擬主機(jī)、域名與空間、VPS主機(jī)、云服務(wù)器、香港云服務(wù)器、免備案服務(wù)器等。

我們會闡述弊端的原因，并且講解kafka為了解決問題從而引入了Lead Epoch的概念。

關(guān)于基于HW的備份主要會產(chǎn)生兩種問題：

• 數(shù)據(jù)丟失

• 數(shù)據(jù)不一致

下面的問題講解基于服務(wù)端min.insync.replicas值為1，該值為，表示只要Leader接收生產(chǎn)者請求并將消息成功寫入了log日志，就會通知客戶端消息寫入成功，不用在乎ISR中的其他follower副本。

數(shù)據(jù)丟失

下圖是一張關(guān)于數(shù)據(jù)丟失的狀態(tài)圖，下面講述一下到底發(fā)生了什么導(dǎo)致了數(shù)據(jù)的丟失。

從圖中，我們可以看出初始狀態(tài)，leader A和follower B底層都寫入兩條日志，只不過leader A的HW已經(jīng)更新為1，但是follower B的HW為0（因?yàn)閒ollower的HW的更新需要經(jīng)歷兩次fetch數(shù)據(jù)請求，這種狀態(tài)說明follower B只進(jìn)行了一次fetch數(shù)據(jù)請求）

假設(shè)現(xiàn)在follower沒有進(jìn)行第二次fetch數(shù)據(jù)請求（圖中給的原因假設(shè)是重啟），并且leader A中由于某種原因發(fā)生了宕機(jī)，此時當(dāng)follower B重啟之后由于leader A已經(jīng)宕機(jī)所以順理成章當(dāng)選leader，B當(dāng)選leader以后發(fā)現(xiàn)自己的HW值為0，于是將offset為1的消息進(jìn)行刪除，同時將LEO的值更新為1(下一次寫入消息將會從offset 1開始，此時原來offset=1的消息丟失)。

當(dāng)A重新啟動以后，也會進(jìn)行日志截斷，然后調(diào)整HW的值為0。此時offset=1的消息則完全丟失。

數(shù)據(jù)不一致

下面這張圖是數(shù)據(jù)不一致的狀態(tài)圖，下面講解一下數(shù)據(jù)不一致的過程中集群中的leader和follower到底發(fā)生了哪些變化。

初始狀態(tài)為Leader A和Follower B都成功寫了第一條日志，并且Leader已經(jīng)寫入了第二條日志。假設(shè)此時Follower B來發(fā)起fetch數(shù)據(jù)請求同步第二條日志，由于此時Follower B攜帶的LEO值為1，當(dāng)Leader A收到fetch數(shù)據(jù)請求時，將自己關(guān)于的B的RemoteLEO改為1，并且更新自身的HW值為1，然后返回數(shù)據(jù)給Follower B。

就在這時，很不幸B發(fā)生了宕機(jī)，并沒有收到響應(yīng)，與此同時LeaderA也發(fā)生了宕機(jī)。但在重啟的過程中，B先恢復(fù)，于是B成為Leader(HWL值更新為0，LEO值更新為1)，此時A依舊還沒恢復(fù)重啟。

假設(shè)就在此時生產(chǎn)者產(chǎn)生了一條消息，于是B將其寫入低層log，并且更新了自身的HW為1，LEO為2。一切看似正常，此時A成功重啟，發(fā)現(xiàn)分區(qū)Leader的HW為1，自身的HW也為1，因此不做更新，不進(jìn)行日志截斷。于是，Leader B和Follower A的offset=1存儲的消息是不一致的。

改進(jìn)之道

由于基于HW的備份恢復(fù)機(jī)制會產(chǎn)生上述兩種問題，因此Kafka在0.11.0.0版本之后引入Lead Epoch的解決上述問題。

Lead Epoch其實(shí)就是在Leader Broker上單獨(dú)開辟了一組緩存，來記錄(epoch, offset)這組鍵值對數(shù)據(jù)，這個鍵值對會被定期寫入一個檢查點(diǎn)文件。Leader每發(fā)生一次變更epoch的值就會加1，offset就代表該epoch版本的Leader寫入的第一條日志的位移。當(dāng)Leader首次寫底層日志時，會在緩存中增加一個條目，否則不做更新。

上述就是小編為大家分享的Kafka基于HW備份恢復(fù)弊端的分析是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。

當(dāng)前標(biāo)題：Kafka基于HW備份恢復(fù)弊端的分析是怎樣的
網(wǎng)站路徑：http://muchs.cn/article4/iehooe.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供響應(yīng)式網(wǎng)站、云服務(wù)器、外貿(mào)建站、虛擬主機(jī)、靜態(tài)網(wǎng)站、軟件開發(fā)

廣告

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