問題描述
最近彥祖發現,有不少同學 對 acks 和 min.insync.replicas 的配置存在不少誤解.
剛好拿一個同學的問題,來好好說明一下
根據上面提的幾個問題, 整理一下幾個知識點
acks = all的概念是什么？min.insync.replicas是怎么用的？- 什么情況下會發生資料丟失的風險？
為更好的閱讀體驗,和及時的勘誤
請訪問原文鏈接：acks和min.insync.replicas配置詳解和資料丟失場景的一次討論
問題解答
acks = all
acks=0: 生產者不會等待服務器的任何確認, 該記錄將立即添加到Socket Buffer Pool 并被視為已發送，這種情況,不保證發送成功,可能會丟失資料，
acks=1: 這個保證了至少Leader副本會將資料寫入到本地日志中,不管其他副本是否寫入，所以當Leader同步成功之后,還沒有來得及同步給Follower副本就宕機了，那么就會丟失資料，
acks=-1/all: 這個確保ISR中的所有同步副本串列中都確認寫入了資料之后,才會視為發送成功, 所以這個配置可以提供最高級的資料可靠性的保證, 不會丟失資料，
但是,就算我們設定了acks=-1/all , 并且也有3個副本, 但是這個時候 Follower副本都沒有加入到ISR的集合中, ISR 只剩下了一個 Leader 副本，如果這個Leader宕機了, 是不是可能會造成磁區不可用或者資料丟失的情況了 ！
那么這種情況是不是就跟 ack=1的情況一樣了, 相當于只保證了Leader寫入了資料，還是達不到高可靠性，
那么，怎么解決這個問題呢？
是不是只需要讓 ISR 里面的同步副本 >1 就行了, 只有一個掛掉了,還有1個作為備份，
最小同步副本數 min.insync.replicas
最小同步副本數, 表示的是 ISR 串列里面最小的個數，這個是跟acks=-1/all配套使用的,默認是=1，
這個配置再加上上面的acks=-1/all是不是就可以設定高可靠性了
特別需要注意：這個配置是用來設定同步副本個數的下限的, 并不是只有 min.insync.replicas 個副本同步成功就回傳ack，
只要你acks=-1/all 就意味著你ISR里面的副本必須都要同步成功，
讀者問題解答
理解清楚了上面的知識點,那么這位朋友的問題應該就可以回答了吧，
問題：Kafka副本數設定為3，min.insync.replicas=2 ，此時AR={1,2,3} ISR={3,2,1} 0磁區的leader為3，假設當前寫入3成功，1和3同步成功，滿足ack=all 回傳客戶端寫入成功，然后leader3宕機，選舉2為leader，假設此時2剛好沒同步，是不是會出現資料丟失風險呢？
還沒結束, 來看下下面的問題,說說你的看法，
問題擴展
當Broker單副本, acks=all 的情況下
- Broker正常關機,會不會導致訊息丟失
- Broker例外crash, 會不會導致訊息丟失
- 物理機正常關機, 會不會導致訊息丟失
- 物理機例外掉電關機,會不會導致訊息丟失
群友見解 :
彥祖拙見:
- 不會丟
- 不會丟/重復資料
①. 要么他沒有成功寫入資料，但是這個時候不會回傳ack，那么producer沒有收到ack，則會嘗試重發，所以這不屬于丟書資料，
②. 它成功寫入了資料, 但是還沒有來得及回傳ack, producer會嘗試重發, 等重啟之后 可能會收到重復訊息
③. 它成功寫入資料, ack也回傳了，不會丟失資料，
注意：這里說的寫入成功，是寫入記憶體中 pagecache中 - 不會丟
- 會丟
思考上面問題的一個很重要的知識點：
kafka在寫資料的時候 默認是依賴作業系統來刷盤的，
kafka認為寫入成功不是寫入磁盤成功，而是寫到到PageCache中， 所以 ，只要不是 服務器掉電，PageCache中的記憶體資料就還在，就不會丟資料
歡迎大家,一起在評論區參與討論, 想要進群的小伙伴可以加我微信哈！
我也會把我的見解寫在評論區！
參與方式:
- 給本文「一鍵三連」 支持博主
- 周五晚上八點開獎
【編輯推薦】
參與抽獎
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/416186.html
標籤：其他
上一篇：大資料技術SpringBoot框架---實作前后端分離(MVC)對資料進行可視化
下一篇：Flink初體驗(1)