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