歡迎關注個人公眾號：石杉的架構筆記（ID:shishan100）
週一至週五早8點半！精品技術文章準時送上！
精品學習資料獲取通道，參見文末
目錄
1、背景引入
2、Kafka分散式儲存架構
3、Kafka高可用架構
4、畫圖復現Kafka的寫入資料丟失問題
5、Kafka的ISR機制是什麼？
6、Kafka寫入的資料如何保證不丟失？
7、總結
（1）背景引入
這篇文章，給大家聊一下寫入Kafka的資料該如何保證其不丟失？
看過之前的文章面試官：訊息中介軟體如何實現每秒幾十萬的高併發寫入？的同學，應該都知道寫入Kafka的資料是會落地寫入磁碟的。
我們暫且不考慮寫磁碟的具體過程，先大致看看下面的圖，這代表了Kafka的核心架構原理。
（2）Kafka分散式儲存架構
那麼現在問題來了，如果每天產生幾十TB的資料，難道都寫一臺機器的磁碟上嗎？這明顯是不靠譜的啊！
所以說，這裡就得考慮資料的分散式儲存了，其實關於訊息中介軟體的分散式儲存以及高可用架構，之前的一篇文章面試一線網際網路大廠？那這道題目你必須得會！也分析過了，但是這裡，我們結合Kafka的具體情況來說說。
在Kafka裡面，有一個核心的概念叫做“Topic”，這個topic你就姑且認為是一個資料集合吧。
舉個例子，如果你現在有一份網站的使用者行為資料要寫入Kafka，你可以搞一個topic叫做“user_access_log_topic”，這裡寫入的都是使用者行為資料。
然後如果你要把電商網站的訂單資料的增刪改變更記錄寫Kafka，那可以搞一個topic叫做“order_tb_topic”，這裡寫入的都是訂單表的變更記錄。
然後假如說我們們舉個例子，就說這個使用者行為topic吧，裡面如果每天寫入幾十TB的資料，你覺得都放一臺機器上靠譜嗎？
明顯不太靠譜，所以Kafka有一個概念叫做Partition，就是把一個topic資料集合拆分為多個資料分割槽，你可以認為是多個資料分片，每個Partition可以在不同的機器上，儲存部分資料。
這樣，不就可以把一個超大的資料集合分散式儲存在多臺機器上了嗎？大家看下圖，一起來體會一下。
（3）Kafka高可用架構
但是這個時候，我們又會遇到一個問題，就是萬一某臺機器當機了，這臺機器上的那個partition管理的資料不就丟失了嗎？
所以說，我們還得做多副本冗餘，每個Partition都可以搞一個副本放在別的機器上，這樣某臺機器當機，只不過是Partition其中一個副本丟失。
如果某個Partition有多副本的話，Kafka會選舉其中一個Parititon副本作為Leader，然後其他的Partition副本是Follower。
只有Leader Partition是對外提供讀寫操作的，Follower Partition就是從Leader Partition同步資料。
一旦Leader Partition當機了，就會選舉其他的Follower Partition作為新的Leader Partition對外提供讀寫服務，這不就實現了高可用架構了？
大家看下面的圖，看看這個過程。
（4）Kafka寫入資料丟失問題
現在我們來看看，什麼情況下Kafka中寫入資料會丟失呢？
其實也很簡單，大家都知道寫入資料都是往某個Partition的Leader寫入的，然後那個Partition的Follower會從Leader同步資料。
但是萬一1條資料剛寫入Leader Partition，還沒來得及同步給Follower，此時Leader Partiton所在機器突然就當機了呢？
大家看下圖：
如上圖，這個時候有一條資料是沒同步到Partition0的Follower上去的，然後Partition0的Leader所在機器當機了。
此時就會選舉Partition0的Follower作為新的Leader對外提供服務，然後使用者是不是就讀不到剛才寫入的那條資料了？
因為Partition0的Follower上是沒有同步到最新的一條資料的。
這個時候就會造成資料丟失的問題。
（5）Kafka的ISR機制是什麼？
現在我們先留著這個問題不說具體怎麼解決，先回過頭來看一個Kafka的核心機制，就是ISR機制。
這個機制簡單來說，就是會自動給每個Partition維護一個ISR列表，這個列表裡一定會有Leader，然後還會包含跟Leader保持同步的Follower。
也就是說，只要Leader的某個Follower一直跟他保持資料同步，那麼就會存在於ISR列表裡。
但是如果Follower因為自身發生一些問題，導致不能及時的從Leader同步資料過去，那麼這個Follower就會被認為是“out-of-sync”，從ISR列表裡踢出去。
所以大家先得明白這個ISR是什麼，說白了，就是Kafka自動維護和監控哪些Follower及時的跟上了Leader的資料同步。
（6）Kafka寫入的資料如何保證不丟失？
所以如果要讓寫入Kafka的資料不丟失，你需要要求幾點：
- 每個Partition都至少得有1個Follower在ISR列表裡，跟上了Leader的資料同步
- 每次寫入資料的時候，都要求至少寫入Partition Leader成功，同時還有至少一個ISR裡的Follower也寫入成功，才算這個寫入是成功了
- 如果不滿足上述兩個條件，那就一直寫入失敗，讓生產系統不停的嘗試重試，直到滿足上述兩個條件，然後才能認為寫入成功
- 按照上述思路去配置相應的引數，才能保證寫入Kafka的資料不會丟失
好！現在我們們來分析一下上面幾點要求。
第一條，必須要求至少一個Follower在ISR列表裡。
那必須的啊，要是Leader沒有Follower了，或者是Follower都沒法及時同步Leader資料，那麼這個事兒肯定就沒法弄下去了。
第二條，每次寫入資料的時候，要求leader寫入成功以外，至少一個ISR裡的Follower也寫成功。
大家看下面的圖，這個要求就是保證說，每次寫資料，必須是leader和follower都寫成功了，才能算是寫成功，保證一條資料必須有兩個以上的副本。
這個時候萬一leader當機，就可以切換到那個follower上去，那麼Follower上是有剛寫入的資料的，此時資料就不會丟失了。
如上圖所示，假如現在leader沒有follower了，或者是剛寫入leader，leader立馬就當機，還沒來得及同步給follower。
在這種情況下，寫入就會失敗，然後你就讓生產者不停的重試，直到kafka恢復正常滿足上述條件，才能繼續寫入。
這樣就可以讓寫入kafka的資料不丟失。
（7）總結
最後總結一下，其實kafka的資料丟失問題，涉及到方方面面。
譬如生產端的快取問題，包括消費端的問題，同時kafka自己內部的底層演算法和機制也可能導致資料丟失。
但是平時寫入資料遇到比較大的一個問題，就是leader切換時可能導致資料丟失。所以本文僅僅是針對這個問題說了一下生產環境解決這個問題的方案。
End
（封面,圖源網路，侵權刪除）
掃描下方二維碼，備註：“資料”，獲取更多“祕製” 精品學習資料
一大波微服務、分散式、高併發、高可用的原創系列文章正在路上
歡迎掃描下方二維碼，持續關注：
石杉的架構筆記（id:shishan100）
十餘年BAT架構經驗傾囊相授
推薦閱讀：
2、【雙11狂歡的背後】微服務註冊中心如何承載大型系統的千萬級訪問？
3、【效能優化之道】每秒上萬併發下的Spring Cloud引數優化實戰
6、大規模叢集下Hadoop NameNode如何承載每秒上千次的高併發訪問
7、【效能優化的祕密】Hadoop如何將TB級大檔案的上傳效能優化上百倍
9、【坑爹呀！】最終一致性分散式事務如何保障實際生產中99.99%高可用？
11、【眼前一亮！】看Hadoop底層演算法如何優雅的將大規模叢集效能提升10倍以上？
16、億級流量系統架構之如何設計全鏈路99.99%高可用架構
18、大白話聊聊Java併發面試問題之volatile到底是什麼？
19、大白話聊聊Java併發面試問題之Java 8如何優化CAS效能？
20、大白話聊聊Java併發面試問題之談談你對AQS的理解？
21、大白話聊聊Java併發面試問題之公平鎖與非公平鎖是啥？
22、大白話聊聊Java併發面試問題之微服務註冊中心的讀寫鎖優化
23、網際網路公司的面試官是如何360°無死角考察候選人的？（上篇）
24、網際網路公司面試官是如何360°無死角考察候選人的？（下篇）
25、Java進階面試系列之一：哥們，你們的系統架構中為什麼要引入訊息中介軟體？
26、【Java進階面試系列之二】：哥們，那你說說系統架構引入訊息中介軟體有什麼缺點？
27、【行走的Offer收割機】記一位朋友斬獲BAT技術專家Offer的面試經歷
28、【Java進階面試系列之三】哥們，訊息中介軟體在你們專案裡是如何落地的？
29、【Java進階面試系列之四】扎心！線上服務當機時，如何保證資料100%不丟失？
30、一次JVM FullGC的背後，竟隱藏著驚心動魄的線上生產事故！
31、【高併發優化實踐】10倍請求壓力來襲，你的系統會被擊垮嗎？
32、【Java進階面試系列之五】訊息中介軟體叢集崩潰，如何保證百萬生產資料不丟失？
33、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（上）？
34、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（中）？
35、億級流量系統架構之如何在上萬併發場景下設計可擴充套件架構（下）？
37、億級流量系統架構之如何保證百億流量下的資料一致性（上）
38、億級流量系統架構之如何保證百億流量下的資料一致性（中）？
39、億級流量系統架構之如何保證百億流量下的資料一致性（下）？
40、網際網路面試必殺：如何保證訊息中介軟體全鏈路資料100%不丟失（1）
41、網際網路面試必殺：如何保證訊息中介軟體全鏈路資料100%不丟失（2）
42、面試大殺器：訊息中介軟體如何實現消費吞吐量的百倍優化？
43、高併發場景下，如何保證生產者投遞到訊息中介軟體的訊息不丟失？
45、從團隊自研的百萬併發中介軟體系統的核心設計看Java併發效能優化
46、【非廣告，純乾貨】英語差的程式設計師如何才能無障礙閱讀官方文件？
47、如果20萬使用者同時訪問一個熱點快取，如何優化你的快取架構？
48、【非廣告，純乾貨】中小公司的Java工程師應該如何逆襲衝進BAT？
50、【金三銀四跳槽季】Java工程師如何在1個月內做好面試準備？
51、【offer收割機必備】我簡歷上的Java專案都好low，怎麼辦？
52、【offer去哪了】我一連面試了十個Java崗，統統石沉大海！
53、高階Java開發必備：分散式系統的唯一id生成演算法你瞭解嗎？
54、支撐日活百萬使用者的高併發系統，應該如何設計其資料庫架構？
55、尷尬了！Spring Cloud微服務註冊中心Eureka 2.x停止維護了咋辦？
作者：石杉的架構筆記
連結：https://juejin.im/post/5c6a9f25518825787e69e70a
來源：掘金
著作權歸作者所有。商業轉載請聯絡作者獲得授權，非商業轉載請註明出處。