AWS帳號開戶 AWS MQ (ActiveMQ/RabbitMQ) 訊息積壓与 Broker 記憶體告警排查

一、先把問題看清楚：積壓不等於記憶體告警，兩者常常互相放大

AWS帳號開戶 AWS MQ 上的訊息積壓，很多時候不是單一故障，而是多個小問題疊在一起：生產速度突然變快、消費端處理變慢、某個下游服務卡住、訊息過大、重試策略失控，最後把 broker 的記憶體頂上去。當 broker 開始告警，生產端可能被限流，消費端又因為請求堆積而更慢，整個系統就像被自己拖住一樣。

排查這類問題，最忌諱一上來就加大 broker 規格。擴容可以止血，但很少是根因。你真正要找的是：是哪一類訊息在堆，堆在佇列的哪個位置，消費者到底有沒有在工作，broker 的記憶體是被大量待投遞訊息吃掉，還是被未確認訊息、連線數、交換器路由壓力推高。這些線索不分 ActiveMQ 或 RabbitMQ，都可以先用同一套思路看。

簡單說，積壓是結果，記憶體告警是症狀。只盯著告警本身，通常只能暫時壓下去；把訊息流向、消費行為和 broker 資源一起看，才找得到真正卡住的地方。

二、先分清你用的是 ActiveMQ 還是 RabbitMQ

兩者都叫訊息中介，但觀察重點不完全一樣。ActiveMQ 更常看隊列深度、入列和出列速率、記憶體使用率、持久化存儲壓力；RabbitMQ 則要特別看 ready 和 unacked 兩類訊息、記憶體水位、磁碟警戒、連線與通道數。AWS MQ 雖然是託管服務，不能像自建環境那樣直接進機器看進程，但 CloudWatch 指標和 broker 日誌已經足夠把八成問題定位出來。

ActiveMQ 的觀察重點

ActiveMQ 裡最直接的信號是 QueueSize、EnqueueCount、DequeueCount、ConsumerCount 這幾個數字。如果入列一直漲、出列幾乎不動，問題多半在消費端；如果隊列大小不大，但記憶體百分比一路升高，可能是訊息體太大、暫存太多，或者某些長時間未確認的會話占住了 broker 資源。另一個容易被忽略的點是 TempPercentUsage 和 StorePercentUsage，前者和臨時訊息、非持久化壓力有關，後者和持久化存儲有關。很多人只盯 MemoryPercentUsage，卻沒發現真正先爆的是磁碟或暫存區。

• EnqueueCount 大於 DequeueCount 很多，且差距持續擴大，表示積壓正在形成。
• ConsumerCount 為零，通常不是 broker 的問題，而是消費服務已經掉線或啟動失敗。
• 記憶體高但隊列不算大，常見於單筆訊息很大、同時存在大量待分發訊息，或 producer 突刺太猛。
• AWS帳號開戶 如果 broker 日誌出現流控、慢消費、阻塞寫入等字樣，通常已經不是早期階段。

RabbitMQ 的觀察重點

RabbitMQ 要先看 messages_ready 和 messages_unacknowledged。前者代表還沒投遞給消費者的訊息，後者代表已經送出但還沒 ack 的訊息。messages_ready 很高，通常是消費者不夠快或根本沒在跑；messages_unacknowledged 很高，則更像是消費者拿到了訊息，但處理很慢、卡在外部依賴、或 ack 時機設計不合理。當記憶體告警出現時，RabbitMQ 會啟動保護機制，讓生產者被限制，這時候你看到的不是單純的延遲，而是整條輸入鏈路都被壓住了。

• messages_ready 高，messages_unacknowledged 低，優先看消費能力和併發數。
• messages_unacknowledged 高，優先看 ack 模式、prefetch、處理時間與外部呼叫。
• AWS帳號開戶 連線數和通道數異常飆高，可能是應用重連風暴，會直接推高 broker 負載。
• 磁碟空間不足時，RabbitMQ 也可能出現警戒，這會讓問題從記憶體擴散到持久化層。

