目錄

前言：

?消息丟失的場(chǎng)景

?生產(chǎn)者消息丟失

Broker消息丟失?

消費(fèi)者消息丟失?

?消息丟失問題排查

無消息丟失配置：

參考資料：

前言：

? ? ? 使用消息中間件時(shí)，我們遇到最頭疼的事就消息丟失，小則影響程序錯(cuò)誤，大則影響到某個(gè)重要業(yè)務(wù)失敗。如果kafka配置不當(dāng)或者使用不當(dāng)，是很有可能出現(xiàn)消息丟失的。本篇博文重點(diǎn)探討主要的kafka消息丟失的場(chǎng)景及我們應(yīng)該如何配置kafka參數(shù)來避免消息的丟失。

?消息丟失的場(chǎng)景

? ? ? 消息丟失無非分為3種，生產(chǎn)端消息丟失、kafka-broker端消息丟失、服務(wù)端消息丟失。

Kafka對(duì)于消息丟失這件事，只做了如下承諾，kafka只對(duì)已提交的消息做有限度的持久化保證。

?生產(chǎn)者消息丟失

? ? ? 那生產(chǎn)者丟失，大多數(shù)就是因?yàn)?，生產(chǎn)者不確定消息是否已經(jīng)提交成功。如果使用不帶

回調(diào)通知的send方法的話producer.send(msg)，就無法保證消息被成功。所以我們應(yīng)該使用帶回調(diào)函數(shù)的send方法producer.send(msg,callback),這樣我們就可以監(jiān)聽消息的發(fā)送情況，然后做有效的重試，確保消息都發(fā)送成功。

Broker消息丟失?

?? 對(duì)于kafka服務(wù)器端消息丟失，相對(duì)來說概率是比較小的，kafka作為一個(gè)成熟的中間件，經(jīng)受業(yè)界的認(rèn)可，但是需要注意，消息在borker中是由存在時(shí)長的，超過這個(gè)時(shí)間，默認(rèn)會(huì)刪除這些消息，另外對(duì)于分區(qū)的副本數(shù)也要進(jìn)行合理設(shè)計(jì)，避免因?yàn)槟骋慌_(tái)機(jī)器的硬盤別破壞掉后，導(dǎo)致消息丟失。

消費(fèi)者消息丟失?

? ? ?消費(fèi)者消費(fèi)丟失，大多數(shù)的場(chǎng)景為位移提交出現(xiàn)了問題，比如在消費(fèi)者異步多線程消費(fèi)消息，其中有個(gè)處理失敗，位移提交失敗，就會(huì)導(dǎo)致這個(gè)線程處理的消息丟失。??

?消息丟失問題排查

? ? 對(duì)于消息丟失的問題，首先，我們應(yīng)該建立完整的日志，在消息發(fā)送前和發(fā)送后 、消費(fèi)前后分別計(jì)日志，?建立告警機(jī)制。

無消息丟失配置：

1. 不要使用producer.send(msg)，而要使用producer.send(msg, callback)。記住，一定要使用帶有回調(diào)通知的send方法。
2. 設(shè)置acks = all。acks是Producer的一個(gè)參數(shù)，代表了你對(duì)“已提交”消息的定義。如果設(shè)置成all，則表明所有副本Broker都要接收到消息，該消息才算是“已提交”。這是最高等級(jí)的“已提交”定義。
3. 設(shè)置retries為一個(gè)較大的值。這里的retries同樣是Producer的參數(shù)，對(duì)應(yīng)前面提到的Producer自動(dòng)重試。當(dāng)出現(xiàn)網(wǎng)絡(luò)的瞬時(shí)抖動(dòng)時(shí)，消息發(fā)送可能會(huì)失敗，此時(shí)配置了retries > 0的Producer能夠自動(dòng)重試消息發(fā)送，避免消息丟失。
4. 設(shè)置unclean.leader.election.enable = false。這是Broker端的參數(shù)，它控制的是哪些Broker有資格競(jìng)選分區(qū)的Leader。如果一個(gè)Broker落后原先的Leader太多，那么它一旦成為新的Leader，必然會(huì)造成消息的丟失。故一般都要將該參數(shù)設(shè)置成false，即不允許這種情況的發(fā)生。
5. 設(shè)置replication.factor >= 3。這也是Broker端的參數(shù)。其實(shí)這里想表述的是，最好將消息多保存幾份，畢竟目前防止消息丟失的主要機(jī)制就是冗余。
6. 設(shè)置min.insync.replicas > 1。這依然是Broker端參數(shù)，控制的是消息至少要被寫入到多少個(gè)副本才算是“已提交”。設(shè)置成大于1可以提升消息持久性。在實(shí)際環(huán)境中千萬不要使用默認(rèn)值1。
7. 確保replication.factor > min.insync.replicas。如果兩者相等，那么只要有一個(gè)副本掛機(jī)，整個(gè)分區(qū)就無法正常工作了。我們不僅要改善消息的持久性，防止數(shù)據(jù)丟失，還要在不降低可用性的基礎(chǔ)上完成。推薦設(shè)置成replication.factor = min.insync.replicas + 1。
8. 確保消息消費(fèi)完成再提交。Consumer端有個(gè)參數(shù)enable.auto.commit，最好把它設(shè)置成false，并采用手動(dòng)提交位移的方式。就像前面說的，這對(duì)于單Consumer多線程處理的場(chǎng)景而言是至關(guān)重要的。

參考資料：

?極客時(shí)間課程《kafka核心技術(shù)與實(shí)戰(zhàn)》第11課

無消息丟失配置如何實(shí)現(xiàn)？文章來源地址http://www.zghlxwxcb.cn/news/detail-595875.html

到了這里，關(guān)于kafka無消息丟失配置的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！