消息隊列這件事我剛?cè)胄心菚喊阉氲猛ι衩乜傆X得是那種大廠才用得起的中間件。后來在多個項目里親手寫完生產(chǎn)者、消費者甚至搭過集群才意識到它沒那么玄乎但真正要用好需要注意的細節(jié)確實不少。這篇文章就當一份來自實踐的產(chǎn)品介紹來讀。我會把消息隊列的核心價值、主流產(chǎn)品怎么選、上手時必須搞懂的幾個要點以及那些你大概率會遇到的坑一次講清楚。不管你現(xiàn)在是剛接觸后端的新人還是已經(jīng)在業(yè)務里用過一點但總感覺差點意思這篇應該都能給你一些實打?qū)嵉膮⒖肌?. 消息隊列到底解決了什么問題1.1 異步讓主流程不再等“雜事”先從一個最典型也最容易理解的場景說起用戶注冊。以前很多系統(tǒng)的做法是注冊接口里先寫數(shù)據(jù)庫然后同步調(diào)用短信服務、郵件服務、積分服務。結(jié)果用戶點完注冊按鈕頁面轉(zhuǎn)圈兩三秒其實早就在庫里插入成功了剩下時間全花在等下游返回。一次注冊要等好多外部系統(tǒng)這個體驗基本沒法接受。引入消息隊列之后注冊接口只做一件事把用戶注冊成功這條消息扔進隊列馬上返回“注冊成功”。短信、郵件、積分這些服務各自訂閱這個消息后臺慢慢處理。用戶感知到的延遲從幾秒降到幾十毫秒。這就是消息隊列最基礎的價值異步化。但異步不是銀彈它換來的是系統(tǒng)復雜度。原來同步調(diào)用出了問題當場能發(fā)現(xiàn)現(xiàn)在變成發(fā)完消息就不管了下游要是沒消費到可能用戶一直收不到短信。所以用異步之后必須配套可靠性機制、監(jiān)控告警、甚至對賬系統(tǒng)。這也是我后面要反復強調(diào)的一點異步一時爽容災不能省。1.2 削峰把流量洪峰緩沖到平谷第二個場景是削峰也是很多公司引入消息隊列的直接理由。比如一個促銷活動假設平時每秒幾百請求活動開始那一分鐘直接沖到每秒幾萬請求。如果這些請求全部直連數(shù)據(jù)庫和訂單服務數(shù)據(jù)庫基本一秒鐘就會被打滿連接甚至直接卡死。消息隊列能做的是先把海量請求接收下來堆在隊列里然后讓下游消費者按照自己能夠承受的速度去處理比如固定每秒拉取五百條。這樣即使瞬時流量特別高后端系統(tǒng)也不會被一波打垮。流量過去之后隊列里的積壓消息再慢慢被消費掉。簡單說消息隊列像一個水庫上游洪水來了先蓄著下游按需放水。不過要注意削峰只解決了抗壓問題不解決業(yè)務問題。如果隊列里的消息長時間堆積用戶可能以為訂單下了沒反應。所以削峰場景一定要配堆積監(jiān)控以及及時的擴容預案。別等堆積了幾百萬條才想起來看那就已經(jīng)變成事故了。1.3 解耦讓上下游各自演進第三個價值是解耦。沒有消息隊列的時候訂單服務要下單成功通知庫存、通知積分、通知物流就得逐個調(diào)用對方的接口。每個接口都是硬依賴任何一個下游升級接口、臨時故障都會直接影響訂單主流程。更麻煩的是以后每新增一個需要感知訂單的服務訂單代碼都要改一遍。用了消息隊列訂單服務只負責發(fā)布“訂單創(chuàng)建成功”事件至于誰訂閱、什么時候訂閱、訂閱之后怎么處理訂單服務完全不用關心。下游系統(tǒng)按需消費新增業(yè)務只要新起一個消費者組訂閱同樣的事件即可訂單服務零改動。這個模式在微服務架構(gòu)里特別實用也是事件驅(qū)動架構(gòu)的基礎。我自己的體會是解耦帶來的好處是長期收益但代價是引入了消息中間件這樣一個額外的組件團隊需要學習和運維它。所以對于只有兩三個服務的小項目我不建議一上來就套消息隊列等真的出現(xiàn)跨系統(tǒng)協(xié)作復雜或者流量波動明顯時再引入不遲。2. 主流消息隊列產(chǎn)品怎么選2.1 四大產(chǎn)品定位速覽市面上消息隊列產(chǎn)品很多見得最多的是 Kafka、RabbitMQ、RocketMQ、Pulsar 這四類。不少同學選型時喜歡查“哪個性能最強”結(jié)果往往變成口水仗。實際上每個產(chǎn)品都有自己的強項和代價選型首先得看業(yè)務場景。產(chǎn)品核心定位吞吐量延遲特點擅長的方向Kafka大數(shù)據(jù)與流處理極高毫秒級日志采集、數(shù)據(jù)管道、事件流RabbitMQ企業(yè)業(yè)務消息中等微秒級復雜路由、延遲/死信隊列、輕量級業(yè)務RocketMQ互聯(lián)網(wǎng)業(yè)務消息高毫秒級事務消息、定時消息、高可靠業(yè)務場景Pulsar云原生多租戶消息極高毫秒級多集群、跨地域復制、彈性擴縮容Kafka 我用的時間最長。它天生是為高吞吐日志和流處理設計的配合生態(tài)里的流處理引擎特別順手但如果你只想在幾個微服務之間傳個簡單的訂單通知用 Kafka 反而顯得重Topic 里的分區(qū)也好、Offset 管理也好概念都比較硬核。RabbitMQ 最直觀路由靈活社區(qū)里相關資料也特別多適合中小型業(yè)務快速上手但吞吐一上來就容易遇到瓶頸。RocketMQ 在電商、交易這類對可靠性要求很高的場景很受歡迎支持事務消息和延遲消息非常契合業(yè)務消息。Pulsar 是后起之秀存儲和計算分離的設計讓它在彈性伸縮上很有優(yōu)勢多租戶能力也強很適合云原生環(huán)境不過相比其他幾個團隊里的熟悉程度和踩坑資料都少一些。2.2 選型背后的四個關鍵指標我建議選型的時候不問“哪個最好”而是問自己四個問題。第一是吞吐量需求。每天幾百萬條消息和每秒幾十萬條消息完全是兩個世界里。每秒十萬以上Kafka 和 Pulsar 更容易扛住如果只是幾萬甚至幾千RabbitMQ、RocketMQ 也完全夠用。第二是延遲要求。金融行情、在線協(xié)同這類場景對端到端延遲很敏感需要選擇延遲穩(wěn)定的產(chǎn)品異步通知、離線計算這類場景對延遲容忍度高可以優(yōu)先考慮吞吐和可靠性。第三是可靠性和一致性。業(yè)務消息、訂單狀態(tài)這類數(shù)據(jù)丟一條都是事故需要開啟持久化和生產(chǎn)者確認機制RocketMQ 在這類場景下口碑很好日志數(shù)據(jù)丟掉個別條可以重采Kafka 默認配置就足夠。第四是團隊技術棧與運維成本。如果團隊只熟悉 Java 和 SpringRocketMQ、RabbitMQ 的接入和排查更平滑如果已經(jīng)有大數(shù)據(jù)生態(tài)Kafka 幾乎是必然選擇。還有一個很容易被忽略的點運維能力。自建一套集群不只是裝個服務那么簡單還要考慮監(jiān)控、擴縮容、故障恢復。如果公司沒有專門的中間件團隊云廠商提供的托管型消息隊列其實是更穩(wěn)妥的選擇省下的運維時間足夠你開發(fā)好幾個業(yè)務模塊了。3. 消息隊列的實操要點從入門到躲坑3.1 核心概念生產(chǎn)者、消費者、Topic、分區(qū)和 Offset剛開始用消息隊列最難跨越的是概念門檻。我用 Kafka 的模型來講解因為這幾個概念在所有產(chǎn)品里基本都是相通的。Topic 可以理解成一個業(yè)務消息的信箱。比如訂單服務發(fā)消息就發(fā)到名為 order-event 的 Topic 里。這個 Topic 下面會被拆成多個 Partition也就是分區(qū)。分區(qū)的意義在于并行一個分區(qū)同一時刻只能被同一個消費組里的一個消費者處理分區(qū)越多能并行消費的消費者就越多。每條消息寫入某個分區(qū)后會得到一個遞增的 Offset它就像消息在分區(qū)里的游標代表這條消息的位置。消費者讀取消息的時候需要記錄自己消費到哪個 Offset 了下次從記錄的 Offset 繼續(xù)讀這就是消費進度。生產(chǎn)者通過負載均衡策略決定消息寫到哪個分區(qū)默認是輪詢或按 key 哈希。如果想要某個訂單的消息嚴格按照順序處理就按訂單 ID 哈希讓同一個訂單的消息永遠進同一個分區(qū)。這個設計也很重要后面講順序性會再說。消費者側(cè)使用消費組多個消費者實例組成一個組組內(nèi)的不同實例分別消費不同分區(qū)合在一起消費完整個 Topic如果希望多個服務都完整消費同樣的消息就分別用不同的消費組組與組之間是相互獨立廣播的。3.2 消息可靠性與順序性不是所有消息都要“不丟不重不亂”很多剛接觸消息隊列的人一開始就提一個高要求消息一定要嚴格不丟失、不重復、不亂序。這個目標聽起來很完美但在分布式系統(tǒng)里幾乎不可能同時做到。CAP 理論放這兒同樣適用關鍵是在業(yè)務需求里做取舍。先說可靠性。消息從生產(chǎn)到消費要經(jīng)過三段鏈路生產(chǎn)者把消息發(fā)送給 BrokerBroker 把消息落盤消費者從 Broker 拉取消息并處理。任何一段都可能出問題。生產(chǎn)階段要開啟生產(chǎn)者確認機制比如 Kafka 的 acks 設置。acks0 就是發(fā)完就完性能最高但可能丟消息acks1 是寫入主副本就返回能夠抗住單點故障acksall 是所有副本都寫入成功才算成功安全性最高但性能會下降。Broker 存儲階段要注意刷盤策略和副本數(shù)內(nèi)存里沒來得及落盤就宕機數(shù)據(jù)可能丟。消費階段核心是“處理完再確認”不要在消息還沒處理完的情況下就提交 Offset。再說順序性。有些業(yè)務對消息順序有硬性要求比如支付狀態(tài)要先“創(chuàng)建”再“成功”順序反了業(yè)務就亂了。全局順序在所有消息隊列里都很難做成本也非常高一般不做。正確做法是分區(qū)有序把需要保證順序的消息通過相同的 key 路由到同一個分區(qū)這樣單分區(qū)內(nèi)的消息天然有序。這就是為什么按訂單 ID 哈希寫入分區(qū)是通用做法。最后是權重問題。我見過不少團隊為了追求極端的可靠性所有消息都開啟強同步復制結(jié)果吞吐量掉了一半業(yè)務根本扛不住。我的建議是給不同 Topic 設置不同的可靠性級別核心交易消息用最高可靠性日志類消息用低可靠性高吞吐配置別用一套參數(shù)打天下。3.3 冪等消費與消費進度管理防止重復和漏處理消息隊列里重復消費是很常見的事。網(wǎng)絡抖動導致消費者處理完消息但確認信息沒發(fā)出去Broker 超時后就會重新投遞消費者在處理過程中宕機還沒提交 Offset重啟后也會從舊 Offset 重新拉取。所以只要用了消息隊列就必須默認消息可能重復。應對重復消費的標準姿勢是“冪等”也就是不管這條消息被處理多少次最終結(jié)果保持一致。常見做法有幾種。最簡單的是在消費者里記錄已經(jīng)處理過的唯一業(yè)務 ID處理前查一下或者用 Redis SETNX 搶占如果之前處理過就直接跳過。還可以在數(shù)據(jù)庫表里建立唯一索引比如訂單流水號插入時如果重復就捕獲異常。更復雜的用狀態(tài)機校驗比如訂單狀態(tài)只有“待支付”才能改成“已支付”如果重復消息嘗試把“已完成”改成“已支付”就說明沒有可轉(zhuǎn)移的狀態(tài)直接忽略。冪等設計屬于業(yè)務層的事但每一個用消息隊列的團隊都必須正視這個問題。消費進度管理也很關鍵。Kafka 通過提交 Offset 來記錄消費位置有自動提交和手動提交兩種。我強烈建議在關鍵業(yè)務里使用手動提交并且先執(zhí)行業(yè)務處理再提交 Offset。自動提交配置簡單但可能存在“消息剛拉到還沒來得及處理就提交”的風險一宕機消息就丟了。手動提交也分兩種先處理再提交可能導致重復消費先提交再處理可能導致漏消費。兩者之間選前者因為重復好于丟失業(yè)務上可以通過冪等抵消丟失則需要補數(shù)據(jù)成本高得多。RabbitMQ 類似通過消息確認機制ACK來控制消費者處理完后主動調(diào)用 basicAckBroker 才會刪除消息。如果消費者一直不返回 ACK消息會重新進入隊列這也是一種重試機制。4. 使用過程中的高頻事故與排查技巧4.1 消息堆積別等爆了才想起來看消息隊列最經(jīng)典的事故莫過于消息堆積。消費者處理不過來生產(chǎn)速度遠大于消費速度隊列積壓越來越多帶來的直接體驗就是業(yè)務延遲、用戶投訴、甚至數(shù)據(jù)對不上。遇到堆積第一步是看監(jiān)控確認堆積量、消費速率、生產(chǎn)速率先分清是生產(chǎn)端突然暴漲還是消費端能力下降。如果消費速度明顯偏低先看消費者實例是不是掛了幾個最常見的問題是某個消費者進程內(nèi)存溢出退出但消費組還掛著它導致部分分區(qū)沒有消費者處理。這時要看分區(qū)的分配情況把掛掉的實例摘掉讓其他實例頂上。如果消費者都在正常工作但消費速度就是不到生產(chǎn)速度的一半大概率是業(yè)務處理邏輯太慢比如消費消息時同步調(diào)用了好幾個外部服務一個接口慢兩三秒整體消費速度直接拖垮。對策有幾個方向一是增加消費者實例數(shù)注意消費組的并發(fā)數(shù)受限于分區(qū)數(shù)實例數(shù)量超過分區(qū)數(shù)沒意義得先考慮增加分區(qū)二是對消費鏈路做優(yōu)化把非核心的同步調(diào)用改成異步或者去掉不必要的等待三是批量消費拉取一次處理一批減少消息拉取的開銷。還有一個臨時緩解手段就是緊急關閉下游一些不需要實時性的處理邏輯只保留核心數(shù)據(jù)落庫先把堆積削下去再回頭補處理。4.2 重復消費為什么做不到“恰好一次”以及怎么兜底我遇到過很多回因為重復消費引發(fā)的線上問題用戶點了兩次申請積分加了兩倍交易狀態(tài)回調(diào)處理了兩次生成了兩筆流水?？梢哉f只要是分布式系統(tǒng)重復消息就是常態(tài)任何號稱“恰好一次”的方案本質(zhì)上都是在某個環(huán)節(jié)做了冪等兜底而不是真的只投遞一次。排查重復消費第一步是看消費端是否有空閑提交現(xiàn)象。如果使用自動提交并且處理一條消息耗時較長消費者可能在處理完之前就提交了 Offset這時候如果進程崩潰重啟后會從更早的位置開始消費之前處理過的消息就會重復。解決辦法是把自動提交關掉改成手動提交并且保證處理成功之后再提交。第二個常見原因是超時重投。比如網(wǎng)絡抖動消費者處理完了但 ACK 沒有得到 Broker 確認Broker 重試投遞導致同一消息再次進入消費者。這種情況在代碼層面很難完全避免只能靠業(yè)務冪等兜底。對于冪等我再推薦一個比較實用的模式給每條消息生成全局唯一的消息 ID消費者落庫時把消息 ID 作為主鍵或者唯一索引如果有重復插入就直接失敗。另一種方式在消費之前用 Redis 寫一條唯一鍵例如 order_id event_type設置一個合理的過期時間如果寫入成功則繼續(xù)處理如果寫入失敗說明已經(jīng)處理過直接返回成功。這個方案在對抗重復消費時效果很明顯而且實現(xiàn)成本低我基本每個項目都會用。4.3 消息丟失從生產(chǎn)到消費的每一環(huán)都要堵數(shù)據(jù)丟失是消息隊列里最嚴重的事故。有一次我在壓測環(huán)境里下了上萬條消息重啟 Broker 后發(fā)現(xiàn)少了一些排查后才發(fā)現(xiàn)生產(chǎn)端沒有配置可靠的確認機制。消息丟失通常不是單一環(huán)節(jié)的問題而是每一環(huán)節(jié)的可靠性沒做到位。規(guī)范排查看三個位置。生產(chǎn)端確認消息是否開啟了“發(fā)送確認”。Kafka 的 acks 配置如果等于 0生產(chǎn)者發(fā)出消息后不等待任何確認一旦網(wǎng)絡閃斷消息就丟了。如果用的是 Kafka 生產(chǎn)客戶端建議生產(chǎn)核心消息時把 acks 設為 all同時在 send 回調(diào)里檢查異常發(fā)送失敗要做重試。Broker 端看副本數(shù)和落盤策略。單副本集群里Broker 宕機基本等于數(shù)據(jù)全丟至少要設置 2 個副本以上并開啟 in.sync.replicas落盤方面默認的刷盤策略是后臺異步刷盤如果允許極端情況下的少量丟失可以使用默認配置以求性能但如果是交易類數(shù)據(jù)需要根據(jù)產(chǎn)品能力開啟同步刷盤。消費端看是否因為自動提交 Offset 導致消息沒處理完就被標記成已消費。另一個容易被忽略的點是消費端代碼異常比如消息拉取到了但處理時拋出異常后沒有正確捕獲也沒有重試策略消息直接被跳過。好的實踐是使用重試隊列或死信隊列處理失敗的消息先進入重試隊列等待再次嘗試多次失敗后進入死信隊列由人工介入處理。消息丟失的排查有時候需要“全鏈路日志”。我建議在生產(chǎn)者和消費者的入口、出口都打印消息 ID 和關鍵業(yè)務信息萬一真丟了可以通過日志查這條消息是否被生產(chǎn)、是否被拉取、是否處理成功定位到具體斷了哪一環(huán)。沒有日志排查消息丟失會像是大海撈針。5. 運營和維護的經(jīng)驗從設計時就避開雷5.1 監(jiān)控把堆積量當成水位線很多團隊引入消息隊列是從“跑通”開始的能發(fā)能收就覺得行了。可一旦流量上來或者業(yè)務開始時間敏感第一個遇到的問題就是沒有任何監(jiān)控指標。等用戶投訴了才登服務器看日志這種被動方式會非常痛苦。我強烈建議消息隊列接入的當天就做好基礎監(jiān)控。最核心的指標有這么幾個生產(chǎn)速率、消費速率、積壓量Lag、消費延遲、Broker 的 CPU 和磁盤。其中積壓量是最直觀的水位線我們?nèi)粘６⒌木褪歉鱾€ Topic 的積壓曲線。給積壓量設置告警閾值比如某 Topic 積壓超過一千條且持續(xù)三分鐘就發(fā)告警超過 1000 條持續(xù)五分鐘就走電話告警。閾值需要根據(jù)每個 Topic 的業(yè)務量動態(tài)調(diào)整不然要么天天誤報要么真出事故了還沒反應。Kafka 可以通過消費者組 Lag 來監(jiān)控RabbitMQ 可以看隊列 Ready 消息數(shù)RocketMQ 有專門的消費進度和堆積 Web 控制臺Pulsar 也有類似的指標。無論哪種產(chǎn)品監(jiān)控數(shù)據(jù)都要落到統(tǒng)一的監(jiān)控面板里別讓運維或者開發(fā)去服務器上一條一條翻命令。5.2 分區(qū)規(guī)劃不是越多越好一個常見誤區(qū)是“分區(qū)數(shù)越多吞吐越高”。分區(qū)多了確實能增加并行度但每個分區(qū)在 Kafka 里對應文件資源和內(nèi)存開銷也要參與 Leader 選舉。分區(qū)數(shù)太多會讓服務器的文件句柄飆升選舉時間變長反而影響穩(wěn)定性。關于分區(qū)數(shù)量業(yè)內(nèi)常用的經(jīng)驗估算公式是目標吞吐量除以單分區(qū)消費能力再留出一定余量。假設單個分區(qū)每秒能穩(wěn)定消費 500 條消息業(yè)務目標每秒需要消費 5000 條那至少需要 10 個分區(qū)考慮到突發(fā)流量和未來的增長再翻一倍設為 20 個比較穩(wěn)。分區(qū)數(shù)的調(diào)整成本也要提前算清楚。Kafka 支持新增分區(qū)但分區(qū)一旦增加key 與分區(qū)的映射關系可能變化原本保證的同一個 key 進同一個分區(qū)會被打破順序性可能受影響。所以盡量在業(yè)務上線前就把分區(qū)數(shù)規(guī)劃好上線后不到萬不得已不要改。5.3 消息隊列不適合什么場景最后想潑一點冷水。消息隊列雖然好用但有些場景真的別硬上。首先是強一致性的分布式事務。消息隊列本質(zhì)上是最終一致你不可能靠它實現(xiàn)多個數(shù)據(jù)庫的原子提交如果業(yè)務要求實時強一致應該考慮本地消息表加事務性消息等更嚴謹?shù)姆桨付皇前严㈥犃挟敹档?。其次是請?響應這種需要同步返回值給調(diào)用方的場景。消息隊列是單向異步通信不適合需要立刻拿到業(yè)務結(jié)果的接口比如用戶登錄校驗硬要繞一圈消息隊列只會增加無謂的延遲。另外消息隊列也不適合解決數(shù)據(jù)庫自身瓶頸比如某張表的慢查詢靠發(fā)消息并不能讓數(shù)據(jù)庫查詢變快最多只是把請求挪到了后臺改了表象沒改本質(zhì)。我覺得選型和使用消息隊列本質(zhì)上是在跟系統(tǒng)的復雜度做博弈。用好了它是架構(gòu)里的重要緩沖器能幫你扛住流量洪峰、讓團隊協(xié)作更清爽用不好它就是系統(tǒng)里最隱蔽的雷平時看不出來關鍵時刻給你來一下大的。最后再分享一個我個人的習慣每次設計消息隊列方案我會先寫清楚“如果這條消息丟了會怎樣”再決定可靠性投資先寫清楚“如果這條消息重復了會怎樣”再決定冪等方案。把這兩件事想明白消息隊列就成功了一半。希望這篇產(chǎn)品介紹對你有點幫助也歡迎在實際使用中驗證這些經(jīng)驗再形成你自己的判斷。