三、排查順序：從流量、消費、再到 broker

真正高效的排查，不是先看告警，而是先看訊息流向。你要回答三個問題：訊息是不是進太快、是不是出太慢、是不是卡在 broker 裡不出去。只要這三件事分清楚，後面就容易很多。

第一步：先確認是哪幾個佇列在堆

很多團隊一開始只看整體 broker 指標，結果看到記憶體高、CPU 高，卻不知道是哪個業務在製造壓力。正確做法是把 queue 級別的數據拉出來，先鎖定前幾個成長最快的佇列。若是某個特定業務的峰值太高，通常問題在流量設計；若是很多佇列同時上升，則更像共用消費服務失效、共用外部依賴慢、或 broker 本身進入瓶頸。

第二步：看生產速率和消費速率是否失衡

如果 EnqueueCount 一直上升，而 DequeueCount 幾乎平線，通常不是 broker 轉不動，而是消費端沒跟上。這時候要看消費服務的部署數量、執行緒池大小、處理單筆訊息所需時間，以及是否有外部 API、資料庫或第三方系統拖慢整體速度。很多積壓不是訊息太多，而是每筆訊息背後做了太多事情，導致吞吐量遠低於預期。

如果兩邊都在漲，但入列比出列快很多，說明系統在用未來的時間還債。這種情況短時間內可能看不出故障，但一旦遇到流量高峰、節點抖動或下游延遲，積壓就會快速放大，最後把 broker 推到告警區。

第三步：檢查 ack、交易與重試策略

消費端不是只要收到訊息就算完成，真正關鍵是 ack 有沒有正常送出。RabbitMQ 常見的問題是手動 ack 放在太晚的位置，導致一批訊息長時間維持在 unacked 狀態；ActiveMQ 則可能因為事務提交太慢、同步處理太重，讓會話長時間占住資源。若再加上重試機制沒設好，失敗訊息會在短時間內反覆回到隊列，形成看似不停前進、實際越積越多的假象。

還要特別注意 poison message，也就是某條訊息資料有問題、每次都處理失敗。這類訊息最可怕的地方，不是它本身，而是它會卡住整批處理流程。若沒有死信隊列或隔離機制，系統會把大量時間花在同一條訊息上，最後變成整個隊列都在為少數壞資料買單。

第四步：看 broker 本身是不是已經開始限流

ActiveMQ 的記憶體使用率接近上限時，broker 會開始做流控；RabbitMQ 一旦觸發 memory alarm，也會限制生產者寫入。這時候你會看到的現象通常很一致：producer 延遲增加、發送失敗率上升、連線變慢、consumer 似乎沒變，但隊列仍然持續增加。這不是錯覺，而是 broker 正在保護自己不被打爆。

當 broker 已經進入保護狀態，先不要急著重啟。重啟只會清空當下狀態，卻看不到是什麼把它推到那裡。先保存監控圖、日誌與隊列快照，確認是短時間流量尖峰，還是長期資源配置不足，再決定要不要擴規格、拆分流量或重構消費邏輯。

四、最常見的五個根因

實際上，大部分 AWS MQ 的積壓與記憶體告警，最後都能落到下面幾類原因。只要你能快速分辨是哪一類，處理速度會快很多。

1. 消費端處理太慢

這是最常見的原因。比如消費端每筆都要查資料庫、調外部服務、寫多張表，或者做複雜計算，單筆處理時間一長，併發再高也追不上入列速度。此時最直接的做法不是盲目加 broker，而是提高消費者並行數、縮短單筆處理路徑、把重活拆出去，讓訊息處理盡量保持短、平、快。

2. ack 與事務設計不合理

如果手動 ack 放在最後，任何一個外部依賴慢一點，訊息就會長時間留在 unacked 狀態。若再加上事務範圍過大，一次拉太多訊息，消費者雖然看起來很忙，實際上卻是卡在少數幾批訊息上。這種問題常被誤判為 broker 不穩，其實是應用層把確認流程設計得太重。

