務(wù)代碼未等風(fēng)控結(jié)果，根因在鏈路與編排)
先說(shuō)結(jié)論這個(gè)標(biāo)題描述的現(xiàn)象本質(zhì)上不是“業(yè)務(wù)代碼沒(méi)有做延遲處理”的問(wèn)題而是消息鏈路里某個(gè)環(huán)節(jié)的耗時(shí)沒(méi)有反映到業(yè)務(wù)代碼的執(zhí)行路徑上。我排過(guò)幾次類似的問(wèn)題最后發(fā)現(xiàn)根因往往藏在 RabbitMQ 的消費(fèi)機(jī)制、下游服務(wù)耗時(shí)抖動(dòng)、甚至網(wǎng)絡(luò)連接狀態(tài)里跟業(yè)務(wù)代碼里有沒(méi)有 sleep 關(guān)系不大。把題主說(shuō)的現(xiàn)象翻譯一下風(fēng)控服務(wù)處理消息有延遲但業(yè)務(wù)代碼消費(fèi)消息時(shí)沒(méi)有等風(fēng)控結(jié)果直接就往下走了。這種情況通常出現(xiàn)在異步消息鏈路里——訂單消息先被消費(fèi)風(fēng)控結(jié)果后到業(yè)務(wù)代碼沒(méi)做阻塞等待導(dǎo)致用戶看到的業(yè)務(wù)狀態(tài)落后于實(shí)際處理節(jié)奏。要定位這個(gè)問(wèn)題得先搞清楚幾個(gè)關(guān)鍵點(diǎn)消息是什么時(shí)候被消費(fèi)的、風(fēng)控結(jié)果是通過(guò)什么通道回來(lái)的、業(yè)務(wù)代碼對(duì)消息依賴順序是怎么編排的。下面我按自己的排障思路展開(kāi)講。1. 消息鏈路延遲問(wèn)題可能出在哪個(gè)環(huán)節(jié)一條 RabbitMQ 消息從生產(chǎn)到消費(fèi)大致要經(jīng)過(guò)生產(chǎn)者發(fā)送、交換機(jī)路由、隊(duì)列存儲(chǔ)、消費(fèi)者拉取、業(yè)務(wù)處理五個(gè)階段。任何一段變慢都會(huì)表現(xiàn)為“消息處理有延遲”。但如果業(yè)務(wù)代碼本身能正常運(yùn)行、只是沒(méi)有等待風(fēng)控結(jié)果那問(wèn)題大概率不在 RabbitMQ 的基礎(chǔ)傳輸層而在業(yè)務(wù)編排層。先把消息鏈路拆開(kāi)看。生產(chǎn)者把消息發(fā)到交換機(jī)交換機(jī)按路由鍵投遞到隊(duì)列消費(fèi)者從隊(duì)列拉消息。RabbitMQ 的特性是推拉結(jié)合——消費(fèi)者訂閱隊(duì)列后broker 會(huì)主動(dòng)推送消息Basic.Deliver也可以由消費(fèi)者主動(dòng)拉取Basic.Get。大多數(shù)業(yè)務(wù)系統(tǒng)用的是推送模式這意味著 broker 是主動(dòng)把消息塞給消費(fèi)者的消費(fèi)者只要線程空閑就立刻開(kāi)始處理。這就能解釋一個(gè)現(xiàn)象業(yè)務(wù)代碼收到消息時(shí)消息本身是熱乎乎的生產(chǎn)時(shí)間和消費(fèi)時(shí)間差得很小。真正的時(shí)間差出現(xiàn)在消費(fèi)之后——業(yè)務(wù)代碼等風(fēng)控結(jié)果的那個(gè)間隙。所以排查方向要鎖定在“風(fēng)控結(jié)果通過(guò)什么方式回到業(yè)務(wù)系統(tǒng)”以及“業(yè)務(wù)代碼在等待期間做了什么”上。如果風(fēng)控結(jié)果是同步 RPC 返回的那業(yè)務(wù)代碼必然阻塞在風(fēng)控調(diào)用上不存在“沒(méi)做延遲處理”的說(shuō)法如果風(fēng)控結(jié)果是異步回調(diào)或另一個(gè)隊(duì)列消息那業(yè)務(wù)代碼就會(huì)先處理完手頭邏輯等風(fēng)控結(jié)果到了再補(bǔ)后續(xù)動(dòng)作這個(gè)設(shè)計(jì)本身就需要業(yè)務(wù)代碼具備“延遲處理”能力。所以第一層判斷是你的業(yè)務(wù)代碼到底有沒(méi)有等待風(fēng)控結(jié)果的機(jī)制如果沒(méi)有那問(wèn)題根源是消息編排邏輯缺失不是 RabbitMQ 配置問(wèn)題。如果有那就要看等待機(jī)制本身的實(shí)現(xiàn)方式以及它為什么沒(méi)生效。2. 高頻根因?yàn)槭裁达L(fēng)控慢業(yè)務(wù)代碼卻感知不到延遲順著上面的思路我總結(jié)了幾個(gè)高頻根因基本都是我在實(shí)際排障中遇到過(guò)的。第一個(gè)是消費(fèi)者線程池耗盡。假設(shè)消費(fèi)者配置了固定線程池核心線程數(shù) 10最大線程數(shù) 20。風(fēng)控服務(wù)的響應(yīng)時(shí)間從 200ms 漲到 2 秒那么每個(gè)消費(fèi)線程處理一條消息的時(shí)間從 300ms 漲到 2.5 秒。在消息量不變的情況下消費(fèi)者的實(shí)際吞吐量直接掉了一個(gè)數(shù)量級(jí)。新消息進(jìn)隊(duì)列后沒(méi)有空閑線程處理只能排隊(duì)。此時(shí)從業(yè)務(wù)側(cè)看消息延遲明顯增加但業(yè)務(wù)代碼本身沒(méi)有任何等待邏輯。這種場(chǎng)景的定位標(biāo)志是RabbitMQ 后臺(tái)的消費(fèi)者連接里Unacked 消息數(shù)持續(xù)高于線程池大小而且線程 dump 能看到大量線程阻塞在下游 RPC 調(diào)用上。第二個(gè)是消費(fèi)者手動(dòng) ack 時(shí)機(jī)太晚。很多團(tuán)隊(duì)把 ack 放在整個(gè)業(yè)務(wù)邏輯處理完成后包括異步回調(diào)、數(shù)據(jù)庫(kù)寫入、后續(xù)通知等。如果一條消息的完整處理鏈路依賴風(fēng)控結(jié)果的回調(diào)那這條消息會(huì)一直處于“未確認(rèn)”狀態(tài)。RabbitMQ 對(duì)未確認(rèn)消息有數(shù)量限制prefetch超過(guò)限制后broker 不會(huì)再向消費(fèi)者投遞新消息。表現(xiàn)就是你后臺(tái)看到消費(fèi)者在線但隊(duì)列里的 Ready 消息數(shù)不降Unacked 消息數(shù)卻很高。這個(gè)場(chǎng)景的定位標(biāo)志是消費(fèi)者進(jìn)程還在運(yùn)行但沒(méi)有消息流入CPU 占用不高業(yè)務(wù)日志里也沒(méi)有新消息的處理記錄。第三個(gè)是跨隊(duì)列消息順序錯(cuò)位。如果訂單創(chuàng)建消息和風(fēng)控結(jié)果消息在同一個(gè)隊(duì)列里那消費(fèi)順序是有保證的——先下單消息后風(fēng)控結(jié)果業(yè)務(wù)代碼可以按順序處理。但很多系統(tǒng)把這兩類消息放到不同隊(duì)列甚至不同交換機(jī)這時(shí)候 RabbitMQ 只能保證單隊(duì)列內(nèi)部有序跨隊(duì)列的順序是無(wú)法保證的。風(fēng)控結(jié)果因?yàn)榉?wù)端處理慢可能比訂單消息晚幾十秒才到。如果業(yè)務(wù)代碼在收到訂單消息后立刻執(zhí)行后續(xù)流程不等風(fēng)控結(jié)果那這個(gè)“延遲”其實(shí)是兩個(gè)隊(duì)列之間的時(shí)間差導(dǎo)致的。這種場(chǎng)景下業(yè)務(wù)代碼確實(shí)沒(méi)有做延遲處理但它也不應(yīng)該用 sleep 來(lái)解決而應(yīng)該設(shè)計(jì)成“先緩存訂單消息等風(fēng)控結(jié)果到達(dá)后合并處理”。第四個(gè)是網(wǎng)絡(luò)或連接層問(wèn)題。RabbitMQ 消費(fèi)者連接如果被防火墻或負(fù)載均衡器斷開(kāi)客戶端會(huì)自動(dòng)重連重連期間消息會(huì)堆積在隊(duì)列里。雖然網(wǎng)絡(luò)層問(wèn)題不直接等同于“風(fēng)控延遲”但它會(huì)放大延遲的感知。我遇到過(guò)一種情況RabbitMQ 集群某個(gè)節(jié)點(diǎn)發(fā)生網(wǎng)絡(luò)抖動(dòng)消費(fèi)者連接被重置重連花了幾秒鐘但這幾秒鐘里業(yè)務(wù)方收到的告警就是“消息處理延遲”。如果只看業(yè)務(wù)代碼根本找不到問(wèn)題。3. 實(shí)操?gòu)?fù)盤從現(xiàn)象到根因的完整排障路徑下面放一份我覺(jué)得比較標(biāo)準(zhǔn)的排障流程你可以對(duì)照著操作。3.1 先判斷延遲發(fā)生的位置接到“風(fēng)控有延遲”的告警后第一步不是看代碼而是看 RabbitMQ 管理后臺(tái)。打開(kāi)隊(duì)列頁(yè)面關(guān)注三個(gè)指標(biāo)Ready待消費(fèi)消息數(shù)、Unacked已投遞但未確認(rèn)消息數(shù)、Total消息總數(shù)。再配合生產(chǎn)者發(fā)送時(shí)間和消費(fèi)者實(shí)際處理時(shí)間的時(shí)間戳基本能判斷延遲發(fā)生在“生產(chǎn)到消費(fèi)之間”還是“消費(fèi)到處理完成之間”。如果 Ready 大、Unacked 小說(shuō)明消息在隊(duì)列里堆積消費(fèi)者消費(fèi)速度跟不上生產(chǎn)速度。如果 Unacked 大、Ready 小說(shuō)明消息已經(jīng)發(fā)給消費(fèi)者了但消費(fèi)者處理得慢。第三步再去看消費(fèi)者的線程池狀態(tài)。我習(xí)慣用命令抓線程棧Java 服務(wù)用jstack pid抓兩三次間隔 5 秒看哪些線程一直卡在同一個(gè)調(diào)用上。如果大量線程阻塞在風(fēng)控服務(wù)的 HTTP 調(diào)用或 RPC 調(diào)用上基本就能鎖定是下游服務(wù)變慢導(dǎo)致消費(fèi)阻塞。3.2 驗(yàn)證風(fēng)控服務(wù)接口耗時(shí)鎖定了風(fēng)控服務(wù)變慢后需要進(jìn)一步看風(fēng)控服務(wù)的監(jiān)控?cái)?shù)據(jù)。常見(jiàn)的情況有兩種風(fēng)控服務(wù)依賴的外部數(shù)據(jù)源變慢比如查詢風(fēng)控規(guī)則庫(kù)的 SQL 從 50ms 漲到 1 秒或者是風(fēng)控服務(wù)本身的連接池被打滿大量請(qǐng)求在等待空閑連接。這個(gè)環(huán)節(jié)我一般直接用風(fēng)控服務(wù)的鏈路追蹤數(shù)據(jù)看接口的 P99 延遲和下游依賴耗時(shí)分布。如果鏈路追蹤里有大段的空白時(shí)間那就是在等某個(gè)外部服務(wù)如果整個(gè)調(diào)用鏈都快唯獨(dú)整體耗時(shí)高那就是線程池排隊(duì)。這兩種根因的解決方案不一樣前者需要優(yōu)化外部依賴后者需要擴(kuò)大線程池或限流。3.3 檢查業(yè)務(wù)代碼的消息編排邏輯如果風(fēng)控服務(wù)本身響應(yīng)很快問(wèn)題還出在“業(yè)務(wù)代碼沒(méi)做延遲處理”上那就要檢查業(yè)務(wù)代碼的消息編排設(shè)計(jì)了。核心問(wèn)題是業(yè)務(wù)代碼收到訂單消息后是直接執(zhí)行后續(xù)流程還是先保存一筆待處理記錄、等風(fēng)控結(jié)果消息到達(dá)后再合并處理后者才是合理的延遲處理設(shè)計(jì)。如果業(yè)務(wù)代碼是直接往下執(zhí)行那你要加一個(gè)改造方案把“待風(fēng)控校驗(yàn)”的狀態(tài)落庫(kù)訂單消息先更新?tīng)顟B(tài)為“處理中”等風(fēng)控結(jié)果消息到達(dá)后再根據(jù)結(jié)果更新“通過(guò)”或“拒絕”。這種異步編排方式不需要 sleep也不需要阻塞等待而是通過(guò)狀態(tài)機(jī) 消息驅(qū)動(dòng)來(lái)保證最終一致性。3.4 結(jié)合監(jiān)控?cái)?shù)據(jù)確認(rèn)全鏈路耗時(shí)做完上述驗(yàn)證后最后一步是把整條鏈路的耗時(shí)拼起來(lái)看。我一般會(huì)拉一張時(shí)間線消息生產(chǎn)、消息入隊(duì)、消息投遞、消費(fèi)者收到、風(fēng)控請(qǐng)求發(fā)出、風(fēng)控響應(yīng)返回、業(yè)務(wù)狀態(tài)更新。每個(gè)時(shí)間點(diǎn)的差值就是每個(gè)環(huán)節(jié)的耗時(shí)。只要哪個(gè)環(huán)節(jié)的耗時(shí)異常一眼就能看出來(lái)。如果實(shí)測(cè)下來(lái)消息從投遞到消費(fèi)者收到只花了 20ms但風(fēng)控結(jié)果返回花了 3 秒而業(yè)務(wù)代碼在收到風(fēng)控結(jié)果前就把業(yè)務(wù)狀態(tài)更新了那問(wèn)題就再清晰不過(guò)了業(yè)務(wù)代碼沒(méi)有等待風(fēng)控結(jié)果導(dǎo)致業(yè)務(wù)狀態(tài)落后于實(shí)際風(fēng)控結(jié)果。這個(gè)情況本質(zhì)上是業(yè)務(wù)編排問(wèn)題不是 RabbitMQ 延遲問(wèn)題但表面現(xiàn)象確實(shí)是“風(fēng)控有延遲、業(yè)務(wù)代碼沒(méi)做延遲處理”。4. 常見(jiàn)問(wèn)題速查表與定位技巧現(xiàn)象優(yōu)先檢查項(xiàng)常見(jiàn)根因Ready 消息數(shù)持續(xù)增長(zhǎng)Unacked 為 0生產(chǎn)者發(fā)送速率、消費(fèi)者是否在線消費(fèi)者未訂閱隊(duì)列或路由鍵配置錯(cuò)誤Unacked 消息數(shù)持續(xù)高消費(fèi)者無(wú)明顯異常消費(fèi)者線程棧、下游調(diào)用耗時(shí)消費(fèi)線程阻塞在下游服務(wù)消息無(wú)法確認(rèn)消費(fèi)者在線但長(zhǎng)期不消費(fèi)新消息prefetch 設(shè)置、ack 策略已投遞消息未確認(rèn)達(dá)到信道未確認(rèn)上限單條消息處理正常但整體延遲高消費(fèi)者線程數(shù)、批量消費(fèi)配置消費(fèi)者并發(fā)度不足需要增加消費(fèi)者實(shí)例消息偶發(fā)延遲幾十秒無(wú)明顯規(guī)律RabbitMQ 集群狀態(tài)、網(wǎng)絡(luò)連接網(wǎng)絡(luò)抖動(dòng)、連接重建、集群分區(qū)這幾個(gè)場(chǎng)景里最容易誤判的是第二種。表面看是 RabbitMQ 隊(duì)列堆積實(shí)際根因是下游風(fēng)控服務(wù)變慢消費(fèi)者線程全部卡在等待上。我曾經(jīng)排查過(guò)一個(gè) case告警顯示某隊(duì)列 Ready 消息數(shù)從正常值漲到幾萬(wàn)條第一反應(yīng)是加消費(fèi)者實(shí)例結(jié)果加了三個(gè)實(shí)例后問(wèn)題依舊。后來(lái)抓線程棧才發(fā)現(xiàn)所有消費(fèi)者線程都阻塞在風(fēng)控服務(wù)的 RPC 調(diào)用上加實(shí)例只意味著更多線程在死等完全沒(méi)解決瓶頸。定位這個(gè)問(wèn)題的實(shí)用技巧是看兩個(gè)值RabbitMQ 后臺(tái)的“消費(fèi)者未確認(rèn)數(shù)”和“隊(duì)列 Ready 數(shù)”。如果未確認(rèn)數(shù)遠(yuǎn)大于消費(fèi)者線程數(shù)說(shuō)明消息都?jí)涸谙M(fèi)者進(jìn)程里這個(gè)時(shí)候抓線程棧比查隊(duì)列配置更有效。另外一個(gè)技巧是給消息處理鏈路的關(guān)鍵節(jié)點(diǎn)打上耗時(shí)日志從消息投遞到消費(fèi)者、到下游調(diào)用發(fā)出、到下游響應(yīng)返回分別記錄耗時(shí)。有了這三個(gè)耗時(shí)值就能定位延遲發(fā)生在消息鏈路、下游服務(wù)、還是業(yè)務(wù)代碼自身。5. 結(jié)合題主現(xiàn)象的經(jīng)驗(yàn)總結(jié)題主描述的現(xiàn)象里有一個(gè)很關(guān)鍵的線索“風(fēng)控有延遲而業(yè)務(wù)代碼沒(méi)有做延遲處理”。這說(shuō)明業(yè)務(wù)代碼缺乏對(duì)風(fēng)控結(jié)果的等待機(jī)制或者等待機(jī)制本身沒(méi)有正常觸發(fā)。這種情況的最佳實(shí)踐不是讓業(yè)務(wù)代碼 sleep 固定時(shí)間而是要讓業(yè)務(wù)狀態(tài)依賴風(fēng)控結(jié)果的狀態(tài)流轉(zhuǎn)。也就是說(shuō)業(yè)務(wù)代碼應(yīng)該具備這樣的能力收到訂單消息后把訂單狀態(tài)置為“風(fēng)控校驗(yàn)中”然后等待風(fēng)控結(jié)果消息收到結(jié)果后更新最終狀態(tài)。這個(gè)等待不是代碼層面的 sleep而是通過(guò)消息驅(qū)動(dòng)的狀態(tài)流轉(zhuǎn)。如果風(fēng)控結(jié)果遲遲不到應(yīng)該觸達(dá)超時(shí)重查機(jī)制而不是讓訂單一直卡在中間狀態(tài)。我在實(shí)際項(xiàng)目里用的方案是訂單消息先落庫(kù)狀態(tài)為“待風(fēng)控”同時(shí)發(fā)一條消息到風(fēng)控隊(duì)列等風(fēng)控結(jié)果消息回來(lái)后更新訂單狀態(tài)。如果風(fēng)控結(jié)果超過(guò)預(yù)設(shè)時(shí)間比如 5 秒未返回就觸發(fā)一個(gè)定時(shí)任務(wù)去查詢風(fēng)控服務(wù)的處理狀態(tài)。這個(gè)方案的好處是業(yè)務(wù)代碼不依賴風(fēng)控服務(wù)的實(shí)時(shí)性不會(huì)因?yàn)轱L(fēng)控服務(wù)慢而阻塞整個(gè)消息消費(fèi)鏈路同時(shí)又能保證最終業(yè)務(wù)狀態(tài)和風(fēng)控結(jié)果一致。暫時(shí)想到這些。RabbitMQ 消息鏈路的延遲問(wèn)題大部分時(shí)候都不是 RabbitMQ 本身的問(wèn)題而是上下游服務(wù)之間的依賴關(guān)系沒(méi)有梳理清楚。排障的時(shí)候不妨把“消息機(jī)制”和“業(yè)務(wù)編排”分開(kāi)看機(jī)制層面的問(wèn)題看隊(duì)列指標(biāo)、看消費(fèi)者狀態(tài)編排層面的問(wèn)題看狀態(tài)流轉(zhuǎn)、看業(yè)務(wù)時(shí)序。我每次排完類似問(wèn)題都會(huì)順手把排查過(guò)程寫成文檔存進(jìn)團(tuán)隊(duì)知識(shí)庫(kù)下次遇到同類現(xiàn)象直接翻文檔能少走不少?gòu)澛贰? RabbitMQ消息延遲排查：業(yè)務(wù)代碼未等風(fēng)控結(jié)果，根因在鏈路與編排
先說(shuō)結(jié)論這個(gè)標(biāo)題描述的現(xiàn)象本質(zhì)上不是“業(yè)務(wù)代碼沒(méi)有做延遲處理”的問(wèn)題而是消息鏈路里某個(gè)環(huán)節(jié)的耗時(shí)沒(méi)有反映到業(yè)務(wù)代碼的執(zhí)行路徑上。我排過(guò)幾次類似的問(wèn)題最后發(fā)現(xiàn)根因往往藏在 RabbitMQ 的消費(fèi)機(jī)制、下游服務(wù)耗時(shí)抖動(dòng)、甚至網(wǎng)絡(luò)連接狀態(tài)里跟業(yè)務(wù)代碼里有沒(méi)有 sleep 關(guān)系不大。把題主說(shuō)的現(xiàn)象翻譯一下風(fēng)控服務(wù)處理消息有延遲但業(yè)務(wù)代碼消費(fèi)消息時(shí)沒(méi)有等風(fēng)控結(jié)果直接就往下走了。這種情況通常出現(xiàn)在異步消息鏈路里——訂單消息先被消費(fèi)風(fēng)控結(jié)果后到業(yè)務(wù)代碼沒(méi)做阻塞等待導(dǎo)致用戶看到的業(yè)務(wù)狀態(tài)落后于實(shí)際處理節(jié)奏。要定位這個(gè)問(wèn)題得先搞清楚幾個(gè)關(guān)鍵點(diǎn)消息是什么時(shí)候被消費(fèi)的、風(fēng)控結(jié)果是通過(guò)什么通道回來(lái)的、業(yè)務(wù)代碼對(duì)消息依賴順序是怎么編排的。下面我按自己的排障思路展開(kāi)講。1. 消息鏈路延遲問(wèn)題可能出在哪個(gè)環(huán)節(jié)一條 RabbitMQ 消息從生產(chǎn)到消費(fèi)大致要經(jīng)過(guò)生產(chǎn)者發(fā)送、交換機(jī)路由、隊(duì)列存儲(chǔ)、消費(fèi)者拉取、業(yè)務(wù)處理五個(gè)階段。任何一段變慢都會(huì)表現(xiàn)為“消息處理有延遲”。但如果業(yè)務(wù)代碼本身能正常運(yùn)行、只是沒(méi)有等待風(fēng)控結(jié)果那問(wèn)題大概率不在 RabbitMQ 的基礎(chǔ)傳輸層而在業(yè)務(wù)編排層。先把消息鏈路拆開(kāi)看。生產(chǎn)者把消息發(fā)到交換機(jī)交換機(jī)按路由鍵投遞到隊(duì)列消費(fèi)者從隊(duì)列拉消息。RabbitMQ 的特性是推拉結(jié)合——消費(fèi)者訂閱隊(duì)列后broker 會(huì)主動(dòng)推送消息Basic.Deliver也可以由消費(fèi)者主動(dòng)拉取Basic.Get。大多數(shù)業(yè)務(wù)系統(tǒng)用的是推送模式這意味著 broker 是主動(dòng)把消息塞給消費(fèi)者的消費(fèi)者只要線程空閑就立刻開(kāi)始處理。這就能解釋一個(gè)現(xiàn)象業(yè)務(wù)代碼收到消息時(shí)消息本身是熱乎乎的生產(chǎn)時(shí)間和消費(fèi)時(shí)間差得很小。真正的時(shí)間差出現(xiàn)在消費(fèi)之后——業(yè)務(wù)代碼等風(fēng)控結(jié)果的那個(gè)間隙。所以排查方向要鎖定在“風(fēng)控結(jié)果通過(guò)什么方式回到業(yè)務(wù)系統(tǒng)”以及“業(yè)務(wù)代碼在等待期間做了什么”上。如果風(fēng)控結(jié)果是同步 RPC 返回的那業(yè)務(wù)代碼必然阻塞在風(fēng)控調(diào)用上不存在“沒(méi)做延遲處理”的說(shuō)法如果風(fēng)控結(jié)果是異步回調(diào)或另一個(gè)隊(duì)列消息那業(yè)務(wù)代碼就會(huì)先處理完手頭邏輯等風(fēng)控結(jié)果到了再補(bǔ)后續(xù)動(dòng)作這個(gè)設(shè)計(jì)本身就需要業(yè)務(wù)代碼具備“延遲處理”能力。所以第一層判斷是你的業(yè)務(wù)代碼到底有沒(méi)有等待風(fēng)控結(jié)果的機(jī)制如果沒(méi)有那問(wèn)題根源是消息編排邏輯缺失不是 RabbitMQ 配置問(wèn)題。如果有那就要看等待機(jī)制本身的實(shí)現(xiàn)方式以及它為什么沒(méi)生效。2. 高頻根因?yàn)槭裁达L(fēng)控慢業(yè)務(wù)代碼卻感知不到延遲順著上面的思路我總結(jié)了幾個(gè)高頻根因基本都是我在實(shí)際排障中遇到過(guò)的。第一個(gè)是消費(fèi)者線程池耗盡。假設(shè)消費(fèi)者配置了固定線程池核心線程數(shù) 10最大線程數(shù) 20。風(fēng)控服務(wù)的響應(yīng)時(shí)間從 200ms 漲到 2 秒那么每個(gè)消費(fèi)線程處理一條消息的時(shí)間從 300ms 漲到 2.5 秒。在消息量不變的情況下消費(fèi)者的實(shí)際吞吐量直接掉了一個(gè)數(shù)量級(jí)。新消息進(jìn)隊(duì)列后沒(méi)有空閑線程處理只能排隊(duì)。此時(shí)從業(yè)務(wù)側(cè)看消息延遲明顯增加但業(yè)務(wù)代碼本身沒(méi)有任何等待邏輯。這種場(chǎng)景的定位標(biāo)志是RabbitMQ 后臺(tái)的消費(fèi)者連接里Unacked 消息數(shù)持續(xù)高于線程池大小而且線程 dump 能看到大量線程阻塞在下游 RPC 調(diào)用上。第二個(gè)是消費(fèi)者手動(dòng) ack 時(shí)機(jī)太晚。很多團(tuán)隊(duì)把 ack 放在整個(gè)業(yè)務(wù)邏輯處理完成后包括異步回調(diào)、數(shù)據(jù)庫(kù)寫入、后續(xù)通知等。如果一條消息的完整處理鏈路依賴風(fēng)控結(jié)果的回調(diào)那這條消息會(huì)一直處于“未確認(rèn)”狀態(tài)。RabbitMQ 對(duì)未確認(rèn)消息有數(shù)量限制prefetch超過(guò)限制后broker 不會(huì)再向消費(fèi)者投遞新消息。表現(xiàn)就是你后臺(tái)看到消費(fèi)者在線但隊(duì)列里的 Ready 消息數(shù)不降Unacked 消息數(shù)卻很高。這個(gè)場(chǎng)景的定位標(biāo)志是消費(fèi)者進(jìn)程還在運(yùn)行但沒(méi)有消息流入CPU 占用不高業(yè)務(wù)日志里也沒(méi)有新消息的處理記錄。第三個(gè)是跨隊(duì)列消息順序錯(cuò)位。如果訂單創(chuàng)建消息和風(fēng)控結(jié)果消息在同一個(gè)隊(duì)列里那消費(fèi)順序是有保證的——先下單消息后風(fēng)控結(jié)果業(yè)務(wù)代碼可以按順序處理。但很多系統(tǒng)把這兩類消息放到不同隊(duì)列甚至不同交換機(jī)這時(shí)候 RabbitMQ 只能保證單隊(duì)列內(nèi)部有序跨隊(duì)列的順序是無(wú)法保證的。風(fēng)控結(jié)果因?yàn)榉?wù)端處理慢可能比訂單消息晚幾十秒才到。如果業(yè)務(wù)代碼在收到訂單消息后立刻執(zhí)行后續(xù)流程不等風(fēng)控結(jié)果那這個(gè)“延遲”其實(shí)是兩個(gè)隊(duì)列之間的時(shí)間差導(dǎo)致的。這種場(chǎng)景下業(yè)務(wù)代碼確實(shí)沒(méi)有做延遲處理但它也不應(yīng)該用 sleep 來(lái)解決而應(yīng)該設(shè)計(jì)成“先緩存訂單消息等風(fēng)控結(jié)果到達(dá)后合并處理”。第四個(gè)是網(wǎng)絡(luò)或連接層問(wèn)題。RabbitMQ 消費(fèi)者連接如果被防火墻或負(fù)載均衡器斷開(kāi)客戶端會(huì)自動(dòng)重連重連期間消息會(huì)堆積在隊(duì)列里。雖然網(wǎng)絡(luò)層問(wèn)題不直接等同于“風(fēng)控延遲”但它會(huì)放大延遲的感知。我遇到過(guò)一種情況RabbitMQ 集群某個(gè)節(jié)點(diǎn)發(fā)生網(wǎng)絡(luò)抖動(dòng)消費(fèi)者連接被重置重連花了幾秒鐘但這幾秒鐘里業(yè)務(wù)方收到的告警就是“消息處理延遲”。如果只看業(yè)務(wù)代碼根本找不到問(wèn)題。3. 實(shí)操?gòu)?fù)盤從現(xiàn)象到根因的完整排障路徑下面放一份我覺(jué)得比較標(biāo)準(zhǔn)的排障流程你可以對(duì)照著操作。3.1 先判斷延遲發(fā)生的位置接到“風(fēng)控有延遲”的告警后第一步不是看代碼而是看 RabbitMQ 管理后臺(tái)。打開(kāi)隊(duì)列頁(yè)面關(guān)注三個(gè)指標(biāo)Ready待消費(fèi)消息數(shù)、Unacked已投遞但未確認(rèn)消息數(shù)、Total消息總數(shù)。再配合生產(chǎn)者發(fā)送時(shí)間和消費(fèi)者實(shí)際處理時(shí)間的時(shí)間戳基本能判斷延遲發(fā)生在“生產(chǎn)到消費(fèi)之間”還是“消費(fèi)到處理完成之間”。如果 Ready 大、Unacked 小說(shuō)明消息在隊(duì)列里堆積消費(fèi)者消費(fèi)速度跟不上生產(chǎn)速度。如果 Unacked 大、Ready 小說(shuō)明消息已經(jīng)發(fā)給消費(fèi)者了但消費(fèi)者處理得慢。第三步再去看消費(fèi)者的線程池狀態(tài)。我習(xí)慣用命令抓線程棧Java 服務(wù)用jstack pid抓兩三次間隔 5 秒看哪些線程一直卡在同一個(gè)調(diào)用上。如果大量線程阻塞在風(fēng)控服務(wù)的 HTTP 調(diào)用或 RPC 調(diào)用上基本就能鎖定是下游服務(wù)變慢導(dǎo)致消費(fèi)阻塞。3.2 驗(yàn)證風(fēng)控服務(wù)接口耗時(shí)鎖定了風(fēng)控服務(wù)變慢后需要進(jìn)一步看風(fēng)控服務(wù)的監(jiān)控?cái)?shù)據(jù)。常見(jiàn)的情況有兩種風(fēng)控服務(wù)依賴的外部數(shù)據(jù)源變慢比如查詢風(fēng)控規(guī)則庫(kù)的 SQL 從 50ms 漲到 1 秒或者是風(fēng)控服務(wù)本身的連接池被打滿大量請(qǐng)求在等待空閑連接。這個(gè)環(huán)節(jié)我一般直接用風(fēng)控服務(wù)的鏈路追蹤數(shù)據(jù)看接口的 P99 延遲和下游依賴耗時(shí)分布。如果鏈路追蹤里有大段的空白時(shí)間那就是在等某個(gè)外部服務(wù)如果整個(gè)調(diào)用鏈都快唯獨(dú)整體耗時(shí)高那就是線程池排隊(duì)。這兩種根因的解決方案不一樣前者需要優(yōu)化外部依賴后者需要擴(kuò)大線程池或限流。3.3 檢查業(yè)務(wù)代碼的消息編排邏輯如果風(fēng)控服務(wù)本身響應(yīng)很快問(wèn)題還出在“業(yè)務(wù)代碼沒(méi)做延遲處理”上那就要檢查業(yè)務(wù)代碼的消息編排設(shè)計(jì)了。核心問(wèn)題是業(yè)務(wù)代碼收到訂單消息后是直接執(zhí)行后續(xù)流程還是先保存一筆待處理記錄、等風(fēng)控結(jié)果消息到達(dá)后再合并處理后者才是合理的延遲處理設(shè)計(jì)。如果業(yè)務(wù)代碼是直接往下執(zhí)行那你要加一個(gè)改造方案把“待風(fēng)控校驗(yàn)”的狀態(tài)落庫(kù)訂單消息先更新?tīng)顟B(tài)為“處理中”等風(fēng)控結(jié)果消息到達(dá)后再根據(jù)結(jié)果更新“通過(guò)”或“拒絕”。這種異步編排方式不需要 sleep也不需要阻塞等待而是通過(guò)狀態(tài)機(jī) 消息驅(qū)動(dòng)來(lái)保證最終一致性。3.4 結(jié)合監(jiān)控?cái)?shù)據(jù)確認(rèn)全鏈路耗時(shí)做完上述驗(yàn)證后最后一步是把整條鏈路的耗時(shí)拼起來(lái)看。我一般會(huì)拉一張時(shí)間線消息生產(chǎn)、消息入隊(duì)、消息投遞、消費(fèi)者收到、風(fēng)控請(qǐng)求發(fā)出、風(fēng)控響應(yīng)返回、業(yè)務(wù)狀態(tài)更新。每個(gè)時(shí)間點(diǎn)的差值就是每個(gè)環(huán)節(jié)的耗時(shí)。只要哪個(gè)環(huán)節(jié)的耗時(shí)異常一眼就能看出來(lái)。如果實(shí)測(cè)下來(lái)消息從投遞到消費(fèi)者收到只花了 20ms但風(fēng)控結(jié)果返回花了 3 秒而業(yè)務(wù)代碼在收到風(fēng)控結(jié)果前就把業(yè)務(wù)狀態(tài)更新了那問(wèn)題就再清晰不過(guò)了業(yè)務(wù)代碼沒(méi)有等待風(fēng)控結(jié)果導(dǎo)致業(yè)務(wù)狀態(tài)落后于實(shí)際風(fēng)控結(jié)果。這個(gè)情況本質(zhì)上是業(yè)務(wù)編排問(wèn)題不是 RabbitMQ 延遲問(wèn)題但表面現(xiàn)象確實(shí)是“風(fēng)控有延遲、業(yè)務(wù)代碼沒(méi)做延遲處理”。4. 常見(jiàn)問(wèn)題速查表與定位技巧現(xiàn)象優(yōu)先檢查項(xiàng)常見(jiàn)根因Ready 消息數(shù)持續(xù)增長(zhǎng)Unacked 為 0生產(chǎn)者發(fā)送速率、消費(fèi)者是否在線消費(fèi)者未訂閱隊(duì)列或路由鍵配置錯(cuò)誤Unacked 消息數(shù)持續(xù)高消費(fèi)者無(wú)明顯異常消費(fèi)者線程棧、下游調(diào)用耗時(shí)消費(fèi)線程阻塞在下游服務(wù)消息無(wú)法確認(rèn)消費(fèi)者在線但長(zhǎng)期不消費(fèi)新消息prefetch 設(shè)置、ack 策略已投遞消息未確認(rèn)達(dá)到信道未確認(rèn)上限單條消息處理正常但整體延遲高消費(fèi)者線程數(shù)、批量消費(fèi)配置消費(fèi)者并發(fā)度不足需要增加消費(fèi)者實(shí)例消息偶發(fā)延遲幾十秒無(wú)明顯規(guī)律RabbitMQ 集群狀態(tài)、網(wǎng)絡(luò)連接網(wǎng)絡(luò)抖動(dòng)、連接重建、集群分區(qū)這幾個(gè)場(chǎng)景里最容易誤判的是第二種。表面看是 RabbitMQ 隊(duì)列堆積實(shí)際根因是下游風(fēng)控服務(wù)變慢消費(fèi)者線程全部卡在等待上。我曾經(jīng)排查過(guò)一個(gè) case告警顯示某隊(duì)列 Ready 消息數(shù)從正常值漲到幾萬(wàn)條第一反應(yīng)是加消費(fèi)者實(shí)例結(jié)果加了三個(gè)實(shí)例后問(wèn)題依舊。后來(lái)抓線程棧才發(fā)現(xiàn)所有消費(fèi)者線程都阻塞在風(fēng)控服務(wù)的 RPC 調(diào)用上加實(shí)例只意味著更多線程在死等完全沒(méi)解決瓶頸。定位這個(gè)問(wèn)題的實(shí)用技巧是看兩個(gè)值RabbitMQ 后臺(tái)的“消費(fèi)者未確認(rèn)數(shù)”和“隊(duì)列 Ready 數(shù)”。如果未確認(rèn)數(shù)遠(yuǎn)大于消費(fèi)者線程數(shù)說(shuō)明消息都?jí)涸谙M(fèi)者進(jìn)程里這個(gè)時(shí)候抓線程棧比查隊(duì)列配置更有效。另外一個(gè)技巧是給消息處理鏈路的關(guān)鍵節(jié)點(diǎn)打上耗時(shí)日志從消息投遞到消費(fèi)者、到下游調(diào)用發(fā)出、到下游響應(yīng)返回分別記錄耗時(shí)。有了這三個(gè)耗時(shí)值就能定位延遲發(fā)生在消息鏈路、下游服務(wù)、還是業(yè)務(wù)代碼自身。5. 結(jié)合題主現(xiàn)象的經(jīng)驗(yàn)總結(jié)題主描述的現(xiàn)象里有一個(gè)很關(guān)鍵的線索“風(fēng)控有延遲而業(yè)務(wù)代碼沒(méi)有做延遲處理”。這說(shuō)明業(yè)務(wù)代碼缺乏對(duì)風(fēng)控結(jié)果的等待機(jī)制或者等待機(jī)制本身沒(méi)有正常觸發(fā)。這種情況的最佳實(shí)踐不是讓業(yè)務(wù)代碼 sleep 固定時(shí)間而是要讓業(yè)務(wù)狀態(tài)依賴風(fēng)控結(jié)果的狀態(tài)流轉(zhuǎn)。也就是說(shuō)業(yè)務(wù)代碼應(yīng)該具備這樣的能力收到訂單消息后把訂單狀態(tài)置為“風(fēng)控校驗(yàn)中”然后等待風(fēng)控結(jié)果消息收到結(jié)果后更新最終狀態(tài)。這個(gè)等待不是代碼層面的 sleep而是通過(guò)消息驅(qū)動(dòng)的狀態(tài)流轉(zhuǎn)。如果風(fēng)控結(jié)果遲遲不到應(yīng)該觸達(dá)超時(shí)重查機(jī)制而不是讓訂單一直卡在中間狀態(tài)。我在實(shí)際項(xiàng)目里用的方案是訂單消息先落庫(kù)狀態(tài)為“待風(fēng)控”同時(shí)發(fā)一條消息到風(fēng)控隊(duì)列等風(fēng)控結(jié)果消息回來(lái)后更新訂單狀態(tài)。如果風(fēng)控結(jié)果超過(guò)預(yù)設(shè)時(shí)間比如 5 秒未返回就觸發(fā)一個(gè)定時(shí)任務(wù)去查詢風(fēng)控服務(wù)的處理狀態(tài)。這個(gè)方案的好處是業(yè)務(wù)代碼不依賴風(fēng)控服務(wù)的實(shí)時(shí)性不會(huì)因?yàn)轱L(fēng)控服務(wù)慢而阻塞整個(gè)消息消費(fèi)鏈路同時(shí)又能保證最終業(yè)務(wù)狀態(tài)和風(fēng)控結(jié)果一致。暫時(shí)想到這些。RabbitMQ 消息鏈路的延遲問(wèn)題大部分時(shí)候都不是 RabbitMQ 本身的問(wèn)題而是上下游服務(wù)之間的依賴關(guān)系沒(méi)有梳理清楚。排障的時(shí)候不妨把“消息機(jī)制”和“業(yè)務(wù)編排”分開(kāi)看機(jī)制層面的問(wèn)題看隊(duì)列指標(biāo)、看消費(fèi)者狀態(tài)編排層面的問(wèn)題看狀態(tài)流轉(zhuǎn)、看業(yè)務(wù)時(shí)序。我每次排完類似問(wèn)題都會(huì)順手把排查過(guò)程寫成文檔存進(jìn)團(tuán)隊(duì)知識(shí)庫(kù)下次遇到同類現(xiàn)象直接翻文檔能少走不少?gòu)澛贰?