建站
咨詢
售后
建站咨詢
新聞中心
一、背景引入
這篇文章，給大家聊一下寫入Kafka的數(shù)據(jù)該如何保證其不丟失？
站在用戶的角度思考問題，與客戶深入溝通，找到建始網(wǎng)站設(shè)計與建始網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：網(wǎng)站設(shè)計、成都網(wǎng)站制作、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、虛擬主機、企業(yè)郵箱。業(yè)務覆蓋建始地區(qū)。
看過之前的文章??《字節(jié)面試官: 讓你設(shè)計一個MQ每秒要抗幾十萬并發(fā)，怎么做？》??的同學，應該都知道寫入Kafka的數(shù)據(jù)是會落地寫入磁盤的。
我們暫且不考慮寫磁盤的具體過程，先大致看看下面的圖，這代表了Kafka的核心架構(gòu)原理。
二、Kafka分布式存儲架構(gòu)
那么現(xiàn)在問題來了，如果每天產(chǎn)生幾十TB的數(shù)據(jù)，難道都寫一臺機器的磁盤上嗎？這明顯是不靠譜的啊！
所以說，這里就得考慮數(shù)據(jù)的分布式存儲了，其實關(guān)于消息中間件的分布式存儲以及高可用架構(gòu)，之前的一篇文章??《程序員別死背面試八股文了，這種面試題才是未來主流。。?！??也分析過了，但是這里，我們結(jié)合Kafka的具體情況來說說。
在Kafka里面，有一個核心的概念叫做“Topic”，這個topic你就姑且認為是一個數(shù)據(jù)集合吧。
舉個例子，如果你現(xiàn)在有一份網(wǎng)站的用戶行為數(shù)據(jù)要寫入Kafka，你可以搞一個topic叫做“user_access_log_topic”，這里寫入的都是用戶行為數(shù)據(jù)。
然后如果你要把電商網(wǎng)站的訂單數(shù)據(jù)的增刪改變更記錄寫Kafka，那可以搞一個topic叫做“order_tb_topic”，這里寫入的都是訂單表的變更記錄。
然后假如說咱們舉個例子，就說這個用戶行為topic吧，里面如果每天寫入幾十TB的數(shù)據(jù)，你覺得都放一臺機器上靠譜嗎？
明顯不太靠譜，所以Kafka有一個概念叫做Partition，就是把一個topic數(shù)據(jù)集合拆分為多個數(shù)據(jù)分區(qū)，你可以認為是多個數(shù)據(jù)分片，每個Partition可以在不同的機器上，儲存部分數(shù)據(jù)。
這樣，不就可以把一個超大的數(shù)據(jù)集合分布式存儲在多臺機器上了嗎？大家看下圖，一起來體會一下。
三、Kafka高可用架構(gòu)
但是這個時候，我們又會遇到一個問題，就是萬一某臺機器宕機了，這臺機器上的那個partition管理的數(shù)據(jù)不就丟失了嗎？
所以說，我們還得做多副本冗余，每個Partition都可以搞一個副本放在別的機器上，這樣某臺機器宕機，只不過是Partition其中一個副本丟失。
如果某個Partition有多副本的話，Kafka會選舉其中一個Parititon副本作為Leader，然后其他的Partition副本是Follower。
只有Leader Partition是對外提供讀寫操作的，F(xiàn)ollower Partition就是從Leader Partition同步數(shù)據(jù)。
一旦Leader Partition宕機了，就會選舉其他的Follower Partition作為新的Leader Partition對外提供讀寫服務，這不就實現(xiàn)了高可用架構(gòu)了？
大家看下面的圖，看看這個過程。
四、Kafka寫入數(shù)據(jù)丟失問題
現(xiàn)在我們來看看，什么情況下Kafka中寫入數(shù)據(jù)會丟失呢？
其實也很簡單，大家都知道寫入數(shù)據(jù)都是往某個Partition的Leader寫入的，然后那個Partition的Follower會從Leader同步數(shù)據(jù)。
但是萬一1條數(shù)據(jù)剛寫入Leader Partition，還沒來得及同步給Follower，此時Leader Partiton所在機器突然就宕機了呢？
大家看下圖：
如上圖，這個時候有一條數(shù)據(jù)是沒同步到Partition0的Follower上去的，然后Partition0的Leader所在機器宕機了。
此時就會選舉Partition0的Follower作為新的Leader對外提供服務，然后用戶是不是就讀不到剛才寫入的那條數(shù)據(jù)了？
因為Partition0的Follower上是沒有同步到最新的一條數(shù)據(jù)的。
這個時候就會造成數(shù)據(jù)丟失的問題。
五、Kafka的ISR機制是什么？
現(xiàn)在我們先留著這個問題不說具體怎么解決，先回過頭來看一個Kafka的核心機制，就是ISR機制。
這個機制簡單來說，就是會自動給每個Partition維護一個ISR列表，這個列表里一定會有Leader，然后還會包含跟Leader保持同步的Follower。
也就是說，只要Leader的某個Follower一直跟他保持數(shù)據(jù)同步，那么就會存在于ISR列表里。
但是如果Follower因為自身發(fā)生一些問題，導致不能及時的從Leader同步數(shù)據(jù)過去，那么這個Follower就會被認為是“out-of-sync”，從ISR列表里踢出去。
所以大家先得明白這個ISR是什么，說白了，就是Kafka自動維護和監(jiān)控哪些Follower及時的跟上了Leader的數(shù)據(jù)同步。
六、數(shù)據(jù)如何保證不丟失？
所以如果要讓寫入Kafka的數(shù)據(jù)不丟失，你需要要求幾點：
- 每個Partition都至少得有1個Follower在ISR列表里，跟上了Leader的數(shù)據(jù)同步
- 每次寫入數(shù)據(jù)的時候，都要求至少寫入Partition Leader成功，同時還有至少一個ISR里的Follower也寫入成功，才算這個寫入是成功了
- 如果不滿足上述兩個條件，那就一直寫入失敗，讓生產(chǎn)系統(tǒng)不停的嘗試重試，直到滿足上述兩個條件，然后才能認為寫入成功
- 按照上述思路去配置相應的參數(shù)，才能保證寫入Kafka的數(shù)據(jù)不會丟失
好！現(xiàn)在咱們來分析一下上面幾點要求。
第一條，必須要求至少一個Follower在ISR列表里。
那必須的啊，要是Leader沒有Follower了，或者是Follower都沒法及時同步Leader數(shù)據(jù)，那么這個事兒肯定就沒法弄下去了。
第二條，每次寫入數(shù)據(jù)的時候，要求leader寫入成功以外，至少一個ISR里的Follower也寫成功。
大家看下面的圖，這個要求就是保證說，每次寫數(shù)據(jù)，必須是leader和follower都寫成功了，才能算是寫成功，保證一條數(shù)據(jù)必須有兩個以上的副本。
這個時候萬一leader宕機，就可以切換到那個follower上去，那么Follower上是有剛寫入的數(shù)據(jù)的，此時數(shù)據(jù)就不會丟失了。
如上圖所示，假如現(xiàn)在leader沒有follower了，或者是剛寫入leader，leader立馬就宕機，還沒來得及同步給follower。
在這種情況下，寫入就會失敗，然后你就讓生產(chǎn)者不停的重試，直到kafka恢復正常滿足上述條件，才能繼續(xù)寫入。
這樣就可以讓寫入kafka的數(shù)據(jù)不丟失。
七、總結(jié)
最后總結(jié)一下，其實kafka的數(shù)據(jù)丟失問題，涉及到方方面面。
譬如生產(chǎn)端的緩存問題，包括消費端的問題，同時kafka自己內(nèi)部的底層算法和機制也可能導致數(shù)據(jù)丟失。
但是平時寫入數(shù)據(jù)遇到比較大的一個問題，就是leader切換時可能導致數(shù)據(jù)丟失。所以本文僅僅是針對這個問題說了一下生產(chǎn)環(huán)境解決這個問題的方案。
文章名稱：面試官讓我聊聊MQ的數(shù)據(jù)丟失問題，沒想到水這么深
文章分享：http://www.5511xx.com/article/cddhshc.html
