你有沒(méi)有遇到過(guò)這種狀況服務(wù)進(jìn)程明明活著CPU占用正常日志卻半天沒(méi)有新東西進(jìn)來(lái)那邊業(yè)務(wù)方已經(jīng)急得拍桌子而你連問(wèn)題出在哪都摸不著頭緒。我前一陣排查一個(gè)訂單延遲推送異常時(shí)就被這么折磨過(guò)最后定位到根因之后才徹底想明白——問(wèn)題出在消息循環(huán)上一批高優(yōu)先級(jí)任務(wù)插隊(duì)搶占了處理權(quán)普通消息在隊(duì)列里被活活餓死整個(gè)業(yè)務(wù)表現(xiàn)就像主動(dòng)脈堵住了一樣。從那以后我對(duì)消息如何流淌這件事特別敏感也借著這個(gè)契機(jī)把 Flowing 框架里的消息循環(huán)從底層拆了個(gè)遍。這篇文章我不是來(lái)給你念文檔的。我會(huì)從一次真實(shí)排障經(jīng)歷出發(fā)把 Flowing 框架中消息循環(huán)的完整結(jié)構(gòu)、調(diào)度策略、代碼實(shí)現(xiàn)、常見(jiàn)坑和進(jìn)階改造方案挨個(gè)講清楚。不管你是剛接觸事件驅(qū)動(dòng)開(kāi)發(fā)還是已經(jīng)在服務(wù)端寫(xiě)了幾年消息處理邏輯我都盡量保證你能從中找到可直接落地的經(jīng)驗(yàn)。1. 為什么消息循環(huán)是 Flowing 這類框架的心臟1.1 事件驅(qū)動(dòng)程序的底層共性先跳開(kāi) Flowing 這個(gè)名字想一個(gè)更基礎(chǔ)的問(wèn)題任何事件驅(qū)動(dòng)的程序本質(zhì)上都在做同一件事——等待外部輸入然后做出響應(yīng)。GUI 程序在等鼠標(biāo)鍵盤(pán)事件網(wǎng)絡(luò)服務(wù)在等請(qǐng)求到達(dá)消息中間件的消費(fèi)者在等新消息投遞。你寫(xiě)的業(yè)務(wù)代碼再多最后都會(huì)收斂到一個(gè)固定的動(dòng)作上取一條消息處理它再取下一條。這個(gè)取一條、處理一條、再取下一條的重復(fù)動(dòng)作就是消息循環(huán)。Flowing 框架把它做成了獨(dú)立的一層而不是散落在業(yè)務(wù)代碼里。好處非常直接所有消息的排隊(duì)、分發(fā)、調(diào)度、異常兜底都被收攏到一個(gè)統(tǒng)一機(jī)制里業(yè)務(wù)方只需要注冊(cè)我關(guān)心什么消息、收到之后干什么剩下的交給循環(huán)。我以前接手過(guò)一個(gè)項(xiàng)目早期沒(méi)引入框架時(shí)每個(gè)人在代碼里各自寫(xiě) while 輪詢、各自建隊(duì)列結(jié)果五個(gè)模塊有五種消息處理方式。有的用阻塞隊(duì)列有的用自旋有一個(gè)干脆每 100 毫秒定時(shí)掃一次數(shù)據(jù)庫(kù)把數(shù)據(jù)庫(kù)當(dāng)成消息隊(duì)列用。改動(dòng)一個(gè)模塊的響應(yīng)邏輯常常會(huì)牽連另一個(gè)模塊的時(shí)序。后來(lái)統(tǒng)一遷到 Flowing 的消息循環(huán)模型上所有模塊才真正有了同一個(gè)心跳。1.2 沒(méi)有良好循環(huán)時(shí)系統(tǒng)會(huì)以什么方式崩潰這里說(shuō)的崩潰不一定是進(jìn)程宕掉更多時(shí)候是邏輯崩了。我歸納下來(lái)最常見(jiàn)的三種癥狀是消息處理亂序并發(fā)消費(fèi)者各自搶消息A 消息先到卻在 B 消息之后才被執(zhí)行業(yè)務(wù)上表現(xiàn)為主從數(shù)據(jù)不一致、狀態(tài)被覆蓋。消息無(wú)限堆積生產(chǎn)者持續(xù)投遞消費(fèi)者處理不過(guò)來(lái)內(nèi)存暴漲或者消息被丟棄。循環(huán)假死某個(gè)消費(fèi)者回調(diào)里做了阻塞操作比如同步調(diào)遠(yuǎn)程接口一直等響應(yīng)整個(gè)循環(huán)卡住后面的消息全部排隊(duì)無(wú)人問(wèn)津。這三種癥狀里假死最坑人。因?yàn)榉?wù)進(jìn)程沒(méi)掛健康檢查可能還通過(guò)但業(yè)務(wù)實(shí)際上已經(jīng)停擺。我那次排查訂單推送問(wèn)題就是典型的假死一個(gè)消息處理器里混入了同步的 HTTP 調(diào)用對(duì)方服務(wù)慢得像蝸牛每次處理要卡 20 秒隊(duì)列從幾十條一路漲到幾萬(wàn)條后面的推送消息全被堵死。所以理解消息循環(huán)不只是為了寫(xiě)出能跑的 Demo更是為了在遇到活著但不動(dòng)這類詭異故障時(shí)能有一個(gè)清晰的排查坐標(biāo)。下面我把 Flowing 的消息循環(huán)按角色拆開(kāi)講。2. Flowing 消息循環(huán)里的四個(gè)角色誰(shuí)投遞、誰(shuí)排隊(duì)、誰(shuí)分發(fā)、誰(shuí)消費(fèi)2.1 生產(chǎn)者消息的源頭遠(yuǎn)比你想的復(fù)雜在很多人的直覺(jué)里生產(chǎn)者就是業(yè)務(wù)代碼調(diào)用一個(gè) post 方法把消息丟進(jìn)來(lái)。對(duì)了一半。Flowing 里消息來(lái)源至少有四種本地調(diào)用投遞、網(wǎng)絡(luò)請(qǐng)求接入、定時(shí)器觸發(fā)、其他消息處理過(guò)程中產(chǎn)生的新消息。最后一種值得專門(mén)說(shuō)。一個(gè)消息處理完可能產(chǎn)生后續(xù)動(dòng)作比如訂單支付成功后要發(fā)送物流通知、更新庫(kù)存、觸發(fā)積分變化。如果這些動(dòng)作直接在處理器里同步執(zhí)行處理時(shí)間會(huì)被拉得很長(zhǎng)正確做法是讓處理器把后續(xù)動(dòng)作作為新消息投遞回循環(huán)由循環(huán)統(tǒng)一調(diào)度。這樣單個(gè)消息處理可以快速結(jié)束處理器不需要關(guān)心后續(xù)邏輯到底花了多長(zhǎng)時(shí)間。但這也帶來(lái)一個(gè)問(wèn)題如果處理消息時(shí)不斷地產(chǎn)生新消息生產(chǎn)者的投遞速率可能被消費(fèi)者自己的行為放大。典型例子是消息處理器內(nèi)部出錯(cuò)后重投如果每次都重投同樣一條消息相當(dāng)于一個(gè)生產(chǎn)者瘋狂生產(chǎn)垃圾消息循環(huán)會(huì)立刻被淹沒(méi)。這種自產(chǎn)自銷的消息風(fēng)暴我在業(yè)務(wù)里見(jiàn)過(guò)不止一次。2.2 隊(duì)列有界與無(wú)界的取舍是一條安全線消息循環(huán)中隊(duì)列的地位就像血管它決定了消息能流多快、能存多少。Flowing 里隊(duì)列的第一個(gè)關(guān)鍵是設(shè)置有界還是無(wú)界。無(wú)界隊(duì)列看起來(lái)誘人因?yàn)橛肋h(yuǎn)不用拒絕消息生產(chǎn)者的 post 永遠(yuǎn)不會(huì)失敗。但代價(jià)是一旦消費(fèi)速度跟不上隊(duì)列會(huì)無(wú)限制增長(zhǎng)最終內(nèi)存溢出把進(jìn)程拖死。更尷尬的是這種問(wèn)題在流量低的時(shí)候根本不會(huì)暴露一到大促流量翻十倍就會(huì)瞬間爆掉。所以我自己的原則很明確線上環(huán)境一律使用有界隊(duì)列寧可拒絕一部分消息也不能讓內(nèi)存先爆。有界隊(duì)列后隨之而來(lái)的問(wèn)題是隊(duì)列滿了之后怎么辦。Flowing 的可選策略大致有四種直接丟棄消息、丟棄最舊的消息、阻塞生產(chǎn)者等待隊(duì)列有空位、拋出異常讓上層決定處理方式。這些策略沒(méi)有絕對(duì)優(yōu)劣取決于業(yè)務(wù)容忍度。比如訂單支付結(jié)果通知你可以阻塞生產(chǎn)者因?yàn)橄⒔^對(duì)不能丟而實(shí)時(shí)日志采集丟棄一兩行日志影響不大阻塞生產(chǎn)者反而會(huì)拖垮業(yè)務(wù)線程。2.3 分發(fā)器消息類型到處理函數(shù)的映射規(guī)則隊(duì)列里存的只是一條條原始消息真正要執(zhí)行什么邏輯由分發(fā)器決定。Flowing 的分發(fā)器維護(hù)著一張消息類型注冊(cè)表每種消息類型對(duì)應(yīng)一個(gè)或者一組處理函數(shù)handler。分發(fā)器的設(shè)計(jì)有一個(gè)容易被忽略的點(diǎn)它不能只做簡(jiǎn)單的一對(duì)一映射。同一個(gè)類型的消息可能需要經(jīng)過(guò)不同的處理鏈路比如訂單消息在支付前和支付后要走的邏輯完全不同。Flowing 的做法是允許按照消息內(nèi)容中的路由鍵做二次匹配分發(fā)器先根據(jù)消息類型找到處理鏈再根據(jù)路由條件選擇具體的處理函數(shù)。在設(shè)計(jì)處理鏈時(shí)我強(qiáng)烈建議你保持一段處理只做一件事的原則。處理鏈上每個(gè)節(jié)點(diǎn)只做過(guò)濾、轉(zhuǎn)換、業(yè)務(wù)處理或者記錄中的一個(gè)職責(zé)這樣后續(xù)排查和使用鏈路追蹤都會(huì)輕松很多。我見(jiàn)過(guò)有同事把七八個(gè)判斷邏輯塞進(jìn)一個(gè)函數(shù)結(jié)果線上一條消息走到哪個(gè)分支都看不清出了問(wèn)題只能靠加日志猜。2.4 消費(fèi)者真正干活的執(zhí)行環(huán)境消費(fèi)者是最終執(zhí)行處理邏輯的代碼塊它運(yùn)行在哪個(gè)線程、能否并發(fā)、會(huì)不會(huì)阻塞直接決定消息循環(huán)的吞吐上限。Flowing 默認(rèn)的做法是在一個(gè)線程里順序消費(fèi)隊(duì)列消息這樣能天然保證消息不并發(fā)、不亂序。但單線程消費(fèi)意味著一條消息處理慢會(huì)阻塞后面所有消息。Flowing 引入了多消費(fèi)者模式允許同一份消息分發(fā)到多個(gè) worker 線程并行處理。這時(shí)候順序性就不能保證了必須通過(guò)分區(qū)策略來(lái)解決——把同一業(yè)務(wù)鍵的消息固定發(fā)送到同一個(gè) worker 上保證這個(gè)業(yè)務(wù)鍵內(nèi)的消息有序。這里我提醒一句并行消費(fèi)者數(shù)量不是越大越好。線程多了上下文切換和鎖競(jìng)爭(zhēng)會(huì)吃掉收益而且消息處理中訪問(wèn)共享資源時(shí)并發(fā)沖突會(huì)增加。我通常先按 CPU 核數(shù)的一半起步壓測(cè)后再調(diào)整。從我觀察到的項(xiàng)目情況看消息體小、處理邏輯輕的場(chǎng)景下 4 到 8 個(gè) worker 已經(jīng)能覆蓋絕大多數(shù)需求。3. 調(diào)度策略FIFO 只是起點(diǎn)優(yōu)先級(jí)、時(shí)間輪和背壓才是重頭3.1 先來(lái)先服務(wù)的適用邊界最簡(jiǎn)單的調(diào)度策略就是先來(lái)先服務(wù)誰(shuí)先入隊(duì)誰(shuí)先被消費(fèi)。Flowing 單線程循環(huán)默認(rèn)采用這個(gè)策略它最大的優(yōu)點(diǎn)是公平性。在系統(tǒng)負(fù)載遠(yuǎn)低于處理能力時(shí)FIFO 完全夠用而且天然保證順序?qū)崿F(xiàn)起來(lái)幾乎沒(méi)有額外成本。問(wèn)題出在負(fù)載升高之后。如果隊(duì)列里混著給用戶發(fā)一條通知這種低優(yōu)任務(wù)和處理退款這種不能拖的高優(yōu)任務(wù)FIFO 一視同仁的結(jié)果就是高優(yōu)任務(wù)被大量普通任務(wù)頂在后面。用戶感知就是退款遲遲不到賬體驗(yàn)非常差。所以一旦你能預(yù)判消息的重要程度有差異就該放棄純粹 FIFO。3.2 優(yōu)先級(jí)隊(duì)列與饑餓問(wèn)題Flowing 支持給消息設(shè)置優(yōu)先級(jí)隊(duì)列內(nèi)部按優(yōu)先級(jí)排序高優(yōu)消息會(huì)被優(yōu)先取出。這看起來(lái)很簡(jiǎn)單但引入優(yōu)先級(jí)之后麻煩立刻跟著來(lái)了如果高優(yōu)消息源源不斷低優(yōu)消息可能永遠(yuǎn)輪不到處理這就是饑餓。處理饑餓問(wèn)題我常用的手段有兩種。第一種是給低優(yōu)隊(duì)列設(shè)置最低處理配額比如循環(huán)每消費(fèi) 100 條消息必須保證有至少 20% 來(lái)自低優(yōu)隊(duì)列防止低優(yōu)完全餓死。第二種是老化機(jī)制低優(yōu)消息在隊(duì)列里等待超過(guò)某個(gè)閾值后自動(dòng)升級(jí)優(yōu)先級(jí)確保它最終能被處理掉。這里要特別提醒的是優(yōu)先級(jí)隊(duì)列的入隊(duì)操作不再是 O(1) 的尾部追加而是需要按優(yōu)先級(jí)插入。如果你用的是二叉堆實(shí)現(xiàn)入隊(duì)和出隊(duì)都是 O(log n)在高頻消息場(chǎng)景下成本需要測(cè)試評(píng)估。我在一個(gè)模擬項(xiàng)目 X 中對(duì)比過(guò)千萬(wàn)級(jí)日消息量下優(yōu)先級(jí)隊(duì)列的額外開(kāi)銷可以忽略不計(jì)但到了億級(jí)堆操作的競(jìng)爭(zhēng)和內(nèi)存分配就開(kāi)始成為瓶頸。3.3 時(shí)間輪與延遲消息很多業(yè)務(wù)場(chǎng)景需要延遲一段時(shí)間再處理比如訂單超時(shí)關(guān)閉、驗(yàn)證碼過(guò)期、延遲推送。如果用普通隊(duì)列實(shí)現(xiàn)你得在消費(fèi)者里不停比對(duì)當(dāng)前時(shí)間和消息的到期時(shí)間效率很低。Flowing 使用時(shí)間輪來(lái)處理延遲消息。時(shí)間輪的思想可以類比一個(gè)環(huán)形鐘表把時(shí)間劃分為很多槽位每個(gè)槽位對(duì)應(yīng)一個(gè)時(shí)刻到期的消息放進(jìn)對(duì)應(yīng)的槽位。指針每走一小格就把當(dāng)前槽位里的消息取出來(lái)投遞到就緒隊(duì)列。這種設(shè)計(jì)讓檢查一個(gè)消息是否到期從每次都遍歷所有消息變成了只需看當(dāng)前指針指向的槽位性能高得多。我在做某個(gè)跨平臺(tái)系統(tǒng)的延遲關(guān)閉功能時(shí)用過(guò) Flowing 的時(shí)間輪把一千個(gè)訂單的延遲關(guān)閉任務(wù)丟進(jìn)時(shí)間輪內(nèi)存占用和 CPU 開(kāi)銷都很低。但注意時(shí)間輪的精度由槽位間隔決定比如 1 秒一個(gè)槽那就無(wú)法保證 100 毫秒級(jí)別的到期精度。如果需要高精度就得換用小頂堆或者更細(xì)粒度的時(shí)間輪相應(yīng)的內(nèi)存開(kāi)銷也會(huì)變大。3.4 背壓讓生產(chǎn)者知道消費(fèi)者扛不住了背壓這個(gè)概念可以理解為消費(fèi)者撐不住時(shí)向生產(chǎn)者傳遞的阻力信號(hào)。Flowing 處理背壓的手段體現(xiàn)在有界隊(duì)列和拒絕策略上當(dāng)隊(duì)列長(zhǎng)度超過(guò)閾值時(shí)新來(lái)的消息要么被阻塞、要么被拒絕、要么被降級(jí)。最有用的一個(gè)實(shí)踐是分級(jí)背壓。不要把隊(duì)列設(shè)計(jì)成一個(gè)到了上限直接拒絕的開(kāi)關(guān)而是設(shè)置幾個(gè)水位線。隊(duì)列長(zhǎng)度超過(guò) 60% 時(shí)開(kāi)始告警超過(guò) 80% 時(shí)對(duì)低優(yōu)消息直接拒絕超過(guò) 95% 時(shí)所有消息都拒絕且觸發(fā)熔斷保護(hù)下游不被打崩。這樣生產(chǎn)者在壓力變大時(shí)能逐漸感知風(fēng)險(xiǎn)而不是在最后一刻眼睜睜看著消息被嘩啦啦丟光。4. 動(dòng)手實(shí)現(xiàn)一個(gè)最小 Flowing 消息循環(huán)4.1 核心數(shù)據(jù)結(jié)構(gòu)理論講了這么多不如直接上代碼。我自己在學(xué)習(xí)消息循環(huán)時(shí)習(xí)慣先實(shí)現(xiàn)一個(gè)最小版本跑通之后再逐步加功能。下面我用 Python 寫(xiě)一個(gè)只保留核心骨架的 Flowing 風(fēng)格消息循環(huán)去掉一切和業(yè)務(wù)無(wú)關(guān)的包裝。先定義消息體和消息循環(huán)的主體import time import threading from collections import deque class FlowingMessage: def __init__(self, msg_type, payload, priority0): self.msg_type msg_type # 消息類型用于分發(fā) self.payload payload # 業(yè)務(wù)數(shù)據(jù) self.priority priority # 優(yōu)先級(jí)先不管先留個(gè)字段 self.created_at time.time() class FlowingLoop: def __init__(self, max_queue_size1024): self.queue deque() self.max_queue_size max_queue_size self.handlers {} self.running False def register(self, msg_type, handler): # handler 是接收一個(gè) msg 參數(shù)的函數(shù) self.handlers[msg_type] handler def post(self, msg): if len(self.queue) self.max_queue_size: raise OverflowError(message queue is full) self.queue.append(msg) def run_once(self): if not self.queue: return False msg self.queue.popleft() handler self.handlers.get(msg.msg_type) if handler is not None: handler(msg) return True def run(self): self.running True while self.running: if not self.run_once(): time.sleep(0.001)這段代碼展示了消息循環(huán)最核心的三個(gè)部分消息對(duì)象、注冊(cè)表、單次消費(fèi)邏輯。run_once 每次從隊(duì)列左邊取一條消息按類型找到 handler 執(zhí)行。run 就是不斷調(diào)用 run_once隊(duì)列空了就睡 1 毫秒避免 CPU 空轉(zhuǎn)。4.2 注冊(cè) handler 與投遞消息光有循環(huán)不行得有業(yè)務(wù)側(cè)接入。下面注冊(cè)兩個(gè) handler一個(gè)處理訂單消息一個(gè)處理用戶消息loop FlowingLoop(max_queue_size100) def handle_order(msg): print(f[order] {msg.payload}) def handle_user(msg): print(f[user] {msg.payload}) loop.register(order, handle_order) loop.register(user, handle_user) loop.post(FlowingMessage(order, {id: 1001})) loop.post(FlowingMessage(user, {uid: 99}))這個(gè) Demo 跑起來(lái)之后能明確看到兩條消息按投遞順序被打印。為什么我要強(qiáng)調(diào)按投遞順序因?yàn)閱尉€程加 FIFO 隊(duì)列保證了消費(fèi)順序這是消息循環(huán)最基本也是最珍貴的能力。在真實(shí)業(yè)務(wù)里很多狀態(tài)一致性問(wèn)題的根源就是順序被破壞所以能從設(shè)計(jì)上保住順序就值得保住。4.3 讓循環(huán)在后臺(tái)線程運(yùn)行實(shí)際使用時(shí)通常不會(huì)在主線程里直接 run那樣主線程會(huì)被阻塞沒(méi)法干別的。Flowing 的典型用法是把循環(huán)放進(jìn)獨(dú)立線程主線程只負(fù)責(zé) post 消息import threading def start_loop(loop): t threading.Thread(targetloop.run, daemonTrue) t.start() return t start_loop(loop) for i in range(5): loop.post(FlowingMessage(order, {id: i})) time.sleep(0.2) time.sleep(1)這里有個(gè)細(xì)節(jié)為什么循環(huán)線程要設(shè)成 daemon因?yàn)槭刈o(hù)線程不阻塞進(jìn)程退出當(dāng)主線程執(zhí)行完進(jìn)程可以直接結(jié)束不會(huì)因?yàn)檠h(huán)線程還活著而無(wú)法退出。在輕量級(jí)工具腳本里很好用但在正式服務(wù)里你得保證循環(huán)有優(yōu)雅退出機(jī)制不能直接靠進(jìn)程退出兜底。4.4 加入優(yōu)先級(jí)后的最小改造上面代碼里 priority 字段沒(méi)用到現(xiàn)在把它用起來(lái)。最小改造方式是post 時(shí)把消息插入到合適的位置高優(yōu)先級(jí)靠前。這其實(shí)就是一種簡(jiǎn)單的優(yōu)先級(jí)隊(duì)列實(shí)現(xiàn)但刪除和查找中間元素性能差只適合消息量小的場(chǎng)景正式場(chǎng)景建議用 heapq 維護(hù)堆結(jié)構(gòu)。import heapq class FlowingLoopWithPriority: def __init__(self, max_queue_size1024): self.heap [] self.counter 0 self.max_queue_size max_queue_size self.handlers {} def post(self, msg, priority0): if len(self.heap) self.max_queue_size: raise OverflowError(message queue is full) self.counter 1 # 注意 heapq 是小頂堆優(yōu)先級(jí)數(shù)值越小越靠前 heapq.heappush(self.heap, (priority, self.counter, msg)) def run_once(self): if not self.heap: return False _, _, msg heapq.heappop(self.heap) handler self.handlers.get(msg.msg_type) if handler is not None: handler(msg) return Truecounter 的用途是當(dāng)優(yōu)先級(jí)相同時(shí)保證先入隊(duì)的消息先被彈出避免相等優(yōu)先級(jí)的消息之間亂序。這種細(xì)節(jié)你在實(shí)現(xiàn)消息循環(huán)時(shí)一定要留意否則你會(huì)得到一個(gè)看起來(lái)有序、實(shí)際隨緣的隊(duì)列。5. 實(shí)戰(zhàn)排障消息積壓、假死和重復(fù)消費(fèi)我是怎么一步步排查的5.1 消息積壓的三種典型根因先看積壓。某次測(cè)試環(huán)境里出現(xiàn)消息積壓第一反應(yīng)通常是消費(fèi)者處理太慢但深入排查會(huì)發(fā)現(xiàn)問(wèn)題沒(méi)那么簡(jiǎn)單。我歸納出三種根因處理函數(shù)耗時(shí)嚴(yán)重比如消息處理器里做了數(shù)據(jù)庫(kù)全表掃描、同步調(diào)用了慢接口。這種情況單純加消費(fèi)者線程沒(méi)用必須優(yōu)化處理器本身。消費(fèi)者線程數(shù)配置不足隊(duì)列堆積明顯但每個(gè)消息處理時(shí)間其實(shí)很短。此時(shí)線程數(shù)不夠需要擴(kuò)大并發(fā)度。消息被反復(fù)重試卡在隊(duì)頭某條消息處理失敗進(jìn)入重試如果實(shí)現(xiàn)方式是放回隊(duì)頭它就會(huì)反復(fù)阻塞后面的消息造成所有新消息積壓。第三種最隱蔽也是我踩坑最多的。之前做某圖像處理 Demo 時(shí)一個(gè)圖片消息解碼失敗后不斷回到隊(duì)頭重試后面的圖片消息全部排隊(duì)。表面看是積壓實(shí)際是死循環(huán)重試。5.2 循環(huán)里不能有阻塞調(diào)用——假死的根因下面這段壞代碼我故意還原出來(lái)你可以看看自己項(xiàng)目里有沒(méi)有類似影子def handle_order(msg): # 同步調(diào)用遠(yuǎn)程服務(wù)假設(shè)這里會(huì)卡 30 秒 resp requests.post(https://slow-service.example/api/process, jsonmsg.payload) save_to_db(resp)在循環(huán)里直接同步調(diào)用遠(yuǎn)程接口是最容易導(dǎo)致假死的寫(xiě)法。因?yàn)橄⒀h(huán)只有一個(gè)線程時(shí)這個(gè)消息沒(méi)處理完后面所有消息都等著。哪怕你有多個(gè) worker如果所有 worker 同時(shí)都在做阻塞調(diào)用一樣會(huì)全部卡住。正確做法是把阻塞調(diào)用放到獨(dú)立線程池中執(zhí)行利用 Future 或回調(diào)機(jī)制把結(jié)果投遞回循環(huán)。Flowing 對(duì)這類場(chǎng)景的處理方式是handler 可以返回一個(gè)協(xié)程或者 Future循環(huán)不等待執(zhí)行完成而是注冊(cè)一個(gè)完成回調(diào)回調(diào)里再往循環(huán)投遞后續(xù)處理消息。這樣當(dāng)前線程立刻被釋放可以繼續(xù)消費(fèi)下一條消息。這里我要強(qiáng)調(diào)一個(gè)很多人忽略的點(diǎn)即使你有 8 個(gè) worker如果每個(gè) worker 的 handler 里都有等遠(yuǎn)程響應(yīng)的同步代碼那么系統(tǒng)的實(shí)際并發(fā)處理能力依然是 8而不是可以處理 8 條消息的同時(shí)還有余力做別的。當(dāng)每個(gè)請(qǐng)求平均需要等待 1 秒時(shí)8 個(gè) worker 最多一秒處理 8 條消息其余請(qǐng)求只能排隊(duì)。真正的吞吐提升要靠在 handler 內(nèi)部使用異步 IO而不是無(wú)限加線程。5.3 重復(fù)消費(fèi)與冪等設(shè)計(jì)消息循環(huán)的另一個(gè)常見(jiàn)坑是重復(fù)消費(fèi)。原因不一定是你代碼邏輯錯(cuò)了而是消息可能被重新投遞。比如消費(fèi)者處理完消息、但還沒(méi)來(lái)得及提交確認(rèn)時(shí)進(jìn)程重啟消息隊(duì)列會(huì)重新投遞這條消息。所以處理消息盡量做成冪等。最簡(jiǎn)單也最有效的方法是在業(yè)務(wù)表里建唯一鍵處理前先判重或者用消息 ID 做去重表。我見(jiàn)過(guò)不少團(tuán)隊(duì)在消息接收方?jīng)]有去重邏輯需求一改同一條消息被處理兩次用戶就收到了兩條一模一樣的短信。我的建議是在消息循環(huán)的消費(fèi)者側(cè)加一個(gè)輕量級(jí)去重模塊。處理消息前先查去重緩存比如 Redis如果處理過(guò)就直接跳過(guò)如果沒(méi)處理過(guò)先寫(xiě)入一個(gè)處理中標(biāo)記再執(zhí)行真正的邏輯執(zhí)行完成后把標(biāo)記置為已完成。注意這個(gè)標(biāo)記不要只存成功狀態(tài)還要存失敗狀態(tài)否則失敗消息每次都要重新跑一遍整個(gè)處理器也是浪費(fèi)。5.4 一次完整排查鏈路從推送延遲到隊(duì)列中的一條壞消息我想分享一次完整的排查過(guò)程給你一個(gè)可復(fù)用的思路?，F(xiàn)象是某電商訂單推送服務(wù)消息延遲從 200 毫秒惡化到 5 分鐘訂單狀態(tài)更新明顯變慢。我接到問(wèn)題的第一反應(yīng)是看監(jiān)控大盤(pán)。隊(duì)列長(zhǎng)度曲線一直往上爬消費(fèi)者處理耗時(shí) P99 也很高說(shuō)明問(wèn)題可能在處理器本身。繼續(xù)看日志發(fā)現(xiàn)每一條訂單消息處理前都會(huì)打印一行processing order日志但某些訂單 ID 處理耗時(shí)差異巨大正常訂單 50 毫秒異常訂單要 40 秒。順著異常訂單 ID 找它對(duì)應(yīng)的 payload發(fā)現(xiàn)里面帶了一個(gè)特別大的 JSON 字段而這個(gè)字段會(huì)觸發(fā)下游服務(wù)的一把全表掃描。定位過(guò)程其實(shí)不是靠代碼 review 找到的而是靠鏈路追蹤把消息 ID 到處理階段的完整鏈路串起來(lái)之后才發(fā)現(xiàn)的。這也提醒我消息循環(huán)的監(jiān)控不只要看隊(duì)列長(zhǎng)度和處理耗時(shí)還要有消息級(jí)別的追蹤能力。沒(méi)有消息 ID 貫穿整個(gè)處理過(guò)程排查這類問(wèn)題基本靠猜。6. 讓 Flowing 消息循環(huán)更抗造的進(jìn)階改造6.1 看門(mén)狗與超時(shí)熔斷基礎(chǔ)消息循環(huán)能跑通業(yè)務(wù)但要說(shuō)抗造還差得很遠(yuǎn)。第一個(gè)要加的是看門(mén)狗機(jī)制。消息循環(huán)中某條消息處理超時(shí)如果沒(méi)有外部干預(yù)它會(huì)一直占用 worker 資源其他消息只能等待。Flowing 可以給每條消息設(shè)置超時(shí)時(shí)間超時(shí)后循環(huán)不再繼續(xù)等待該消息處理完成而是標(biāo)記處理異常并把任務(wù)從當(dāng)前 worker 上摘除。實(shí)現(xiàn)上用超時(shí)調(diào)度器比如時(shí)間輪定期掃描執(zhí)行中的任務(wù)超過(guò)閾值就把該消息認(rèn)定為超時(shí)記錄日志并觸發(fā)補(bǔ)償邏輯。這里要小心一點(diǎn)摘除任務(wù)不等于終止任務(wù)。如果處理器內(nèi)部已經(jīng)在做數(shù)據(jù)庫(kù)更新你強(qiáng)行跳過(guò)去這條消息的后續(xù)副作用可能還在繼續(xù)執(zhí)行會(huì)造成狀態(tài)不一致。所以超時(shí)后要結(jié)合消息 ID 做補(bǔ)償要么允許繼續(xù)執(zhí)行但記錄警告要么確保后續(xù)補(bǔ)償邏輯也能正確處理重復(fù)。千萬(wàn)不要以為超時(shí)摘除就萬(wàn)事大吉。6.2 多線程消費(fèi)者與動(dòng)態(tài)擴(kuò)縮多線程消費(fèi)者的改造不算難難的是讓并發(fā)度能動(dòng)態(tài)調(diào)整。我結(jié)合 Flowing 的實(shí)際使用經(jīng)驗(yàn)推薦一個(gè)簡(jiǎn)單有效的方案維護(hù)一個(gè)可調(diào)大小的 worker 池定時(shí)檢查隊(duì)列長(zhǎng)度和消息平均處理耗時(shí)利用簡(jiǎn)單的控制邏輯動(dòng)態(tài)增加或減少 worker 數(shù)量。判斷該不該擴(kuò)容我的經(jīng)驗(yàn)公式是看隊(duì)列積壓速度。記錄一段時(shí)間內(nèi)的隊(duì)列長(zhǎng)度變化量如果持續(xù)正向增長(zhǎng)說(shuō)明消費(fèi)速度跟不上生產(chǎn)速度先加 worker如果隊(duì)列長(zhǎng)度穩(wěn)定且 worker 的 CPU 占用高說(shuō)明加線程已經(jīng)無(wú)法提升吞吐該優(yōu)化的是單個(gè)消息的處理開(kāi)銷。動(dòng)態(tài)擴(kuò)縮要格外注意資源競(jìng)爭(zhēng)問(wèn)題。worker 增加時(shí)共享資源的鎖競(jìng)爭(zhēng)會(huì)加劇可能反而導(dǎo)致吞吐下降。我在某跨平臺(tái)系統(tǒng)里做過(guò)對(duì)比測(cè)試在無(wú)鎖情況下從 4 worker 加到 8 worker 吞吐提升明顯但在一把大鎖保護(hù)共享狀態(tài)的情況下8 worker 反而比 4 worker 吞吐低了 15%。所以擴(kuò)容不是拍腦袋決定必須實(shí)測(cè)。6.3 可觀測(cè)性隊(duì)列水位、循環(huán)時(shí)延和消息生命周期最后一個(gè)進(jìn)階建議是可觀測(cè)性。我接觸過(guò)的很多系統(tǒng)消息循環(huán)跑得通但出問(wèn)題時(shí)兩眼一抹黑就是因?yàn)槿鄙僦笜?biāo)。哪怕是最簡(jiǎn)單的三個(gè)指標(biāo)也能幫你省下大量排查時(shí)間。第一個(gè)指標(biāo)是隊(duì)列水位即當(dāng)前隊(duì)列長(zhǎng)度與最大長(zhǎng)度的比值。它能直接告訴你系統(tǒng)離爆隊(duì)列還有多遠(yuǎn)。第二個(gè)指標(biāo)是循環(huán)時(shí)延指消息從進(jìn)入隊(duì)列到被取出的等待時(shí)間這個(gè)指標(biāo)比平均處理耗時(shí)更能反映用戶體驗(yàn)。第三個(gè)指標(biāo)是消息生命周期從投遞到處理完成的完整時(shí)間如果它持續(xù)上漲說(shuō)明系統(tǒng)的處理能力正在惡化?？捎^測(cè)性的落地手段可以用結(jié)構(gòu)化日志每條消息處理完成后輸出一條包含消息 ID、耗時(shí)、等待時(shí)間、處理結(jié)果的日志。線上查問(wèn)題時(shí)只要搜消息 ID 就能還原它在消息循環(huán)里走過(guò)的完整路徑。我個(gè)人的經(jīng)驗(yàn)是這比任何復(fù)雜的監(jiān)控大盤(pán)都管用因?yàn)樗前聪⒁暯墙M織的和業(yè)務(wù)認(rèn)知天然一致。最后的一點(diǎn)體會(huì)寫(xiě)到這里關(guān)于 Flowing 消息循環(huán)的骨架已經(jīng)完整了。回看我自己的排障經(jīng)歷最大的感受是理解消息循環(huán)不能只停留在隊(duì)列加分發(fā)這種表面你還需要看到它背后的調(diào)度策略、超時(shí)機(jī)制、背壓邏輯和可觀測(cè)性設(shè)計(jì)。消息如何流淌決定了系統(tǒng)的穩(wěn)定性天花板也決定了你半夜被叫起來(lái)排查故障時(shí)是十分鐘定位還是通宵抓瞎。如果你最近也要在自己的項(xiàng)目里引入或者改造消息循環(huán)我建議你按這個(gè)順序動(dòng)手先用最簡(jiǎn)單的方式跑通最小循環(huán)確認(rèn)順序和基礎(chǔ)分發(fā)沒(méi)問(wèn)題然后加上隊(duì)列飽和和超時(shí)機(jī)制保證它不會(huì)因?yàn)橐粋€(gè)慢處理器而全線崩潰最后再補(bǔ)監(jiān)控和追蹤。不要一開(kāi)始就上分布式、上動(dòng)態(tài)線程池因?yàn)榛A(chǔ)不穩(wěn)時(shí)越復(fù)雜的機(jī)制越容易掩蓋真正的問(wèn)題。