3. 訊息體過大或突發流量太集中

很多系統平時都沒事，一到批次匯入、活動結算、重試風暴就開始爆。原因常常不是消息數量，而是單筆 payload 太大，或短時間內湧入大量相似訊息。大訊息會同時吃記憶體、網路和序列化成本，對託管 broker 來說尤其敏感。能拆就拆，能壓縮就壓縮，能只傳必要欄位就不要把整包資料丟進隊列。

4. 消費者數量不足或連線不穩

如果消費端節點數太少，任何一個節點抖動都可能讓吞吐量瞬間掉下來。連線不穩更麻煩，因為它會帶來重連、重新訂閱、重複投遞與短時間內的大量握手成本。當你看到 broker 連線數忽高忽低，或日誌裡反覆出現 disconnect、reconnect、channel close，應該先去查應用和網路，不要先怪 broker。

5. 死信與重試機制失控

重試本來是保護機制，但設計不好就會變成放大器。比如失敗訊息立即重送、沒有退避時間、沒有最大重試次數、沒有死信隔離，結果就是同一批壞訊息不斷進入主隊列。這不只會讓隊列深度上升，還會增加 broker 的記憶體壓力，因為那些反覆流轉的訊息一直占著位置不放。

AWS帳號開戶 五、AWS MQ 上的處理原則：先止血，再修正，最後優化

如果現在已經在告警，第一件事是先讓系統恢復可用。止血的手段通常有三個：暫時擴大消費者併發、降低非核心流量、把明顯有問題的消息隔離出去。這些做法不一定漂亮，但在事故現場很實用。重點是讓隊列先下降，讓 broker 的記憶體水位先離開危險區。

接著才是修正。修正的核心通常是三件事：減少每筆訊息的處理時間、降低單批消息對 broker 的壓力、建立清楚的錯誤隔離機制。你可以增加消費者實例，但若每筆消息都要等外部服務回應，吞吐量還是上不去。你也可以升級 broker 規格，但如果生產節奏和消費節奏一直失衡，記憶體告警遲早還會回來。

最後才是優化。真正健康的消息系統，應該在流量變大前就能看出趨勢。你需要把 queue depth、入列出列速率、unacked、記憶體、水位、消費失敗率、重試次數、死信數量都納入監控，並且設定合理告警門檻。這樣當問題還在萌芽期時，就能先處理，而不是等到 broker 已經開始自我保護才反應。

六、實戰排查清單

遇到 AWS MQ 訊息積壓與記憶體告警時，可以直接照下面的順序做。順著看，比漫無目的翻圖表有效得多。

• 先確認是 ActiveMQ 還是 RabbitMQ，再決定看哪一組核心指標。
• 找出積壓最快的隊列，不要只看整體 broker 指標。
• 比對入列與出列速度，判斷是生產太快還是消費太慢。
• 檢查消費者是否在線，是否有重連風暴、異常退出或處理阻塞。
• 查看 ack、事務、prefetch、重試與死信策略是否合理。
• 檢查訊息大小、外部依賴、資料庫延遲與第三方服務超時。
• 確認 broker 是否已觸發記憶體或磁碟保護機制。
• 最後再考慮擴容、拆分隊列、調整架構或重構業務流程。

如果把這套順序養成習慣，很多看起來很大的事故，其實幾分鐘就能定位。訊息系統的問題，表面上是佇列在長，背後其實是節奏失衡。你把節奏找回來，積壓自然會退，記憶體告警也會跟著消失。

真正成熟的做法，不是等 broker 告警才補救，而是讓監控提早告訴你：哪個隊列開始變長，哪個消費者開始變慢，哪個重試開始失控。只要這三件事盯緊，AWS MQ 的 ActiveMQ 或 RabbitMQ 都能跑得穩，問題也不會總是等到深夜才跳出來。