上周分享的一篇文章《Kafka如何實(shí)現(xiàn)每秒上百萬(wàn)的超高并發(fā)寫(xiě)入?》，相信大家都知道了寫(xiě)入 Kafka 的數(shù)據(jù)是會(huì)落地寫(xiě)入磁盤(pán)的，這篇給大家聊下寫(xiě)入 Kafka 的數(shù)據(jù)該如何保證其不丟失?

我們暫且不考慮寫(xiě)磁盤(pán)的具體過(guò)程，先大致看看下面的圖，這代表了 Kafka 的核心架構(gòu)原理。

Kafka 分布式存儲(chǔ)架構(gòu)

那么現(xiàn)在問(wèn)題來(lái)了，如果每天產(chǎn)生幾十 TB 的數(shù)據(jù)，難道都寫(xiě)一臺(tái)機(jī)器的磁盤(pán)上嗎?這明顯是不靠譜的啊!

所以說(shuō)，這里就得考慮數(shù)據(jù)的分布式存儲(chǔ)了，我們結(jié)合 Kafka 的具體情況來(lái)說(shuō)說(shuō)。

在 Kafka 里面，有一個(gè)核心的概念叫做“Topic”，這個(gè) Topic 你就姑且認(rèn)為是一個(gè)數(shù)據(jù)集合吧。

舉個(gè)例子，如果你現(xiàn)在有一份網(wǎng)站的用戶行為數(shù)據(jù)要寫(xiě)入 Kafka，你可以搞一個(gè) Topic 叫做“user_access_log_topic”，這里寫(xiě)入的都是用戶行為數(shù)據(jù)。

然后如果你要把電商網(wǎng)站的訂單數(shù)據(jù)的增刪改變更記錄寫(xiě) Kafka，那可以搞一個(gè) Topic 叫做“order_tb_topic”，這里寫(xiě)入的都是訂單表的變更記錄。

然后假如說(shuō)咱們舉個(gè)例子，就說(shuō)這個(gè)用戶行為 Topic 吧，里面如果每天寫(xiě)入幾十 TB 的數(shù)據(jù)，你覺(jué)得都放一臺(tái)機(jī)器上靠譜嗎?

明顯不太靠譜，所以 Kafka 有一個(gè)概念叫做 Partition，就是把一個(gè) Topic 數(shù)據(jù)集合拆分為多個(gè)數(shù)據(jù)分區(qū)，你可以認(rèn)為是多個(gè)數(shù)據(jù)分片，每個(gè) Partition 可以在不同的機(jī)器上，儲(chǔ)存部分?jǐn)?shù)據(jù)。

這樣，不就可以把一個(gè)超大的數(shù)據(jù)集合分布式存儲(chǔ)在多臺(tái)機(jī)器上了嗎?大家看下圖，一起來(lái)體會(huì)一下。

Kafka 高可用架構(gòu)

但是這個(gè)時(shí)候，我們又會(huì)遇到一個(gè)問(wèn)題，就是萬(wàn)一某臺(tái)機(jī)器宕機(jī)了，這臺(tái)機(jī)器上的那個(gè) Partition 管理的數(shù)據(jù)不就丟失了嗎?

所以說(shuō)，我們還得做多副本冗余，每個(gè) Partition 都可以搞一個(gè)副本放在別的機(jī)器上，這樣某臺(tái)機(jī)器宕機(jī)，只不過(guò)是 Partition 其中一個(gè)副本丟失。

如果某個(gè) Partition 有多副本的話，Kafka 會(huì)選舉其中一個(gè) Parititon 副本作為 Leader，然后其他的 Partition 副本是 Follower。

只有 Leader Partition 是對(duì)外提供讀寫(xiě)操作的，F(xiàn)ollower Partition 就是從 Leader Partition 同步數(shù)據(jù)。

一旦 Leader Partition 宕機(jī)了，就會(huì)選舉其他的 Follower Partition 作為新的 Leader Partition 對(duì)外提供讀寫(xiě)服務(wù)，這不就實(shí)現(xiàn)了高可用架構(gòu)了?

大家看下面的圖，看看這個(gè)過(guò)程：

Kafka 寫(xiě)入數(shù)據(jù)丟失問(wèn)題

現(xiàn)在我們來(lái)看看，什么情況下 Kafka 中寫(xiě)入數(shù)據(jù)會(huì)丟失呢?其實(shí)也很簡(jiǎn)單，大家都知道寫(xiě)入數(shù)據(jù)都是往某個(gè) Partition 的 Leader 寫(xiě)入的，然后那個(gè) Partition 的 Follower 會(huì)從 Leader 同步數(shù)據(jù)。

但是萬(wàn)一 1 條數(shù)據(jù)剛寫(xiě)入 Leader Partition，還沒(méi)來(lái)得及同步給 Follower，此時(shí) Leader Partiton 所在機(jī)器突然就宕機(jī)了呢?

大家看下圖：

如上圖，這個(gè)時(shí)候有一條數(shù)據(jù)是沒(méi)同步到 Partition0 的 Follower 上去的，然后 Partition0 的 Leader 所在機(jī)器宕機(jī)了。

此時(shí)就會(huì)選舉 Partition0 的 Follower 作為新的 Leader 對(duì)外提供服務(wù)，然后用戶是不是就讀不到剛才寫(xiě)入的那條數(shù)據(jù)了?

