雲訊息佇列 RabbitMQ 版提供高可用的 RabbitMQ 相容服務，併兼容 AMQP 0-9-1 協議。需要注意的是，產品 SLA 保障的是平台側服務可用性，不等同於客戶業務端到端 100% 可用。
背景
根據官方 RabbitMQ 服務等級協議，RabbitMQ 服務可用性以單個執行個體為維度，按單個自然月計算，當前協議中的基礎承諾為不低於 99.95%。以 30 天自然月估算，99.95% 對應約 21.6 分鐘的協議口徑不可用時間。該數值僅用於理解 SLA 度量，不等同於業務可接受的故障視窗；實際計算以協議中的服務不可用定義、除外情形及訂購時生效協議為準。
業務整體可用性還受到用戶端重連、網路與 DNS、應用發布、消費處理能力、等冪能力、跨地區災害、版本生命週期和客戶自身配置等因素影響。若商務持續性目標高於單一實例產品 SLA，需要在應用側和資源架構側主動建設多執行個體、多地區、切換和訊息等冪能力。
不同執行個體類型或規格的 SLA 度量可能不同，可參考執行個體類型，具體權益以購買頁、阿里雲官網和訂購時生效協議為準。多執行個體方案不會形成新的產品 SLA，也不能將兩個執行個體的 SLA 簡單相乘；業務可用性取決於故障隔離、訊息同步、用戶端切換和演練效果。
架構邊界
雲訊息佇列 RabbitMQ 版對外相容 AMQP 0-9-1 協議，服務端採用託管化多節點架構。公網、VPC 和 私網串連存取點等接入方式，以控制台和官方文檔支援情況為準。
RabbitMQ 版通過多節點和多可用性區域能力提升執行個體可用性。服務端由多個節點共同承載串連和請求，單個服務端節點或可用性區域異常時，多節點能力有助於降低對執行個體可用性的影響；具體能力以執行個體類型、地區和購買頁說明為準。
用戶端串連由服務端按 Connection 粒度承載。建立多條長期 Connection 有助於讓串連和流量在多個節點之間更充分分散，但不表示每條 Connection 必然落到不同節點。單個 AMQP Connection 上建立多個 Channel 只能提升該串連內的並發複用，不能替代 Connection 層級的服務端節點分散。高並發或核心業務應建立多條長期 Connection，並讓生產者和消費者在串連池內分散使用，避免所有流量集中在單條或少數串連上。
但以下情境不是單一實例架構天然解決的：
地區級故障、跨地區網路故障或客戶側 VPC、DNS、安全性群組異常。
用戶端未配置自動重連、Channel 重建和消費者重新訂閱。
用戶端只使用極少數長期 Connection，導致串連和流量無法在服務端多個節點之間充分分散。
客戶消費慢、業務處理失敗、訊息堆積或超配額限流。
客戶未做等冪，切換或回放導致重複消費、亂序或業務副作用。
客戶側須完成的改造
無論選擇哪種執行個體形態，建議優先按照雲訊息佇列 RabbitMQ 版官方最佳實務完成接入和改造，完整實踐可參考SDK 使用注意事項和Spring 整合最佳實務。以下為需重點確認的改造項（不限於此）：
自動重連：串連斷開後自動重建 Connection，並根據所用 SDK 確認拓撲和消費者恢複能力，具體可參考用戶端配置自動重連。
多 Connection 分散流量：根據生產和消費並發、執行個體 Connection 配額配置多條長期 Connection，並將生產和消費串連分開使用。不要把所有生產和消費都壓在單條 Connection 上，也不要頻繁建立和關閉 Connection。通用建議可參考Connection 和 Channel，Spring 用戶端可參考Spring 整合最佳實務。
Channel 重建：RabbitMQ Channel 不是永久資源。如發生協議異常、資源聲明衝突、限流等情境，需要重建 Channel。資源聲明衝突應先修正聲明參數，限流情境應先退避和降載，避免迴圈重建 Channel。Channel 可以複用 Connection，但不能替代 Connection 層級的服務端節點分散，具體可參考執行個體限流最佳實務。
消費者恢複：重連後重建立立消費訂閱，恢複
basic.consume和消費者回調；同時確認排他 Queue、Consumer Tag 等資源在重連後的恢複行為符合預期。Publisher Confirm：生產端通過 Publisher Confirm 判斷服務端是否已接收並承擔訊息責任。Publisher Confirm 不代表消費者已成功處理訊息；確認逾時或未確認時，應使用相同業務訊息 ID 按等冪規則重試。
消費 ACK 和重試：業務處理成功後再 ACK；失敗時按業務策略執行 reject、nack、有限次數重試或進入死信，避免無限 requeue 形成重試迴圈。
等冪處理：生產、路由、切換和回放都可能帶來重複訊息，生產端應為同一業務訊息保持穩定的業務訊息 ID，消費端必須按業務 ID 去重，具體可參考訊息等冪。
限流與熔斷：執行個體異常或業務下遊異常時，生產端應限流並對重試設定退避和上限，避免重試放大、堆積和雪崩，具體可參考執行個體限流最佳實務。
接入地址重新整理：如果通過配置中心或客戶自管網域名稱切換執行個體，用戶端需要支援重新整理接入地址，避免長期持有舊地址。使用客戶自管網域名稱時，還應驗證 DNS TTL、用戶端或 JVM DNS 緩衝以及 TLS 主機名稱校正行為。
建議方案
方案 | 適用情境 | 容災範圍 | 核心前置要求 |
非核心鏈路，RTO 和 RPO 要求不高 | 執行個體內多節點和多可用性區域 | 用戶端改造 | |
同地區執行個體級故障恢複，暫不做跨地區容災 | 同地區執行個體級 | 訊息同步、切換預案、等冪 | |
防範地區級故障或跨地區部署 | 跨地區 | 跨地區網路、訊息同步、切換預案 | |
兩地區或兩執行個體同時承載流量 | 跨地區或跨執行個體 | 強等冪、去重、衝突處理、最終一致性 |
單一實例基準方案
適用範圍：非核心鏈路、可接受短時不可用、RTO 和 RPO 要求不高的業務。
建議：
根據執行個體類型和使用限制，選擇滿足業務 TPS、Queue、Connection、訊息大小和保留時間要求的執行個體規格。
若業務對穩定性、資源隔離或容量確定性有更高要求，建議優先選擇鉑金版或 Serverless 獨享版，具體能力和 SLA 以執行個體類型說明及購買頁為準。
用戶端開啟 Connection 自動重連，並具備 Channel 重建和消費者恢複能力。
按應用執行個體和業務並發建立多條長期 AMQP Connection，通過串連池分散生產和消費流量；不建議用單條 Connection 承載全部流量後只增加 Channel 數。
配置 Publisher Confirm、消費 ACK、逾時重試、死信和警示。
按官方版本管理和升級通知要求完成執行個體版本升級，不長期運行已到期或停止維護的版本。
按監控指標對串連數、發送和消費流量、錯誤碼、Queue 堆積、消費延遲和限流等關鍵計量配置警示。
風險：
單一實例方案只能獲得對應執行個體類型的產品 SLA，不等同於業務側 100% 可用。
若業務不可接受單一實例故障視窗，需要升級為多執行個體容災方案。
同地區雙執行個體主備方案
適用範圍：希望提升同地區內執行個體級故障恢複能力，但暫不做跨地區容災的核心業務。
關鍵設計：
在同一地區購買兩個 RabbitMQ 執行個體。若業務對穩定性、資源隔離或容量確定性有更高要求，建議優先選擇鉑金版或 Serverless 獨享版；同地區雙執行個體仍不能替代跨地區容災。
主備執行個體的 Vhost、Exchange、Queue、Binding、帳號許可權和網路存取原則應保持功能等價。建議通過自動化配置或應用啟動聲明管理資源，避免人工配置漂移；主備執行個體訪問憑證應分別管理並按安全性原則輪換。
訊息同步可以選擇以下方式：
應用雙寫：生產端同時寫入主備執行個體。應用雙寫可降低單路寫入失敗造成的資料缺口，但不提供跨執行個體原子性保證，需要處理部分成功、確認逾時、等冪重試和補償。
全球訊息路由：通過全球訊息路由將主執行個體源 Queue 中的訊息非同步轉寄到備執行個體 Queue 或 Exchange。該方式存在同步延遲，RPO 取決於路由積壓和網路狀態；功能支援情況以執行個體類型說明和控制台為準。
全球訊息路由會消費源 Queue 並將訊息轉寄至目標端，不是對源 Queue 的旁路複製。不要直接複用業務消費者正在消費的 Queue 作為路由源。建議將源 Exchange 同時綁定業務 Queue 和容災同步專用 Queue，再以容災同步專用 Queue 作為路由源，具體語義可參考全球訊息路由和 RabbitMQ Shovel。
若全球訊息路由的目標類型選擇 Exchange，應提前確認目標 Exchange 已綁定可儲存訊息的 Queue，避免訊息路由到 Exchange 後無 Queue 承接而丟失。
消費者預設只消費主執行個體。切換時啟動或放量備執行個體消費者，防止主備同時消費同一業務流造成重複副作用。
業務必須以業務訊息 ID 做等冪，允許故障切換後出現重複投遞或補償投遞。
切換流程建議：
監控確認主執行個體不可用或效能異常已影響業務發送或消費，且未在預期視窗內恢複。
按業務預案暫停、限流或降級生產側寫入，避免故障視窗內的主備資料差異繼續擴大。
通過配置中心或應用接入地址配置切換到備執行個體；如使用客戶自管 DNS，應確認 DNS 緩衝和 TLS 校正不會阻礙切換。
啟動備執行個體消費者或提升備執行個體消費權重。
觀察發送成功率、消費速率、Queue 堆積和業務成功率。
主執行個體恢複後，基於業務發送與消費流水、堆積指標和業務訊息 ID 完成對賬、補償和去重，再按變更流程回切。
跨地區主備容災方案
適用範圍：核心業務需要防範地區級故障，或業務本身跨地區部署。
關鍵設計：
在兩個地區分別建立 RabbitMQ 執行個體，拓撲、帳號許可權和網路存取原則保持功能等價，訪問憑證分別管理。
使用全球訊息路由、應用雙寫或業務 Outbox 機制同步關鍵訊息。全球訊息路由的功能支援情況以執行個體類型說明和控制台為準。
使用全球訊息路由時，應採用與同地區方案相同的容災同步專用 Queue 設計，避免與業務消費者競爭消費源 Queue。
若全球訊息路由的目標類型選擇 Exchange，應提前確認目標 Exchange 已綁定可儲存訊息的 Queue。
使用全球訊息路由時，需要評估 EventBridge 和 CEN 費用、訊息同步延遲以及路由積壓；使用應用雙寫或 Outbox 時，需要單獨規劃用戶端網路、存取點、白名單、鏈路費用和故障切換方式。
目標端訊息大小限制必須不低於源端，否則超過目標端限制的訊息可能路由失敗。
全球訊息路由不支援傳遞路由，即 A 到 B 到 C 不會自動把 A 的訊息經 B 繼續傳到 C；如需 A 到 C，應直接配置 A 到 C 的路由。
跨地區容災不應預設假設完全透明切換。應明確 RTO、RPO、切換審批人、回切條件和資料補償機制。
雙活方案
適用範圍：業務已經具備強等冪、去重、衝突處理和最終一致效能力，且希望兩個地區或兩個執行個體同時承載流量。雙活屬於客戶應用架構設計，不代表產品自動提供跨執行個體雙活或全域一致效能力。
要求：
生產端使用全域唯一且重試期間保持穩定的業務訊息 ID。
消費端按業務主鍵做等冪和去重，不依賴 RabbitMQ 投遞次數作為唯一事實。
明確每條訊息的主寫入路徑和同步方向，避免雙向同步形成迴圈或重複放大。
明確順序語義邊界。跨執行個體雙活通常不提供全域嚴格順序保障。
明確衝突處理策略，包括重複支付、重複下單、庫存扣減等業務副作用。
具備持續演練和自動化對賬能力。
不建議把雙活作為預設方案。多數業務應優先選擇主備或分級降級，避免因複雜度導致穩定性下降。
演練和驗收標準
上線多執行個體容災方案前，建議至少完成以下演練：
演練項 | 驗證目標 |
主執行個體接入失敗 | 用戶端能按預期切到備執行個體，RTO 符合目標 |
主執行個體發送失敗 | 生產端能識別失敗並重試或補償，不產生不可控重複 |
多串連分散 | 應用執行個體能按配置建立多條長期 Connection，重啟或切換後串連池可恢複，生產和消費流量不會長期集中在單條 Connection 上 |
消費者重啟 | 應用能重建 Channel 並重建立立消費者訂閱 |
全球訊息路由延遲 | 能觀測源端專用 Queue 積壓、目標端流入量和同步延遲 |
備執行個體接管消費 | 備執行個體消費者啟動後能處理存量訊息，業務等冪有效 |
回切主執行個體 | 能完成業務對賬、補償、去重和灰階回切 |
容災方案的驗收指標包括以下維度：
RTO：從業務受到影響或滿足切換條件開始，到業務恢複的時間。
RPO：故障視窗內最多允許丟失或需要補償的訊息範圍。
重複率：切換和回放期間重複訊息比例及業務影響。
堆積恢復：切換後 Queue 堆積恢複到正常水位的時間。
用戶端恢複成功率：Connection 重連、Channel 重建和消費者重新訂閱的成功率。
串連分散度：應用重啟、擴容或故障切換後，生產和消費流量應持續分散使用多條長期 Connection，避免長期只使用單條 Connection。