做后端服務(wù)的同學(xué)大概率都有過(guò)這種經(jīng)歷業(yè)務(wù)模塊之間的調(diào)用像一團(tuán)亂麻A服務(wù)要同步等B服務(wù)返回結(jié)果B掛了A就跟著超時(shí)流量一上來(lái)數(shù)據(jù)庫(kù)連接池先被打滿定時(shí)任務(wù)散落在各個(gè)業(yè)務(wù)進(jìn)程里沒(méi)有統(tǒng)一的重試機(jī)制凌晨三點(diǎn)某個(gè)任務(wù)靜默失敗第二天數(shù)據(jù)對(duì)不上賬才發(fā)現(xiàn)。我早期也被這類問(wèn)題折磨過(guò)后來(lái)干脆自己動(dòng)手維護(hù)了一個(gè)輕量級(jí)的消息代理組件也就是標(biāo)題里提到的這個(gè) hermes-agent。名字取自希臘神話里專門負(fù)責(zé)傳信的赫爾墨斯定位很直白做一個(gè)默默跑在業(yè)務(wù)背后的“信使”把消息從生產(chǎn)者手里穩(wěn)妥地送到消費(fèi)者手里。這篇文章不是官方文檔的復(fù)述而是我從實(shí)際項(xiàng)目里摸爬滾打出來(lái)的經(jīng)驗(yàn)總結(jié)。內(nèi)容會(huì)覆蓋 hermes-agent 的核心模塊拆解、部署接入的完整過(guò)程、那些文檔里不會(huì)寫的踩坑記錄以及壓測(cè)調(diào)優(yōu)的思路。如果你正在為服務(wù)間同步耦合、任務(wù)投遞不可靠、或者單純想找一個(gè)比 Redis 列表更好用的消息中轉(zhuǎn)方案而頭疼這篇內(nèi)容可以幫你少走不少?gòu)澛贰?. 為什么我會(huì)選擇維護(hù)一個(gè) hermes-agent 這樣的消息代理1.1 最初的問(wèn)題同步調(diào)用把系統(tǒng)綁成了單點(diǎn)先說(shuō)我最開(kāi)始遇到的場(chǎng)景。當(dāng)時(shí)手上有幾個(gè)業(yè)務(wù)服務(wù)用戶下單后需要同步調(diào)用庫(kù)存服務(wù)、優(yōu)惠券服務(wù)、積分服務(wù)。用戶側(cè)看著一個(gè)下單接口后端實(shí)際上是三個(gè)串行 HTTP 調(diào)用任何一個(gè)服務(wù)抖動(dòng)下單就失敗。這個(gè)架構(gòu)的脆弱之處不用我多說(shuō)典型的多米諾骨牌下游一個(gè)慢查詢拖垮整條鏈路。這個(gè)痛點(diǎn)我估計(jì)很多人都有共鳴。同步調(diào)用的本質(zhì)問(wèn)題是“強(qiáng)耦合”——調(diào)用方必須等被調(diào)用方就緒雙方必須同時(shí)在線流量高峰還必須讓二者的容量精確匹配?？蓪?shí)際業(yè)務(wù)里庫(kù)存服務(wù)和積分服務(wù)的處理速度根本不一樣硬把它們綁在同一個(gè)事務(wù)里只會(huì)互相拖后腿。我當(dāng)時(shí)需要的是一個(gè)能把“發(fā)消息”和“處理消息”拆開(kāi)的中間層。生產(chǎn)者只管把“用戶已下單”這個(gè)事件扔進(jìn)去剩下的庫(kù)存扣減、積分發(fā)放消費(fèi)者自己慢慢消化。就算消費(fèi)端某個(gè)服務(wù)臨時(shí)掛掉消息還在隊(duì)列里等著等它恢復(fù)之后繼續(xù)處理。1.2 為什么不用現(xiàn)成的消息隊(duì)列反而自己搞一個(gè)說(shuō)到削峰填谷、異步解耦很多人第一反應(yīng)是 Kafka、RabbitMQ 這類重型 MQ。這幾個(gè)方案我都用過(guò)穩(wěn)定是真穩(wěn)定但重也是真重。Kafka 需要一個(gè) Zookeeper 集群或者 KRaftRabbitMQ 要維護(hù) Erlang 環(huán)境的版本兼容性如果只是幾個(gè)內(nèi)部服務(wù)之間傳消息這些基礎(chǔ)設(shè)施的運(yùn)維成本比業(yè)務(wù)本身還高。相比之下hermes-agent 這種輕量代理的核心優(yōu)勢(shì)是“不挑環(huán)境、不搶資源”。它不需要獨(dú)立的存儲(chǔ)集群天然支持把消息轉(zhuǎn)發(fā)到 HTTP 接口甚至可以直接推送到業(yè)務(wù)方的回調(diào)地址。這種形態(tài)特別適合內(nèi)部服務(wù)數(shù)量在幾個(gè)到幾十個(gè)的中小型團(tuán)隊(duì)既想要消息隊(duì)列的解耦能力又不想背上 Kafka 那套重運(yùn)維包袱。我在選型時(shí)做了一個(gè)簡(jiǎn)單對(duì)比核心維度如下表對(duì)比項(xiàng)hermes-agentRedis StreamsRabbitMQKafka部署復(fù)雜度單個(gè)二進(jìn)制無(wú)外部依賴依賴 Redis 版本依賴 Erlang 環(huán)境依賴 Kafka 協(xié)調(diào)組件消息投遞方式HTTP推送/回調(diào)為主需自行實(shí)現(xiàn)推送邏輯AMQP 協(xié)議需要客戶端 SDK 消費(fèi)持久化能力支持本地積壓存儲(chǔ)依賴 Redis 持久化配置支持支持運(yùn)維成本低中中高高適合場(chǎng)景中小規(guī)模服務(wù)解耦簡(jiǎn)單隊(duì)列場(chǎng)景企業(yè)級(jí)復(fù)雜路由大數(shù)據(jù)量日志與流處理這個(gè)表不是否定 MQ 的價(jià)值而是想說(shuō)選型得看場(chǎng)景。如果每秒消息量過(guò)萬(wàn)、需要復(fù)雜路由和回溯消費(fèi)還是老實(shí)用 Kafka但如果是百來(lái)臺(tái)機(jī)器規(guī)模、消息量每秒幾百上千hermes-agent 這個(gè)體量的組件足以撐住。2. hermes-agent 的核心能力拆解從消息投遞到任務(wù)生命周期管理2.1 連接管理與心跳?；钕攘倪B接管理。消息代理的第一要?jiǎng)?wù)是保證生產(chǎn)端和消費(fèi)端之間鏈路可用而鏈路可用靠的是心跳機(jī)制。hermes-agent 的處理方式比較直接生產(chǎn)端每間隔固定時(shí)間發(fā)送一個(gè)輕量心跳包代理在連續(xù) N 個(gè)心跳周期沒(méi)收到數(shù)據(jù)后判定對(duì)端失聯(lián)觸發(fā)連接回收和待發(fā)送消息的積壓處理。這個(gè)機(jī)制跟我之前自己寫 socket 長(zhǎng)連接時(shí)的經(jīng)驗(yàn)很一致核心是兩個(gè)參數(shù)的配合心跳發(fā)送間隔和失聯(lián)判定閾值。間隔太短會(huì)浪費(fèi)帶寬和 CPU太長(zhǎng)則故障感知滯后。實(shí)際使用中業(yè)務(wù)允許的故障恢復(fù)時(shí)間大概是多少就把失聯(lián)閾值設(shè)在多少以內(nèi)心跳間隔取閾值的四分之一到三分之一比較合理。比如希望 30 秒內(nèi)感知對(duì)端故障心跳間隔 10 秒一次連續(xù) 3 次未收到心跳就判定失聯(lián)。2.2 消息路由基于 Topic 的訂閱分發(fā)消息路由是消息代理的心臟。hermes-agent 采用了 Topic 加訂閱分組的模型這個(gè)模型用一句話說(shuō)就是生產(chǎn)者把消息發(fā)到某個(gè) Topic代理根據(jù)訂閱關(guān)系把消息副本推給每個(gè)訂閱該 Topic 的消費(fèi)組。這個(gè)設(shè)計(jì)模仿了消息隊(duì)列里最成熟的那套思路。每個(gè)消費(fèi)組內(nèi)部消息按負(fù)載均衡策略分發(fā)給組內(nèi)的多個(gè)消費(fèi)者實(shí)例同一個(gè)消息在一個(gè)消費(fèi)組內(nèi)只會(huì)被一個(gè)實(shí)例處理。而不同的消費(fèi)組之間則互為獨(dú)立——比如訂單服務(wù)創(chuàng)建一個(gè)“訂單已支付”Topic庫(kù)存服務(wù)和積分服務(wù)可以各自建一個(gè)消費(fèi)組訂閱它兩邊互不干擾地拿全量消息。我在實(shí)際配置時(shí)踩過(guò)一個(gè)認(rèn)知誤區(qū)把“消費(fèi)組”和“消費(fèi)者”混為一談。一個(gè)消費(fèi)組代表一個(gè)獨(dú)立的業(yè)務(wù)處理方里面可以有一個(gè)或多個(gè)消費(fèi)者實(shí)例如果你把同一個(gè)業(yè)務(wù)的兩個(gè)實(shí)例放進(jìn)了不同的消費(fèi)組它們會(huì)各自消費(fèi)一遍全量消息這在某些網(wǎng)關(guān)通知場(chǎng)景會(huì)造成重復(fù)推送。正確姿勢(shì)是一個(gè)業(yè)務(wù)方對(duì)應(yīng)一個(gè)消費(fèi)組組內(nèi)加實(shí)例才是擴(kuò)容。2.3 消息生命周期與狀態(tài)機(jī)機(jī)制消息的一生在 hermes-agent 里會(huì)經(jīng)歷這樣一個(gè)狀態(tài)流轉(zhuǎn)新建、待投遞、投遞中、投遞成功、投遞失敗、重試中、最終被放進(jìn)死信隊(duì)列。理解每個(gè)狀態(tài)的含義對(duì)排查問(wèn)題很有幫助。新建狀態(tài)表示消息剛被代理接收尚未分配給任何消費(fèi)組待投遞狀態(tài)表示消息已確認(rèn)目標(biāo)消費(fèi)組等待被消費(fèi)者拉取或等待代理主動(dòng)推送投遞中狀態(tài)表示代理已通過(guò)網(wǎng)絡(luò)把消息發(fā)給了消費(fèi)者但還沒(méi)收到確認(rèn)回執(zhí)收到消費(fèi)者的成功應(yīng)答后消息進(jìn)入投遞成功狀態(tài)從待處理隊(duì)列中移除反之進(jìn)入投遞失敗狀態(tài)根據(jù)配置決定是直接重試還是進(jìn)入死信隊(duì)列。這幾個(gè)狀態(tài)不是憑空設(shè)計(jì)的它們對(duì)應(yīng)了消息系統(tǒng)最核心的“至少一次投遞”語(yǔ)義。因?yàn)榫W(wǎng)絡(luò)可能出問(wèn)題消費(fèi)者可能已處理但回執(zhí)丟失所以消息被重復(fù)投遞是不可避免的。能做的不是消滅重復(fù)投遞而是通過(guò)狀態(tài)機(jī)確保每條消息最多被“有效處理”一次——這部分我在后面踩坑那一章會(huì)展開(kāi)聊。2.4 重試機(jī)制與死信隊(duì)列重試機(jī)制是消息代理可靠性最關(guān)鍵的一環(huán)。hermes-agent 的重試采用了“指數(shù)退避加最大重試次數(shù)”的老牌策略第一次重試延遲 1 秒第二次延遲 2 秒然后 4 秒、8 秒、16 秒……直到達(dá)到配置的最大重試次數(shù)。超過(guò)最大次數(shù)后消息會(huì)被轉(zhuǎn)入一個(gè)獨(dú)立的死信 Topic不再騷擾消費(fèi)者但會(huì)觸發(fā)告警通知運(yùn)維人員。指數(shù)退避的意義在于避免“重試風(fēng)暴”。如果所有失敗消息都立刻重試一旦消費(fèi)端短暫故障代理就會(huì)在恢復(fù)瞬間收到海量重試請(qǐng)求直接把消費(fèi)端再次打掛。這是踩坑踩出來(lái)的教訓(xùn)重試要像道歉一樣第一次說(shuō)對(duì)不起第二次隔一會(huì)兒再說(shuō)表達(dá)誠(chéng)意但不能把人煩死。死信隊(duì)列并非處理完的終點(diǎn)。我通常會(huì)在死信 Topic 上掛一個(gè)專門的補(bǔ)償消費(fèi)者解析失敗消息結(jié)合業(yè)務(wù)日志決定是修正數(shù)據(jù)后手動(dòng)重投還是放棄。死信不能只存不處理不然等于把問(wèn)題從“消息投遞失敗”拖延成“消息被靜默丟棄”。3. 從零接入的完整實(shí)操讓第一條消息從生產(chǎn)端到達(dá)消費(fèi)端3.1 環(huán)境準(zhǔn)備與部署形態(tài)部署 hermes-agent 的過(guò)程簡(jiǎn)單得有點(diǎn)不像一個(gè)“中間件”。只需要把編譯好的二進(jìn)制丟到服務(wù)器上寫一個(gè) YAML 配置文件然后啟動(dòng)進(jìn)程就行。沒(méi)有依賴數(shù)據(jù)庫(kù)沒(méi)有依賴單獨(dú)的緩存服務(wù)消息的積壓存儲(chǔ)基于本地磁盤文件這也讓整體部署非常輕量。我在測(cè)試環(huán)境用的是單節(jié)點(diǎn)部署生產(chǎn)環(huán)境采用兩節(jié)點(diǎn)互為主備的形態(tài)。代理本身是無(wú)狀態(tài)設(shè)計(jì)的消息落盤后即便節(jié)點(diǎn)重啟也能從本地文件恢復(fù)未投遞完的消息。這里注意一點(diǎn)消息是本地存儲(chǔ)節(jié)點(diǎn)掛了但沒(méi)有將文件轉(zhuǎn)移到備節(jié)點(diǎn)的話備節(jié)點(diǎn)無(wú)法接續(xù)處理存量消息。所以更穩(wěn)妥的做法是讓生產(chǎn)端雙寫或者依賴上層業(yè)務(wù)的重試補(bǔ)償。3.2 配置文件的語(yǔ)義詳解以 YAML 配置為例核心配置項(xiàng)如下server: listen: 0.0.0.0:7788 # 代理對(duì)外服務(wù)端口生產(chǎn)端和消費(fèi)端都連這里 max_connections: 2000 # 最大連接數(shù)超過(guò)后拒絕新連接保護(hù)代理自身 storage: data_dir: /var/lib/hermes-agent/data # 消息落盤目錄注意預(yù)留磁盤空間 segment_size: 256MB # 每個(gè)數(shù)據(jù)分片的大小按消息量調(diào)整 sync_mode: async # async / fsyncasync 性能好fsync 更安全 route: topics: - name: order.created partitions: 8 # 分區(qū)數(shù)決定消息并行處理能力 consumers_mode: push # push / pull推送模式或拉取模式 delivery: ack_timeout: 30 # 消費(fèi)者確認(rèn)超時(shí)秒數(shù)超時(shí)判定失敗 max_retries: 5 # 最大重試次數(shù) retry_base_delay: 2 # 重試基礎(chǔ)延遲秒數(shù) dead_letter_topic: dlq.order.created # 死信 Topic幾個(gè)容易理解錯(cuò)的地方說(shuō)一下。partitions參數(shù)決定了一個(gè) Topic 在代理內(nèi)部被分成幾個(gè)并行處理的分片分區(qū)數(shù)越多并行度越高但也會(huì)帶來(lái)更大的文件句柄消耗和消息順序性變化。sync_mode選 async 時(shí)消息先寫內(nèi)存緩沖再異步刷盤吞吐高但極端情況下可能丟剛寫入的數(shù)據(jù)選 fsync每條消息都強(qiáng)制落盤安全但對(duì)磁盤性能要求高。我的建議是先從 async 開(kāi)始跑壓測(cè)之后如果吞吐達(dá)標(biāo)且能接受極端場(chǎng)景下的少量消息丟失保持現(xiàn)狀即可如果消息很重要再切換 fsync。3.3 生產(chǎn)端接入如何把一條消息安全投遞出去生產(chǎn)端接入的代碼模式非常干凈。以 Python 為例核心就三個(gè)動(dòng)作建立連接、發(fā)送消息、關(guān)閉連接。from hermes_agent import Producer producer Producer( endpointhermes://10.10.10.10:7788, topicorder.created, timeout5, ) def send_order_created(order_id: str, user_id: str, amount: int) - bool: payload { order_id: order_id, user_id: user_id, amount: amount, created_at: 1710000000, } try: producer.send(payload, keyorder_id) return True except Exception as exc: # 這里注意send 拋出異常并不代表消息一定沒(méi)被代理接收 # 可能是代理已接收但回執(zhí)在網(wǎng)絡(luò)上丟了需要去重機(jī)制兜底 print(fsend failed: {exc}) return Falsekey參數(shù)值得單獨(dú)說(shuō)。它決定了消息在分區(qū)間的分配策略同一個(gè) key 的消息會(huì)始終進(jìn)入同一個(gè)分區(qū)。對(duì)訂單類消息拿order_id當(dāng) key 可以保證同一個(gè)訂單的所有事件天然有序如果對(duì)順序性不敏感不傳 key 也行代理會(huì)按輪詢策略把消息打散到各分區(qū)吞吐更均衡。生產(chǎn)端有一個(gè)細(xì)節(jié)必須注意send 方法返回異常并不等于消息一定沒(méi)被收到。字節(jié)流可能已經(jīng)到了代理只是確認(rèn)包在回程中丟失。因此業(yè)務(wù)側(cè)在收到 send 異常時(shí)不能簡(jiǎn)單判斷“發(fā)送失敗”而要在消費(fèi)端配合冪等去重處理否則重發(fā)會(huì)帶來(lái)重復(fù)數(shù)據(jù)。這一點(diǎn)我在第 4 章展開(kāi)講。3.4 消費(fèi)端接入回調(diào)函數(shù)與確認(rèn)機(jī)制消費(fèi)端接入更簡(jiǎn)單注冊(cè)一個(gè)回調(diào)函數(shù)在收到消息時(shí)執(zhí)行執(zhí)行成功就返回確認(rèn)代理收到確認(rèn)后刪除消息執(zhí)行異常則觸發(fā)重試。from hermes_agent import Consumer def handle_order_created(payload: dict): order_id payload[order_id] user_id payload[user_id] amount payload[amount] # 模擬業(yè)務(wù)處理扣減庫(kù)存、發(fā)放積分、發(fā)送通知 print(fprocess order: {order_id}, user: {user_id}, amount: {amount}) # 處理成功后無(wú)需額外操作函數(shù)正常返回即視為確認(rèn) # 如果處理失敗拋出異常代理會(huì)自動(dòng)重試該消息 consumer Consumer( endpointhermes://10.10.10.10:7788, topicorder.created, groupinventory-group, callbackhandle_order_created, ) consumer.start()這套模型本質(zhì)上是把消息消費(fèi)做成一個(gè)“可重試的事務(wù)”?；卣{(diào)函數(shù)正常返回代表處理成功拋出異常代表處理失敗這條消息會(huì)被代理重新投遞。因此回調(diào)函數(shù)里不能有不可逆的操作。比如扣庫(kù)存和發(fā)短信這種動(dòng)作要保證即便重復(fù)執(zhí)行也不會(huì)造成資損。一個(gè)穩(wěn)妥的措施是引入去重表每條消息在第一次進(jìn)入回調(diào)時(shí)把message_id寫入一張去重表重復(fù)執(zhí)行時(shí)先查表命中則直接返回成功。這樣處理邏輯天然冪等無(wú)論代理重試多少遍業(yè)務(wù)數(shù)據(jù)都不會(huì)臟。這個(gè)處理方式雖然會(huì)給每筆請(qǐng)求增加一次存儲(chǔ)查詢但相比數(shù)據(jù)錯(cuò)亂帶來(lái)的對(duì)賬成本這點(diǎn)開(kāi)銷微不足道。4. 跑通之后才是真正開(kāi)始線上環(huán)境踩過(guò)的坑菜單搭起來(lái)、代碼寫順了不等于系統(tǒng)可以高枕無(wú)憂。這一章寫的都是我實(shí)際運(yùn)維時(shí)遇到并解決過(guò)的坑每個(gè)都花了不少時(shí)間才定位到根因。4.1 第一個(gè)坑消費(fèi)端重復(fù)執(zhí)行原以為是代理重復(fù)投遞結(jié)果是自己業(yè)務(wù)沒(méi)做冪等上線第二天運(yùn)營(yíng)反饋說(shuō)某些用戶的積分好像加了兩次。我第一反應(yīng)是查代理的重試日志結(jié)果發(fā)現(xiàn)消息只投遞了一次消費(fèi)者也成功確認(rèn)了。隨后翻數(shù)據(jù)庫(kù)才發(fā)現(xiàn)問(wèn)題出在消費(fèi)回調(diào)里扣減積分的邏輯是先查詢用戶當(dāng)前積分再加上本次積分然后寫回庫(kù)。而當(dāng)兩條不同的消息比如下單積分和簽到積分幾乎同時(shí)到達(dá)兩個(gè)回調(diào)各自讀到舊積分余額分別加完后寫回后寫的覆蓋了先寫的相當(dāng)于丟了一次加分。這不是重復(fù)投遞這叫并發(fā)覆蓋寫。排查鏈路是這樣的先看消息日志確認(rèn)消息被消費(fèi)的時(shí)間點(diǎn)和數(shù)據(jù)庫(kù)寫入時(shí)間點(diǎn)是匹配的再看應(yīng)用日志發(fā)現(xiàn)兩條消息的處理日志幾乎在同一秒打印最后看了數(shù)據(jù)庫(kù)記錄確認(rèn)是覆蓋寫而不是追加寫。到這里定位就清楚了——這不是消息代理的問(wèn)題是消費(fèi)端代碼沒(méi)有考慮并發(fā)串行化。解決方案是在數(shù)據(jù)庫(kù)層面用原子更新把“讀改寫”三個(gè)動(dòng)作合并為一個(gè) UPDATE 語(yǔ)句保證同一用戶的積分變更按順序執(zhí)行。如果用 Redis 做積分存儲(chǔ)就用 Lua 腳本把讀和寫做成原子操作。這個(gè)教訓(xùn)讓我養(yǎng)成了一個(gè)習(xí)慣所有消費(fèi)回調(diào)里的寫操作都得先問(wèn)自己“這條 SQL 在并發(fā)下執(zhí)行兩次數(shù)據(jù)會(huì)不會(huì)錯(cuò)”。4.2 第二個(gè)坑連接風(fēng)暴代理重啟把消費(fèi)端全部打掛有一次給代理節(jié)點(diǎn)做例行重啟重啟過(guò)程很順利但隨后監(jiān)控顯示消費(fèi)端服務(wù) CPU 一路飆升最后整批宕機(jī)。排查下來(lái)發(fā)現(xiàn)是這么一回事代理重啟后所有消費(fèi)端的長(zhǎng)連接同時(shí)斷開(kāi)各消費(fèi)端為了盡快恢復(fù)連接在極短時(shí)間內(nèi)同時(shí)發(fā)起重連請(qǐng)求。服務(wù)器的進(jìn)程數(shù)、文件描述符、握手線程全部被打滿代理反而因?yàn)檫^(guò)載拒絕了新的連接形成一個(gè)惡性循環(huán)。這個(gè)坑在連接型中間件里非常經(jīng)典英文叫 connection storm中文互聯(lián)網(wǎng)一般叫“連接風(fēng)暴”。根因是消費(fèi)端重連時(shí)機(jī)過(guò)于集中沒(méi)有加入抖動(dòng)延遲。修復(fù)方案也很經(jīng)典消費(fèi)端在斷線重連時(shí)不能立刻重連而要加上一個(gè)隨機(jī)延遲延遲范圍取 1 到 10 秒。這相當(dāng)于讓所有重連請(qǐng)求在時(shí)間軸上散開(kāi)避免對(duì)齊式的集中沖擊。同時(shí)我在代理側(cè)也做了保護(hù)限制單 IP 的連接頻率以及設(shè)置最大半開(kāi)連接數(shù)。這類保護(hù)看著多余但在線上出問(wèn)題的時(shí)候能救命尤其是當(dāng)你通過(guò)域名接入多個(gè)消費(fèi)端時(shí)DNS 刷新可能導(dǎo)致所有消費(fèi)端同時(shí)換 IP 重連。4.3 第三個(gè)坑消息積壓消費(fèi)者擴(kuò)容卻沒(méi)用問(wèn)題出在分區(qū)數(shù)某個(gè)大促活動(dòng)開(kāi)始時(shí)訂單量瞬間翻了好幾倍代理端消息積壓很快到了幾十萬(wàn)條。我第一反應(yīng)是給消費(fèi)端擴(kuò)容機(jī)器從 2 臺(tái)加到 8 臺(tái)結(jié)果積壓數(shù)紋絲不動(dòng)。后來(lái)仔細(xì)看文檔才意識(shí)到模型里有個(gè)關(guān)鍵約束同一個(gè)消費(fèi)組內(nèi)一條消息在同一時(shí)間只會(huì)被一個(gè)消費(fèi)者實(shí)例處理而消息是按分區(qū)分配給消費(fèi)者的消費(fèi)者數(shù)量超過(guò)分區(qū)數(shù)之后多出來(lái)的消費(fèi)者實(shí)例只能閑著。換句話說(shuō)分區(qū)數(shù)決定了消費(fèi)并行度的天花板。Topic 創(chuàng)建時(shí)我設(shè)了 4 個(gè)分區(qū)哪怕后面往消費(fèi)組里塞 100 個(gè)消費(fèi)者實(shí)例同時(shí)最多也只有 4 個(gè)實(shí)例在拉消息。這便是積壓無(wú)法緩解的真正原因。排查思路梳理如下表排查步驟操作結(jié)論1. 檢查消費(fèi)組內(nèi)實(shí)例數(shù)8 個(gè)消費(fèi)者都在線實(shí)例數(shù)不是瓶頸2. 檢查代理分發(fā)狀態(tài)只有 4 個(gè)消費(fèi)者分到消息消息只按分區(qū)數(shù)并行分發(fā)3. 檢查分區(qū)配置Topic 只有 4 個(gè)分區(qū)并行上限為 4擴(kuò)容無(wú)效4. 修改分區(qū)數(shù)并滾動(dòng)重啟分區(qū)提升到 12 個(gè)積壓開(kāi)始快速下降這個(gè)坑暴露了一個(gè)容量規(guī)劃原則Topic 的分區(qū)數(shù)在創(chuàng)建初期就要按業(yè)務(wù)峰值和消費(fèi)可并行的最大規(guī)模來(lái)定而不是按日常流量定。分區(qū)數(shù)過(guò)小后續(xù)擴(kuò)容消費(fèi)端沒(méi)用要修改分區(qū)數(shù)還需要新建 Topic 或做數(shù)據(jù)遷移分區(qū)數(shù)過(guò)大則會(huì)產(chǎn)生過(guò)多小文件影響代理本身的吞吐穩(wěn)定性。實(shí)踐中保守一點(diǎn)的做法是按當(dāng)前日常流量的 4 倍峰值來(lái)預(yù)估所需分區(qū)再乘 1.5 的冗余系數(shù)。4.4 第四個(gè)坑ack 超時(shí)導(dǎo)致頻繁重試消費(fèi)者其實(shí)只是有點(diǎn)慢默認(rèn)的ack_timeout是 30 秒平時(shí)運(yùn)行沒(méi)有任何問(wèn)題。某天一個(gè)消費(fèi)回調(diào)里多了一個(gè)外部接口調(diào)用響應(yīng)偶爾會(huì)飄到 40 秒開(kāi)外。代理端因?yàn)?30 秒沒(méi)收到確認(rèn)判定這條消息投遞失敗于是觸發(fā)重試重試幾秒后外部接口恢復(fù)消息成功被消費(fèi)并確認(rèn)。但原來(lái)的那條還沒(méi)超時(shí)的消息繼續(xù)處理最后也確認(rèn)了。結(jié)果一條業(yè)務(wù)數(shù)據(jù)被執(zhí)行了兩次。這個(gè)問(wèn)題的根子在于代理不知道消費(fèi)者需要多久才能處理完超時(shí)時(shí)間只是一個(gè)拍腦袋的配置。處理方案很直觀讓代理的 ack 超時(shí)時(shí)間大于消費(fèi)者的 p99 處理耗時(shí)即 99% 請(qǐng)求都能在該時(shí)間內(nèi)完成處理而不是等于平均值。通過(guò)監(jiān)控得出消費(fèi)者的 p99 處理耗時(shí)是 50 秒我就把 ack_timeout 改成了 90 秒多留一點(diǎn)余量重試次數(shù)立刻降了下來(lái)。另外一個(gè)相關(guān)的點(diǎn)是客戶端的心跳間隔。如果消費(fèi)者長(zhǎng)時(shí)間不發(fā)送心跳代理會(huì)誤判消費(fèi)者失聯(lián)并釋放連接導(dǎo)致消息被分配給其他實(shí)例。所以心跳間隔也要和 ack_timeout 配合設(shè)置我的習(xí)慣是把心跳間隔設(shè)為 ack_timeout 的一半比如 ack_timeout 90 秒心跳間隔 45 秒一次。5. 性能調(diào)優(yōu)與容量規(guī)劃用數(shù)據(jù)說(shuō)話而不是拍腦袋5.1 吞吐量估算從業(yè)務(wù)目標(biāo)反推技術(shù)參數(shù)接入階段很多人的第一個(gè)問(wèn)題是“我的業(yè)務(wù)需要多少個(gè)分區(qū)、多少臺(tái)代理”。這個(gè)問(wèn)題不該靠猜而應(yīng)該從業(yè)務(wù)指標(biāo)倒推。假設(shè)你的業(yè)務(wù)高峰期每秒產(chǎn)生 2000 條訂單消息每條消息大小約 2 KB你期望消費(fèi)端能在 10 秒內(nèi)把消息全部消化掉且單條消息處理耗時(shí)約 50 毫秒那么每個(gè)消費(fèi)實(shí)例的吞吐大約是 1 / 0.05 20 條/秒。消化 2000 條/秒的流量需要 2000 / 20 100 個(gè)消費(fèi)實(shí)例并發(fā)而這又要求分區(qū)數(shù)至少等于 100。這個(gè)簡(jiǎn)單的算術(shù)題說(shuō)明了一個(gè)直接結(jié)論分區(qū)數(shù)的上限不是消息量而是消費(fèi)端的處理速度。如果你的消費(fèi)端單條處理需要 500 毫秒那 1000 條/秒的流量就需要 500 個(gè)實(shí)例這顯然不現(xiàn)實(shí)。更合理的方案不是無(wú)限擴(kuò)容而是優(yōu)化消費(fèi)端的處理邏輯——比如把 500 毫秒的外部調(diào)用改為異步批量處理單條耗時(shí)降到 50 毫秒后實(shí)例數(shù)和分區(qū)數(shù)都降了一個(gè)數(shù)量級(jí)。5.2 磁盤和內(nèi)存的平衡消息量大的時(shí)候磁盤 IO 和內(nèi)存分配往往是瓶頸。本地存儲(chǔ)模式下消息寫入磁盤文件讀取后刪除。如果寫入頻率高、單條消息小會(huì)產(chǎn)生大量小文件碎片文件句柄數(shù)量上升操作系統(tǒng)層面的 IO 壓力隨之增大。我的調(diào)優(yōu)動(dòng)作主要有三個(gè)一是把segment_size調(diào)大減少分片合并的頻率二是將消息批量刷盤一次寫入合并多批數(shù)據(jù)減少磁盤尋道次數(shù)三是為數(shù)據(jù)目錄單獨(dú)掛一塊 SSD同時(shí)設(shè)置獨(dú)立的 IO 調(diào)度策略避免和其他業(yè)務(wù)的磁盤讀寫互相干擾。內(nèi)存方面我建議給代理進(jìn)程留足 page cache 空間。消息先寫內(nèi)存再刷盤系統(tǒng)會(huì)利用空閑內(nèi)存緩存熱點(diǎn)分片文件。如果服務(wù)器內(nèi)存有 64 GB使用率不高的情況下不需要刻意限制代理的內(nèi)存占用讓它多用 page cache 反而是好事情。真正需要擔(dān)心的是內(nèi)存被打滿導(dǎo)致 swap所以還是要給操作系統(tǒng)保留一定空閑內(nèi)存。5.3 監(jiān)控指標(biāo)這幾項(xiàng)不盯出事必手忙腳亂代理是否健康不能靠等 bug 出來(lái)再看我的監(jiān)控面板里固定放著四個(gè)指標(biāo)。第一是消息積壓數(shù)量這個(gè)直接反映消費(fèi)是否跟得上生產(chǎn)第二是重試消息占比這個(gè)指標(biāo)如果突然上升說(shuō)明消費(fèi)端在報(bào)錯(cuò)或者 ack 超時(shí)第三是死信隊(duì)列增長(zhǎng)速率正常應(yīng)該趨近于零一旦出現(xiàn)有規(guī)律的死信增長(zhǎng)就是有某類固定消息被反復(fù)處理失敗第四是代理進(jìn)程的句柄數(shù)與連接數(shù)這個(gè)可以在連接風(fēng)暴和設(shè)備文件耗盡之前提前預(yù)警。積壓數(shù)量這個(gè)指標(biāo)要額外加一個(gè)按 Topic 分組的統(tǒng)計(jì)因?yàn)槿址e壓看起來(lái)正常但不代表單個(gè) Topic 沒(méi)有異常。我曾經(jīng)遇到過(guò)全局積壓只有幾百條實(shí)際上某一個(gè)訂單 Topic 積壓了 20 萬(wàn)條的情況因?yàn)槠渌?Topic 消費(fèi)很快平均下來(lái)總量并不大結(jié)果掩蓋了問(wèn)題。6. 從消息代理走向任務(wù)調(diào)度hermes-agent 的兩種進(jìn)階用法6.1 定時(shí)任務(wù)與延遲消息的落地實(shí)踐消息代理用順手之后我開(kāi)始嘗試擴(kuò)展它的能力邊界。第一個(gè)用法是把延遲消息做成定時(shí)任務(wù)調(diào)度器。場(chǎng)景是這樣的下單后 15 分鐘未支付需要自動(dòng)關(guān)單用戶申請(qǐng)退款后 48 小時(shí)未處理需要提醒客服。原生實(shí)現(xiàn)往往要起一個(gè)單獨(dú)的任務(wù)掃描表定時(shí)輪詢數(shù)據(jù)庫(kù)效率低且存在掃描傾斜問(wèn)題。把 hermes-agent 和延遲隊(duì)列結(jié)合后整個(gè)流程變成一條流水線業(yè)務(wù)服務(wù)創(chuàng)建訂單時(shí)投放一條延遲消息到代理代理在指定的延遲時(shí)間之后才將消息推給消費(fèi)端消費(fèi)端收到消息后再去數(shù)據(jù)庫(kù)里核實(shí)訂單的支付狀態(tài)若未支付則執(zhí)行關(guān)單若已支付則直接放棄處理。這個(gè)方案省掉了定時(shí)掃描任務(wù)也不用維護(hù)額外的任務(wù)表。這里有個(gè)很重要的細(xì)節(jié)延遲類的回調(diào)處理必須是“復(fù)核式”的不能收到延遲消息就無(wú)條件執(zhí)行動(dòng)作。因?yàn)檠舆t消息可能被重復(fù)投遞而且從投放消息到觸發(fā)回調(diào)的這段時(shí)間里原始業(yè)務(wù)狀態(tài)可能已經(jīng)變了。收到關(guān)單消息時(shí)先查一遍訂單當(dāng)前狀態(tài)已經(jīng)支付就什么都不做這樣整個(gè)機(jī)制才是冪等可靠的。6.2 用消息代理做服務(wù)狀態(tài)感知與自動(dòng)補(bǔ)償?shù)诙€(gè)進(jìn)階用法是狀態(tài)感知與補(bǔ)償說(shuō)白了就是讓消息代理充當(dāng)業(yè)務(wù)的“神經(jīng)末梢”。某個(gè)下游服務(wù)被調(diào)用失敗時(shí)生產(chǎn)端不直接把錯(cuò)誤吞掉而是投遞一條失敗事件到代理專門的補(bǔ)償消費(fèi)者會(huì)分析這類失敗事件結(jié)合失敗頻率和業(yè)務(wù)規(guī)則決定是否啟動(dòng)重試、告警或者切換備用通道。本質(zhì)上是把業(yè)務(wù)里的異常分支也變成一條消息流。以前異常處理散落在各個(gè)服務(wù)里有的記日志、有的打告警、有的重試三次就放棄行為完全不統(tǒng)一。接了消息代理之后我把所有業(yè)務(wù)的失敗事件統(tǒng)一投遞到同一個(gè)失敗處理 Topic由同一個(gè)消費(fèi)組專門負(fù)責(zé)分類處理。這套模式減少了每個(gè)服務(wù)的異常處理代碼量也讓系統(tǒng)里“哪里有坑”變得一目了然——失敗事件累積最多的那個(gè) Topic就是最需要重構(gòu)的業(yè)務(wù)代碼所在。6.3 消費(fèi)能力擴(kuò)展從內(nèi)部解耦到對(duì)外開(kāi)放回調(diào)最后一個(gè)擴(kuò)展方向是對(duì)外開(kāi)放回調(diào)能力。hermes-agent 本身支持 HTTP 推送消費(fèi)者的形態(tài)所以可以不寫服務(wù)端代碼直接讓代理把消息以 HTTP POST 的形式推給一個(gè)公網(wǎng)可訪問(wèn)的回調(diào)地址。這個(gè)特性在對(duì)接內(nèi)部運(yùn)維系統(tǒng)、對(duì)接企業(yè)微信機(jī)器人、或者做外部 Webhook 通知時(shí)特別方便不需要為了發(fā)一條通知而專門起一個(gè) WEB 服務(wù)。對(duì)這類對(duì)外回調(diào)要注意兩個(gè)安全問(wèn)題一是回調(diào)地址必須配置白名單防止代理被惡意用來(lái)做內(nèi)網(wǎng)請(qǐng)求轉(zhuǎn)發(fā)二是回調(diào)地址必須是 HTTPS避免消息內(nèi)容在傳輸過(guò)程中被截獲。內(nèi)部調(diào)試階段用 HTTP 沒(méi)太大問(wèn)題一旦涉及真實(shí)用戶數(shù)據(jù)證書配置這件事不能省。7. 寫在最后消息代理不是一個(gè)終點(diǎn)而是一個(gè)起點(diǎn)從最初為了解決服務(wù)間同步耦合開(kāi)始到后來(lái)逐漸承擔(dān)了延遲任務(wù)、失敗補(bǔ)償、狀態(tài)感知、外部回調(diào)這些職責(zé)hermes-agent 這個(gè)組件在我的技術(shù)體系里已經(jīng)從“一個(gè)中間件”變成了“一套業(yè)務(wù)韌性基礎(chǔ)設(shè)施”?；乜凑麄€(gè)過(guò)程幾個(gè)教訓(xùn)我印象最深。分區(qū)數(shù)一定要按峰值和消費(fèi)并行度來(lái)規(guī)劃而不是按平均流量估否則線上擴(kuò)容會(huì)撞上一個(gè)看不見(jiàn)的天花板。消費(fèi)回調(diào)必須做冪等處理重復(fù)投遞不是 bug不做去重才是。配置 ack 超時(shí)和重試策略之前先去監(jiān)控面板看一眼消費(fèi)端的 p99 耗時(shí)所有參數(shù)調(diào)整都應(yīng)基于真實(shí)數(shù)據(jù)而不是猜。如果只讓我留一條建議那就是消息代理類組件的核心價(jià)值不在“能把消息發(fā)出去”而在“發(fā)不出去、收不到確認(rèn)、重復(fù)投遞、消費(fèi)積壓這些異常場(chǎng)景下系統(tǒng)能不能穩(wěn)定自愈”。把異常路徑設(shè)計(jì)好代理才能真正成為那個(gè)名字里所說(shuō)的信使——平時(shí)無(wú)感關(guān)鍵時(shí)刻絕不掉鏈子。