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

這期內容當中小編將會給大家帶來有關Kafka基于HW備份恢復弊端的分析是怎樣的，文章內容豐富且以專業的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

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

關于基于HW的備份主要會產生兩種問題：

• 數據丟失

• 數據不一致

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

數據丟失

下圖是一張關于數據丟失的狀態圖，下面講述一下到底發生了什么導致了數據的丟失。

從圖中，我們可以看出初始狀態，leader A和follower B底層都寫入兩條日志，只不過leader A的HW已經更新為1，但是follower B的HW為0（因為follower的HW的更新需要經歷兩次fetch數據請求，這種狀態說明follower B只進行了一次fetch數據請求）

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

當A重新啟動以后，也會進行日志截斷，然后調整HW的值為0。此時offset=1的消息則完全丟失。

數據不一致

下面這張圖是數據不一致的狀態圖，下面講解一下數據不一致的過程中集群中的leader和follower到底發生了哪些變化。

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

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

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

改進之道

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

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

上述就是小編為大家分享的Kafka基于HW備份恢復弊端的分析是怎樣的了，如果剛好有類似的疑惑，不妨參照上述分析進行理解。如果想知道更多相關知識，歡迎關注億速云行業資訊頻道。