Kafka 在很長(zhǎng)一段時(shí)間里都被當(dāng)成消息中間件里的“天花板”來(lái)用吞吐量高、可擴(kuò)展性好、還能做存儲(chǔ)。但凡是線上實(shí)際用過(guò) Kafka 的團(tuán)隊(duì)幾乎都經(jīng)歷過(guò)一次“到底丟沒丟消息”的爭(zhēng)論。有人說(shuō)是 Kafka 的問題有人說(shuō)是自己代碼的問題還有人說(shuō)是網(wǎng)絡(luò)抖動(dòng)導(dǎo)致的偶發(fā)故障。實(shí)際上我做了這么多年 Kafka 相關(guān)的項(xiàng)目結(jié)論非常明確Kafka 本身很少會(huì)“無(wú)理由丟消息”絕大多數(shù)丟消息的根源都出在生產(chǎn)者配置、消費(fèi)者提交位點(diǎn)的時(shí)機(jī)以及你對(duì)確認(rèn)機(jī)制的理解上。這篇文章我會(huì)從生產(chǎn)端、Broker 端、消費(fèi)端三個(gè)鏈路分別拆解把“丟消息”這件事徹底講透。不管你是在做日志采集、實(shí)時(shí)數(shù)倉(cāng)還是普通的后端消息推送這篇內(nèi)容都值得對(duì)照你當(dāng)前的配置逐條查一遍。你會(huì)發(fā)現(xiàn)很多丟消息不是玄學(xué)而是配置和代碼寫得不夠謹(jǐn)慎。1. 先說(shuō)結(jié)論丟消息從來(lái)都不是 Kafka 一個(gè)環(huán)節(jié)的問題1.1 我對(duì)“Kafka 丟消息”這句話的理解很多人一搜“Kafka 丟消息”第一反應(yīng)是 Kafka 這個(gè)中間件本身有沒有 bug。其實(shí) Kafka 作為分布式系統(tǒng)單從設(shè)計(jì)上講它已經(jīng)盡最大努力去保證消息不丟了。問題在于這個(gè)“保證”是有前提條件的比如生產(chǎn)者要設(shè)置合理的確認(rèn)機(jī)制、Broker 端要有足夠的副本數(shù)、消費(fèi)者要自己管理好偏移量。你如果把保證可靠性的責(zé)任全部甩給 Kafka自己代碼里毫不在意地往生產(chǎn)端一塞、消費(fèi)端一拉那丟消息幾乎是必然的。所以我的第一句話永遠(yuǎn)是Kafka 不丟消息是有條件的你要做的不是問 Kafka 為什么丟而是問自己在哪個(gè)環(huán)節(jié)破壞了它的可靠性邊界。1.2 先想清楚消息從進(jìn)到出要經(jīng)過(guò)哪幾道門一條消息從業(yè)務(wù)系統(tǒng)產(chǎn)生到最終被下游消費(fèi)者處理完整的路徑是生產(chǎn)者把消息發(fā)送給 Kafka BrokerBroker 把消息寫入分區(qū)對(duì)應(yīng)的日志文件并完成副本同步消費(fèi)者從 Broker 拉取消息處理業(yè)務(wù)邏輯消費(fèi)者提交偏移量offset確認(rèn)這條消息已經(jīng)被消費(fèi)。這里面每一道門都有可能把消息弄丟。生產(chǎn)端可能因?yàn)榘l(fā)送失敗、回調(diào)沒處理、緩沖區(qū)滿了而丟Broker 端可能因?yàn)樗⒈P不及時(shí)、副本同步失敗、Leader 切換而丟消費(fèi)端可能因?yàn)槲稽c(diǎn)提交太快、程序崩潰、重平衡而丟。你光盯著某一端排查是沒用的。我見過(guò)不少團(tuán)隊(duì) debug 了好幾天最后發(fā)現(xiàn)是消費(fèi)端業(yè)務(wù)異常導(dǎo)致位點(diǎn)已經(jīng)提交了但消息沒處理完成這種“假成功”最容易讓人誤以為是 Kafka 在丟消息。所以先建立這個(gè)全局鏈路認(rèn)知后面排查起來(lái)才有方向。2. 生產(chǎn)端你還沒發(fā)出去消息就已經(jīng)丟了2.1 acks0 的代價(jià)說(shuō)發(fā)就發(fā)后果自負(fù)生產(chǎn)者端第一個(gè)經(jīng)典坑就是 acks 配置。如果你把a(bǔ)cks設(shè)成 0意味著生產(chǎn)者不需要等待 Broker 的任何確認(rèn)消息發(fā)出去就算完事。這個(gè)配置下吞吐量最高但代價(jià)就是只要網(wǎng)絡(luò)發(fā)生抖動(dòng)、請(qǐng)求還沒到 Broker或者 Broker 寫入過(guò)程中出現(xiàn)問題生產(chǎn)者這邊完全無(wú)感知。我實(shí)際幫團(tuán)隊(duì)排查過(guò)一個(gè)采集系統(tǒng)的丟數(shù)據(jù)問題客戶端采集到日志后直接往 Kafka 里懟配置里acks0結(jié)果高峰期數(shù)據(jù)丟失率在 0.5% 左右看著不高但對(duì)于需要精準(zhǔn)對(duì)賬的業(yè)務(wù)來(lái)說(shuō)完全不可接受。后來(lái)把a(bǔ)cks改成 1丟失率立刻降下來(lái)了。在這個(gè)配置下你所謂“發(fā)消息成功”只是客戶端把數(shù)據(jù)交給了 socket 緩沖區(qū)并不是真的寫到了 Kafka。所以生產(chǎn)環(huán)境里除了極少數(shù)允許丟失的監(jiān)控指標(biāo)類數(shù)據(jù)我認(rèn)為一般不要用acks0。真到了丟不起的場(chǎng)合再回來(lái)的查證成本遠(yuǎn)高于那點(diǎn)吞吐量收益。2.2 acks1 的中間地帶Leader 掛了你就傻眼acks1是很多團(tuán)隊(duì)里的默認(rèn)選擇意思是生產(chǎn)者只需要等 Leader 副本寫入成功就返回成功。這個(gè)配置在實(shí)際吞吐量和可靠性之間確實(shí)比較均衡很多業(yè)務(wù)也都跑在這種模式下。但你要清楚它的死角如果 Leader 在寫入完成后、還沒等其他副本同步的時(shí)候掛了這條消息對(duì)消費(fèi)者來(lái)說(shuō)就是“丟失”的。舉個(gè)例子你給主題配置了一個(gè)分區(qū)三個(gè)副本某臺(tái)機(jī)器上的 Leader 副本把消息寫盤后數(shù)據(jù)還沒同步到其他兩個(gè) Follower結(jié)果這臺(tái)機(jī)器突然斷電。Kafka 會(huì)從剩下的 Follower 里選一個(gè)新的 Leader之前那批沒有同步完成的消息就永遠(yuǎn)沒了。在這個(gè)環(huán)節(jié)你要是只盯著生產(chǎn)者有沒有收到成功回調(diào)那是不夠的。acks1只保證“那一刻的 Leader 寫入成功”不保證這條消息在集群里永久存活。對(duì)于賬務(wù)類、訂單類這種強(qiáng)一致場(chǎng)景我建議直接上acksall別太摳那一點(diǎn)點(diǎn)延遲。2.3 最穩(wěn)妥的 acksall選對(duì) ISR 才是關(guān)鍵acksall也不是無(wú)敵的很多人的理解是“設(shè)成 all 就絕對(duì)不丟了”這其實(shí)是個(gè)誤區(qū)。acksall的含義是 Leader 必須等待當(dāng)前 ISRIn-Sync Replica同步中副本集合里的所有副本都寫入成功才返回成功。注意ISR 集合是動(dòng)態(tài)變化的。如果一個(gè) Follower 跟不上水位它會(huì)被踢出 ISR那么acksall實(shí)際上只需要等 ISR 里剩下的那些副本確認(rèn)。極端情況下ISR 里只有 Leader 自己這時(shí)候acksall的可靠性就退化成acks1了。所以我有一個(gè)習(xí)慣性建議把min.insync.replicas這個(gè)參數(shù)設(shè)置好比如設(shè)置成 2。它的作用是最少要有多少個(gè) ISR 副本在線否則分區(qū)直接不可寫。這樣配合acksall可靠性才能真正兜住底。不要只改一個(gè)參數(shù)這倆是配套的少了誰(shuí)都有漏洞。2.4 異步發(fā)送、緩沖區(qū)和超時(shí)三個(gè)隱藏的地雷除了 acks生產(chǎn)端還有三個(gè)隱藏炸彈異步發(fā)送、max.block.ms、buffer.memory。很多人寫代碼時(shí)喜歡用異步發(fā)送因?yàn)橥桨l(fā)送在 Broker 繁忙時(shí)會(huì)有明顯的 RT 上漲。異步發(fā)送本身沒問題問題在于很多人發(fā)了消息之后沒有正確注冊(cè)回調(diào)或者回調(diào)里只是打了行日志就沒后續(xù)。消息發(fā)送失敗后你毫無(wú)感知這對(duì)“丟沒丟消息”的判斷是致命的。緩沖區(qū)參數(shù)也一樣。如果生產(chǎn)者的buffer.memory設(shè)置太小或者max.block.ms設(shè)置得過(guò)于保守在業(yè)務(wù)洪峰來(lái)臨時(shí)KafkaProducer 會(huì)直接拋出異常。如果你沒做重試和補(bǔ)償這條消息就靜默丟失了。建議把異常處理落到實(shí)處發(fā)送失敗至少要有重試機(jī)制而且重試時(shí)必須關(guān)注enable.idempotence冪等生產(chǎn)者避免重試造成消息重復(fù)。3. 服務(wù)端Broker 層面的丟失其實(shí)最容易被忽視3.1 刷盤策略斷電的一瞬間內(nèi)存里的都白寫B(tài)roker 端的第一個(gè)“丟消息”隱患就是刷盤策略。Kafka 利用操作系統(tǒng) PageCache 來(lái)提升寫入性能生產(chǎn)數(shù)據(jù)會(huì)先寫入 PageCache再由系統(tǒng)異步刷到磁盤。這個(gè)機(jī)制在絕大多數(shù)情況下都沒問題性能高、吞吐大。但一旦發(fā)生斷電或者內(nèi)核崩潰PageCache 里還沒有落盤的數(shù)據(jù)就會(huì)全部丟失。有些團(tuán)隊(duì)會(huì)調(diào)整log.flush.interval.messages和log.flush.interval.ms來(lái)強(qiáng)制更頻繁地刷盤但這兩個(gè)參數(shù)和吞吐量是沖突的。你不能又想要極致吞吐又想要斷電不丟數(shù)據(jù)這不現(xiàn)實(shí)。我實(shí)際遇到的案例里很多公司壓根沒注意日志目錄的磁盤是不是 SSD、IO 是否穩(wěn)定。磁盤性能差會(huì)導(dǎo)致 Follower 復(fù)制延遲升高進(jìn)而被踢出 ISR最終影響整個(gè)分區(qū)的可用性。這里我想跟大家說(shuō)的經(jīng)驗(yàn)是不要把 Kafka 部署在性能很差的云盤上否則你會(huì)遇到各種詭異的消息延遲和副本同步問題。3.2 副本數(shù)是 2丟一半的概率可不算小很多人創(chuàng)建主題時(shí)只設(shè)置了 1 個(gè)副本或者圖省錢只設(shè) 2 個(gè)副本。副本是 1 的時(shí)候機(jī)器一掛分區(qū)數(shù)據(jù)全沒這種場(chǎng)景已經(jīng)不能叫“丟消息”了應(yīng)該叫“數(shù)據(jù)毀滅”。副本數(shù)設(shè)置為 2其實(shí)也并沒有好到哪里去因?yàn)樗荒苋萑桃慌_(tái)機(jī)器故障遇到機(jī)房級(jí)別的斷電依然可能同時(shí)掛掉兩個(gè)副本。我自己在給項(xiàng)目做容量規(guī)劃的時(shí)候一般建議核心業(yè)務(wù)主題至少 3 個(gè)副本。如果你說(shuō)我資源緊張至少保證min.insync.replicas2并且磁盤、機(jī)器盡量分散到不同的故障域。記住一個(gè)核心原則可靠性是設(shè)計(jì)出來(lái)的不是運(yùn)氣碰出來(lái)的。你可以用最小副本數(shù)跑測(cè)試環(huán)境但生產(chǎn)環(huán)境請(qǐng)別抱僥幸心理。另外想說(shuō)一下副本數(shù)不是設(shè)置完就完事的。Kafka 的副本分布和機(jī)器的機(jī)架信息有關(guān)如果所有副本恰好都分配在同一臺(tái)物理機(jī)上那等于沒有副本。你可以通過(guò)kafka-reassign-partitions.sh來(lái)做副本重分配至少看一眼分區(qū)副本的分布情況再上線。3.3 Leader 選舉與 ISR 收縮你以為的高可用是暫時(shí)的一條消息能不能被安全消費(fèi)其實(shí)取決于它是否完成了“高水位”同步。高水位就是所有 ISR 副本都同步到的位置。如果你的消費(fèi)者只讀取了 Leader 上的數(shù)據(jù)而一條消息還沒來(lái)得及同步到所有副本Leader 掛掉時(shí)新選舉出來(lái)的 Leader 上可能沒有這條消息消費(fèi)端就會(huì)覺得消息丟了。還有一個(gè)很多初學(xué)者會(huì)忽視的點(diǎn)Leader 切換時(shí)消息的偏移量可能會(huì)重置。比如舊 Leader 上有 offset 是 0~100 的數(shù)據(jù)但新 Leader 只同步到了 offset 80那么舊 Leader 上 80~100 的數(shù)據(jù)對(duì)客戶端來(lái)說(shuō)就是“被丟了”。嚴(yán)格意義上說(shuō)這不是 Kafka 丟了你的消息而是你讀取的是一個(gè)并不完整的副本數(shù)據(jù)。所以我們要依賴min.insync.replicas和 ISR 機(jī)制把“數(shù)據(jù)未完整同步前不可用”變成硬約束。你可以把 ISR 收縮、Leader 切換的日志全部打開來(lái)觀察一旦發(fā)現(xiàn) ISR 頻繁變化就要注意了這往往意味著某臺(tái)機(jī)器磁盤 IO 很高、GC 停頓嚴(yán)重或者網(wǎng)絡(luò)有問題。表面上是在“丟消息”實(shí)質(zhì)上是在“丟副本”。3.4 日志清理和配額別讓物理資源替你“丟消息”還有一個(gè)冷門但真實(shí)會(huì)發(fā)生的場(chǎng)景日志清理。Kafka 的主題默認(rèn)開啟了日志刪除機(jī)制超過(guò)retention.ms或者超過(guò)retention.bytes的舊數(shù)據(jù)會(huì)被自動(dòng)清理。如果你消費(fèi)端掛了好幾天回來(lái)繼續(xù)消費(fèi)的時(shí)候發(fā)現(xiàn)從頭開始讀已經(jīng)讀不到多少數(shù)據(jù)了那不是 Kafka 丟消息而是消息被過(guò)期清理了。這種問題常發(fā)生在測(cè)試環(huán)境或者運(yùn)維不規(guī)范的團(tuán)隊(duì)里。消費(fèi)者離線太久清理線程把舊日志都刪掉了。我建議你根據(jù)數(shù)據(jù)保留需求設(shè)置合理的retention.ms同時(shí)監(jiān)控消費(fèi)組 Lag 的監(jiān)控指標(biāo)發(fā)現(xiàn) Lag 持續(xù)增長(zhǎng)就要及時(shí)處理別等消息被清理了再去找原因。還有一種情況是磁盤空間被打滿導(dǎo)致日志寫入失敗Kafka 會(huì)直接停止接受寫入。這個(gè)場(chǎng)景比較像“丟消息”其實(shí)是集群進(jìn)入保護(hù)狀態(tài)。日常運(yùn)維中必須為日志目錄預(yù)留充足的空間并配置好磁盤使用率告警別讓物理資源掐住了消息通道的脖子。4. 消費(fèi)端處理不掉的“丟”其實(shí)是消費(fèi)位點(diǎn)的問題4.1 自動(dòng)提交位點(diǎn)程序一崩一批消息直接“丟了”消費(fèi)端的“丟消息”往往最具有迷惑性因?yàn)樗诤芏鄷r(shí)候表現(xiàn)為“消費(fèi)者明明拉取了消息結(jié)果卻像沒有消費(fèi)過(guò)一樣”。最經(jīng)典的場(chǎng)景就是開啟enable.auto.committrue默認(rèn)每 5 秒自動(dòng)提交一次消費(fèi)位點(diǎn)。想象一個(gè)場(chǎng)景消費(fèi)者把一批消息拉了下來(lái)業(yè)務(wù)處理過(guò)程中 Redis 超時(shí)代碼拋了異常于是這批消息還沒有處理完但 Kafka 客戶端的后臺(tái)線程已經(jīng)按照落地時(shí)間提交了 offset。等重啟消費(fèi)者之后Kafka 會(huì)認(rèn)為這批消息已經(jīng)消費(fèi)完畢直接跳到后面去了。你的業(yè)務(wù)數(shù)據(jù)缺失看起來(lái)就像 Kafka 把消息丟了。最讓我無(wú)語(yǔ)的是有些團(tuán)隊(duì)把錯(cuò)誤處理邏輯做成打日志然后繼續(xù)消費(fèi)這樣連“消費(fèi)失敗”的痕跡都看不到。下游數(shù)據(jù)對(duì)不上賬的時(shí)候翻業(yè)務(wù)日志全是異常后跳過(guò)繼續(xù)往下走的記錄。這里我給大家一個(gè)最基礎(chǔ)也最有效的建議核心業(yè)務(wù)里不要自動(dòng)提交位點(diǎn)手動(dòng)提交并且做到“先處理完業(yè)務(wù)再提交 offset”。4.2 enable.auto.commitfalse 真的就不丟了嗎手動(dòng)提交位點(diǎn)解決了“處理一半就提交”的問題但如果你用手動(dòng)提交的方式又容易引發(fā)另一個(gè)常見問題位點(diǎn)提交失敗。比如你的消費(fèi)者處理完一條消息準(zhǔn)備提交 offset 的時(shí)候剛好發(fā)生 Rebalance這時(shí)第一次提交失敗。如果你沒做重試重啟之后就會(huì)從這個(gè)舊位點(diǎn)重新消費(fèi)。這種情況和“丟消息”相反它會(huì)導(dǎo)致“重復(fù)消費(fèi)”而不是消息丟失。但引出的另一個(gè)極端是有些人為了追求效率在業(yè)務(wù)處理之前就提前提交 offset這樣下一次消費(fèi)者掛掉時(shí)這些消息就永遠(yuǎn)不會(huì)再被讀到。這不叫丟但在業(yè)務(wù)效果上跟丟了一模一樣。所以我特別想強(qiáng)調(diào)一個(gè)觀點(diǎn)在 Kafka 的消費(fèi)模型里“不丟消息”和“不重復(fù)消息”這倆目標(biāo)本質(zhì)上就是沖突的。你只能選擇“至少一次”或者“恰好一次”沒有完美的中間態(tài)。如果業(yè)務(wù)要求絕對(duì)不能丟那你就要接受可能會(huì)有重復(fù)并且在消費(fèi)端做冪等。比如用 Redis 記錄消息唯一 ID或者直接把冪等判斷做到數(shù)據(jù)庫(kù)里。4.3 重平衡踢你出群的那一刻消息去哪里了重平衡Rebalance是消費(fèi)端丟消息的另一個(gè)重災(zāi)區(qū)。Kafka 消費(fèi)者通過(guò)消費(fèi)組協(xié)調(diào)分區(qū)分配當(dāng)消費(fèi)者數(shù)量變化、消費(fèi)組訂閱關(guān)系變化或者消費(fèi)者心跳超時(shí)的時(shí)候會(huì)觸發(fā)重平衡。重平衡本身不是問題問題在于重平衡發(fā)生時(shí)未提交位點(diǎn)的分區(qū)會(huì)被重新分配給其他消費(fèi)者。打個(gè)比方分區(qū) 0 之前分配給了消費(fèi)者 AA 拉了幾百條消息正在處理還沒提交位點(diǎn)結(jié)果網(wǎng)絡(luò)抖動(dòng)消費(fèi)組觸發(fā)了重平衡分區(qū) 0 分給了消費(fèi)者 B。B 會(huì)從上次提交的位點(diǎn)開始消費(fèi)那些 A 拉下來(lái)但沒來(lái)得及落庫(kù)的數(shù)據(jù)就“丟”了。當(dāng)然現(xiàn)代 Kafka 的協(xié)同式重平衡已經(jīng)比老版本溫和了不少但老版本的問題在新版本里依然可能因?yàn)樾奶瑫r(shí)、session.timeout.ms設(shè)置不合理而出現(xiàn)。我給團(tuán)隊(duì)的建議是不要把max.poll.records調(diào)得過(guò)大單次拉取太多消息處理時(shí)間太長(zhǎng)容易導(dǎo)致消費(fèi)者超過(guò)max.poll.interval.ms被判定為不可用從而觸發(fā)重平衡。4.4 從“至少一次”到“恰好一次”別把丟和重混為一談最后一條是關(guān)于語(yǔ)義邊界的認(rèn)知。很多人說(shuō)“我想做到不丟消息”其實(shí)他們內(nèi)心的真實(shí)訴求是“我一條消息都不多、一條都不少”。要做到一條都不少需要引入 Kafka 的冪等生產(chǎn)者和事務(wù)機(jī)制配合消費(fèi)端的冪等消費(fèi)也就是端到端恰好一次。但這里有一個(gè)現(xiàn)實(shí)問題絕大多數(shù)業(yè)務(wù)系統(tǒng)追求的是“至少一次”加上消費(fèi)端的業(yè)務(wù)冪等。比如你用訂單號(hào)做主鍵做 upsert重復(fù)插入和插入一次效果一樣你就不怕重復(fù)消費(fèi)。反而是一味追求事務(wù)機(jī)制會(huì)帶來(lái)比較大的性能損耗和實(shí)現(xiàn)復(fù)雜度。站在我個(gè)人的角度除非你是做支付、對(duì)賬一類強(qiáng)一致系統(tǒng)否則優(yōu)先采用“生產(chǎn)冪等 消費(fèi)冪等”這個(gè)組合性價(jià)比最高。搞清楚語(yǔ)義邊界你才不會(huì)被“丟消息”和“重復(fù)消息”這兩個(gè)詞來(lái)回繞暈。排查問題的時(shí)候要搞清楚用戶說(shuō)的“丟”到底是真的丟了還是重復(fù)消費(fèi)中被掩蓋了還是只是延遲變高導(dǎo)致看起來(lái)像是沒消息。這一步清晰了很多時(shí)候你根本不需要調(diào)一堆參數(shù)。5. 排查實(shí)錄遇到丟消息我是怎么一步步查的5.1 第一步先分清楚是“沒生產(chǎn)成功”還是“沒消費(fèi)到”排查丟消息最忌諱一上來(lái)就翻 Kafka 源碼或者亂調(diào)參數(shù)。我自己的固定套路是先分域到底是生產(chǎn)端沒發(fā)出去Broker 端沒存住還是消費(fèi)端沒消費(fèi)掉。生產(chǎn)端好判斷你只要看生產(chǎn)者日志里有沒有異?；卣{(diào)里有沒有記錄失敗消息。如果回調(diào)里記錄了大量失敗那問題就定位在生產(chǎn)端先看max.block.ms是否觸發(fā)、重試次數(shù)是否不夠、目標(biāo) topic 是否存在。如果回調(diào)都是空的可以去 Broker 端看這個(gè) topic 的落盤總消息數(shù)。消費(fèi)端則要看消費(fèi)組的 Lag。用命令行工具執(zhí)行kafka-consumer-groups.sh --describe --group xxx觀察每條分區(qū)的CURRENT-OFFSET和LOG-END-OFFSET。如果 Lag 很高說(shuō)明消息沒被及時(shí)消費(fèi)完先排查消費(fèi)者是否有異常退出。如果 Lag 是 0 但下游數(shù)據(jù)缺失那大概率是“處理失敗但提交成功”需要回源日志看業(yè)務(wù)處理狀態(tài)。5.2 第二步用數(shù)據(jù)驗(yàn)證別靠感覺很多時(shí)候大家判斷丟消息都是“感覺丟了”。比如下游說(shuō)某個(gè)時(shí)段的數(shù)據(jù)少了然后就開始抓狂。我建議遇到這種場(chǎng)景先做個(gè)端到端的數(shù)字驗(yàn)證生產(chǎn)者端統(tǒng)計(jì)發(fā)送成功總數(shù)Broker 端統(tǒng)計(jì)某個(gè) topic 的累積消息量消費(fèi)者端統(tǒng)計(jì)處理成功數(shù)。三個(gè)數(shù)字一對(duì)問題到底出在哪一段就清楚了。如果生產(chǎn)者發(fā)送成功數(shù)比 Broker 的入站消息數(shù)多那是生產(chǎn)者回調(diào)處理有問題消息實(shí)際上沒發(fā)到 Broker。如果 Broker 端有但消費(fèi)者端沒有那就是消費(fèi)端處理邏輯或提交位點(diǎn)的問題。如果 Broker 端本身就少了再繼續(xù)查副本、磁盤和 ISR 的情況。這里分享一個(gè)我常用的手法在生產(chǎn)端往消息里注入唯一 ID消費(fèi)端用這個(gè) ID 做去重和統(tǒng)計(jì)這樣幾乎可以把每條消息的流轉(zhuǎn)軌跡都撈出來(lái)。日志長(zhǎng)期留存的情況下排查“丟消息”會(huì)變得非常直觀。不要嫌麻煩這樣的投入在關(guān)鍵時(shí)刻能救你一命。5.3 第三步常見“丟消息”場(chǎng)景速查表下面是我這些年排查中遇到最常見的幾類“丟消息”場(chǎng)景直接做成速查表方便你對(duì)照自己的系統(tǒng)場(chǎng)景表現(xiàn)潛在原因核心檢查點(diǎn)生產(chǎn)端偶發(fā)超時(shí)消息缺失網(wǎng)絡(luò)抖動(dòng)、delivery.timeout.ms過(guò)小增加重試次數(shù)調(diào)大超時(shí)時(shí)間極端情況下 Leader 切換少量消息丟失acks1或acksall但min.insync.replicas太小設(shè)置acksall并配套min.insync.replicas2磁盤滿或 IO 異常寫入失敗機(jī)器磁盤容量/性能不足監(jiān)控磁盤配置告警增加節(jié)點(diǎn)消費(fèi)者重啟后部分?jǐn)?shù)據(jù)缺失自動(dòng)提交位點(diǎn)處理失敗但已提交關(guān)閉自動(dòng)提交先處理再提交消費(fèi)組重平衡后數(shù)據(jù)缺失未提交位點(diǎn) Rebalance 觸發(fā)重分配檢查心跳超時(shí)、max.poll.interval.ms消息還在但消費(fèi)不到日志過(guò)期被清理設(shè)置合理retention.ms監(jiān)控 Lag這張表不是標(biāo)準(zhǔn)答案但它基本覆蓋了日常 90% 的丟消息故障。如果你遇到的問題不在這張表里那再去翻kafka.server:typeKafkaRequestHandlerPool、RequestQueueTimeMs這些監(jiān)控指標(biāo)看有沒有請(qǐng)求積壓或者處理瓶頸。5.4 幾條我踩過(guò)坑之后留下的經(jīng)驗(yàn)第一條經(jīng)驗(yàn)是永遠(yuǎn)不要依賴環(huán)境默認(rèn)值。Kafka 的默認(rèn)配置是“均衡”的但用在你的業(yè)務(wù)上未必合適。每個(gè)團(tuán)隊(duì)都要根據(jù)自己的消費(fèi)頻率、允許延遲、數(shù)據(jù)重要性去調(diào)整配置。最好把關(guān)鍵參數(shù)固化到你們的部署模板里新項(xiàng)目直接套用。第二條經(jīng)驗(yàn)是監(jiān)控一定做在前頭。Kafka 的指標(biāo)非常多我不建議一開始就堆一堆 Dashboard先盯幾個(gè)關(guān)鍵項(xiàng)就夠了生產(chǎn)端成功消息數(shù)、消費(fèi)組 Lag 值、ISR 副本數(shù)是否健康、Broker 磁盤剩余空間。這四個(gè)指標(biāo)能覆蓋大多數(shù)丟消息預(yù)兆。第三個(gè)比較個(gè)人化的體會(huì)是不要在工作中試圖制造完美的“絕不丟失”系統(tǒng)。我見過(guò)不少同事為了追求極端可靠性設(shè)計(jì)出了一套非常復(fù)雜的事務(wù)方案最終運(yùn)行維護(hù)成本劇增反而是引入了更多故障點(diǎn)。成熟的架構(gòu)會(huì)接受“去重”而不是“杜絕重復(fù)”用冪等去消化不確定性而不是把一切都堵死在消息系統(tǒng)這層。6. 附值得長(zhǎng)期關(guān)注的 Kafka 可靠性配置清單如果你看到這里還不知道從哪里入手我直接給你一份我常用的配置清單里面每一項(xiàng)都是圍繞“降低丟消息概率”來(lái)設(shè)計(jì)的。主題級(jí)別配置replication.factor3至少也要 3 個(gè)副本核心主題別低于這個(gè)數(shù)。min.insync.replicas2保證至少有兩個(gè)副本同步完成才可寫。retention.ms要匹配消費(fèi)端的最大離線容忍時(shí)間別設(shè)太短。cleanup.policydelete保留默認(rèn)即可除非你需要 compact。生產(chǎn)者級(jí)別配置acksall。enable.idempotencetrue讓生產(chǎn)者自動(dòng)處理重復(fù)與亂序。retries設(shè)置一個(gè)較大值比如Integer.MAX_VALUE配合delivery.timeout.ms控制總時(shí)長(zhǎng)。max.in.flight.requests.per.connection在開啟冪等后可以保持默認(rèn) 5不用刻意調(diào)為 1。buffer.memory根據(jù)你的單機(jī)峰值發(fā)送量調(diào)大別默認(rèn) 32MB高峰期很容易滿。max.block.ms建議在 3000 以上不然一阻塞就拋異常。消費(fèi)者級(jí)別配置enable.auto.commitfalse手動(dòng)提交異步入庫(kù)成功后再提交。auto.offset.reset根據(jù)業(yè)務(wù)選默認(rèn)latest對(duì)新消費(fèi)組來(lái)說(shuō)會(huì)直接跳過(guò)已有消息如果你需要“從最早開始消費(fèi)”就設(shè)成earliest。max.poll.interval.ms要大于你的單次批量處理耗時(shí)余量建議至少 3 倍余量。session.timeout.ms不要太高也不要太低默認(rèn) 45 秒在很多場(chǎng)景夠用但要注意網(wǎng)絡(luò)抖動(dòng)時(shí)太短容易頻繁重平衡。這些參數(shù)不是一成不變的但你可以把它們當(dāng)成一個(gè)比較可靠的基線。業(yè)務(wù)跑起來(lái)之后再根據(jù)監(jiān)控?cái)?shù)據(jù)微調(diào)單個(gè)參數(shù)每次修改都要能說(shuō)清為什么改不要憑感覺拍腦袋。我自己就是這樣從一堆“丟消息”的事故里熬出來(lái)的希望對(duì)你有幫助。