因?yàn)?Partition0 的 Follower 上是沒(méi)有同步到***的一條數(shù)據(jù)的。這個(gè)時(shí)候就會(huì)造成數(shù)據(jù)丟失的問(wèn)題。

Kafka 的 ISR 機(jī)制是什么?

現(xiàn)在我們先留著這個(gè)問(wèn)題不說(shuō)具體怎么解決，先回過(guò)頭來(lái)看一個(gè) Kafka 的核心機(jī)制，就是 ISR 機(jī)制。

這個(gè)機(jī)制簡(jiǎn)單來(lái)說(shuō)，就是會(huì)自動(dòng)給每個(gè) Partition 維護(hù)一個(gè) ISR 列表，這個(gè)列表里一定會(huì)有 Leader，然后還會(huì)包含跟 Leader 保持同步的 Follower。

也就是說(shuō)，只要 Leader 的某個(gè) Follower 一直跟他保持?jǐn)?shù)據(jù)同步，那么就會(huì)存在于 ISR 列表里。

但是如果 Follower 因?yàn)樽陨戆l(fā)生一些問(wèn)題，導(dǎo)致不能及時(shí)的從 Leader 同步數(shù)據(jù)過(guò)去，那么這個(gè) Follower 就會(huì)被認(rèn)為是“out-of-sync”，被從 ISR 列表里踢出去。

所以大家先得明白這個(gè) ISR 是什么，說(shuō)白了，就是 Kafka 自動(dòng)維護(hù)和監(jiān)控哪些 Follower 及時(shí)的跟上了 Leader 的數(shù)據(jù)同步。

Kafka 寫(xiě)入的數(shù)據(jù)如何保證不丟失?

所以如果要讓寫(xiě)入 Kafka 的數(shù)據(jù)不丟失，你需要保證如下幾點(diǎn)：

• 每個(gè) Partition 都至少得有 1 個(gè) Follower 在 ISR 列表里，跟上了 Leader 的數(shù)據(jù)同步。
• 每次寫(xiě)入數(shù)據(jù)的時(shí)候，都要求至少寫(xiě)入 Partition Leader 成功，同時(shí)還有至少一個(gè) ISR 里的 Follower 也寫(xiě)入成功，才算這個(gè)寫(xiě)入是成功了。
• 如果不滿足上述兩個(gè)條件，那就一直寫(xiě)入失敗，讓生產(chǎn)系統(tǒng)不停的嘗試重試，直到滿足上述兩個(gè)條件，然后才能認(rèn)為寫(xiě)入成功。
• 按照上述思路去配置相應(yīng)的參數(shù)，才能保證寫(xiě)入 Kafka 的數(shù)據(jù)不會(huì)丟失。

好!現(xiàn)在咱們來(lái)分析一下上面幾點(diǎn)要求。

***條，必須要求至少一個(gè) Follower 在 ISR 列表里。

那必須的啊，要是 Leader 沒(méi)有 Follower 了，或者是 Follower 都沒(méi)法及時(shí)同步 Leader 數(shù)據(jù)，那么這個(gè)事兒肯定就沒(méi)法弄下去了。

第二條，每次寫(xiě)入數(shù)據(jù)的時(shí)候，要求 Leader 寫(xiě)入成功以外，至少一個(gè) ISR 里的 Follower 也寫(xiě)成功。

大家看下面的圖，這個(gè)要求就是保證說(shuō)，每次寫(xiě)數(shù)據(jù)，必須是 Leader 和 Follower 都寫(xiě)成功了，才能算是寫(xiě)成功，保證一條數(shù)據(jù)必須有兩個(gè)以上的副本。

這個(gè)時(shí)候萬(wàn)一 Leader 宕機(jī)，就可以切換到那個(gè) Follower 上去，那么 Follower 上是有剛寫(xiě)入的數(shù)據(jù)的，此時(shí)數(shù)據(jù)就不會(huì)丟失了。

如上圖所示，假如現(xiàn)在 Leader 沒(méi)有 Follower 了，或者是剛寫(xiě)入 Leader，Leader 立馬就宕機(jī)，還沒(méi)來(lái)得及同步給 Follower。

在這種情況下，寫(xiě)入就會(huì)失敗，然后你就讓生產(chǎn)者不停的重試，直到 Kafka 恢復(fù)正常滿足上述條件，才能繼續(xù)寫(xiě)入。這樣就可以讓寫(xiě)入 Kafka 的數(shù)據(jù)不丟失。

總結(jié)

***總結(jié)一下，其實(shí) Kafka 的數(shù)據(jù)丟失問(wèn)題，涉及到方方面面。

譬如生產(chǎn)端的緩存問(wèn)題，包括消費(fèi)端的問(wèn)題，同時(shí) Kafka 自己內(nèi)部的底層算法和機(jī)制也可能導(dǎo)致數(shù)據(jù)丟失。

但是平時(shí)寫(xiě)入數(shù)據(jù)遇到比較大的一個(gè)問(wèn)題，就是 Leader 切換時(shí)可能導(dǎo)致數(shù)據(jù)丟失。所以本文僅僅是針對(duì)這個(gè)問(wèn)題說(shuō)了一下生產(chǎn)環(huán)境解決這個(gè)問(wèn)題的方案。