一次關(guān)于kafka數(shù)據(jù)丟失場(chǎng)景的激烈討論...

百分之80的同學(xué)都理解錯(cuò)了的小知識(shí)點(diǎn)…

問(wèn)題描述

最近彥祖發(fā)現(xiàn),有不少同學(xué) 對(duì)

acks

和

min.insync.replicas

的配置存在不少誤解.

剛好拿一個(gè)同學(xué)的問(wèn)題,來(lái)好好說(shuō)明一下

根據(jù)上面提的幾個(gè)問(wèn)題, 整理一下幾個(gè)知識(shí)點(diǎn)

acks = all的概念是什么？

min.insync.replicas 是怎么用的？

什么情況下會(huì)發(fā)生數(shù)據(jù)丟失的風(fēng)險(xiǎn)？

問(wèn)題解答

acks = all

acks=0

: 生產(chǎn)者不會(huì)等待服務(wù)器的任何確認(rèn), 該記錄將立即添加到Socket Buffer Pool 并被視為已發(fā)送，這種情況,不保證發(fā)送成功,可能會(huì)丟失數(shù)據(jù)。

acks=1

: 這個(gè)保證了至少Leader副本會(huì)將數(shù)據(jù)寫(xiě)入到本地日志中,不管其他副本是否寫(xiě)入。所以當(dāng)Leader同步成功之后,還沒(méi)有來(lái)得及同步給Follower副本就宕機(jī)了。那么就會(huì)丟失數(shù)據(jù)。

acks=-1/all

: 這個(gè)確保

ISR中的所有同步副本列表

中都確認(rèn)寫(xiě)入了數(shù)據(jù)之后,才會(huì)視為發(fā)送成功, 所以這個(gè)配置可以提供最高級(jí)的數(shù)據(jù)可靠性的保證, 不會(huì)丟失數(shù)據(jù)。

但是,就算我們?cè)O(shè)置了

acks=-1/all

, 并且也有3個(gè)副本, 但是這個(gè)時(shí)候 Follower副本都沒(méi)有加入到ISR的集合中, ISR 只剩下了一個(gè) Leader 副本。如果這個(gè)Leader宕機(jī)了, 是不是可能會(huì)造成分區(qū)不可用或者數(shù)據(jù)丟失的情況了 ！

那么這種情況是不是就跟 ack=1的情況一樣了, 相當(dāng)于只保證了Leader寫(xiě)入了數(shù)據(jù)。還是達(dá)不到高可靠性。

那么，怎么解決這個(gè)問(wèn)題呢？

是不是只需要讓 ISR 里面的同步副本 >1 就行了, 只有一個(gè)掛掉了,還有1個(gè)作為備份。

最小同步副本數(shù) min.insync.replicas

最小同步副本數(shù), 表示的是 ISR 列表里面最小的個(gè)數(shù)。這個(gè)是跟

acks=-1/all

配套使用的,默認(rèn)是=1。

這個(gè)配置再加上上面的

acks=-1/all

是不是就可以設(shè)置高可靠性了

特別需要注意：這個(gè)配置是用來(lái)設(shè)置同步副本個(gè)數(shù)的下限的, 并不是只有 min.insync.replicas 個(gè)副本同步成功就返回ack。

只要你

acks=-1/all

就意味著你ISR里面的副本必須都要同步成功。

讀者問(wèn)題解答

理解清楚了上面的知識(shí)點(diǎn),那么這位朋友的問(wèn)題應(yīng)該就可以回答了吧。

問(wèn)題：Kafka副本數(shù)設(shè)置為3，min.insync.replicas=2 ，此時(shí)AR={1,2,3} ISR={3,2,1} 0分區(qū)的leader為3，假設(shè)當(dāng)前寫(xiě)入3成功，1和3同步成功，滿(mǎn)足ack=all 返回客戶(hù)端寫(xiě)入成功，然后leader3宕機(jī)，選舉2為leader，假設(shè)此時(shí)2剛好沒(méi)同步，是不是會(huì)出現(xiàn)數(shù)據(jù)丟失風(fēng)險(xiǎn)呢？

問(wèn)題擴(kuò)展

當(dāng)Broker單副本, acks=all 的情況下

Broker正常關(guān)機(jī),會(huì)不會(huì)導(dǎo)致消息丟失

Broker異常crash, 會(huì)不會(huì)導(dǎo)致消息丟失

物理機(jī)正常關(guān)機(jī), 會(huì)不會(huì)導(dǎo)致消息丟失

物理機(jī)異常掉電關(guān)機(jī),會(huì)不會(huì)導(dǎo)致消息丟失

群友見(jiàn)解 :

彥祖拙見(jiàn):

不會(huì)丟

不會(huì)丟/重復(fù)數(shù)據(jù)

①. 要么他沒(méi)有成功寫(xiě)入數(shù)據(jù)，但是這個(gè)時(shí)候不會(huì)返回ack，那么producer沒(méi)有收到ack，則會(huì)嘗試重發(fā)，所以這不屬于丟書(shū)數(shù)據(jù)。

②. 它成功寫(xiě)入了數(shù)據(jù), 但是還沒(méi)有來(lái)得及返回ack, producer會(huì)嘗試重發(fā), 等重啟之后 可能會(huì)收到重復(fù)消息

③. 它成功寫(xiě)入數(shù)據(jù), ack也返回了，不會(huì)丟失數(shù)據(jù)。

注意：這里說(shuō)的寫(xiě)入成功，是寫(xiě)入內(nèi)存中 pagecache中

不會(huì)丟

會(huì)丟

思考上面問(wèn)題的一個(gè)很重要的知識(shí)點(diǎn)：

kafka在寫(xiě)數(shù)據(jù)的時(shí)候 默認(rèn)是依賴(lài)操作系統(tǒng)來(lái)刷盤(pán)的。

kafka認(rèn)為寫(xiě)入成功不是寫(xiě)入磁盤(pán)成功，而是寫(xiě)到到PageCache中。 所以 ，只要不是 服務(wù)器掉電，PageCache中的內(nèi)存數(shù)據(jù)就還在，就不會(huì)丟數(shù)據(jù)

歡迎大家,一起在評(píng)論區(qū)參與討論, 想要進(jìn)群的小伙伴可以加哈！

我也會(huì)把我的見(jiàn)解寫(xiě)在評(píng)論區(qū)！

Kafka 大數(shù)據(jù) 運(yùn)維

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。