本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

# RabbitMQ 4
<a name="rabbitmq-4"></a>

Amazon MQ RabbitMQ 僅在所有支援的執行個體大小的 mq.m7g 執行個體類型上，支援 RabbitMQ 4 發行系列中的 RabbitMQ 4.2。

Amazon MQ 支援從 RabbitMQ 3.13 就地升級至 RabbitMQ 4.2。如需詳細資訊，請參閱[從 RabbitMQ 3 升級到 4](upgrading-rabbitmq-v3-to-v4.md)。

**重要**  
 Amazon MQ for RabbitMQ 4.2 代理程式的預設佇列類型為「規定人數」。如果在建立佇列期間未指定佇列類型引數，則會建立規定人數佇列。  
 我們強烈建議在 RabbitMQ 4 上使用規定人數佇列來滿足耐久性需求，因為傳統佇列在所有情況下都無法保證耐用。

## 下列變更已在 Amazon MQ 上的 RabbitMQ 4 中推出 Amazon MQ
<a name="rabbitmq-4-new-features"></a>
+ **AMQP 1.0 作為核心通訊協定：**如需詳細資訊，請參閱[通訊協定](rabbitmq-supported-protocols.md)。
+ **Local Shovels：**Shovels 現在除了 AMQP 0-9-1 和 AMQP 1.0 之外，還支援稱為 "local" 的新通訊協定。本機 shovel 在內部以 AMQP 1.0 為基礎，但不是使用單獨的 TCP 連線，而是在叢集節點和內部 APIs 之間使用叢集內連線來發佈和取用訊息。這只能用於在相同叢集內消費和發佈，並且可以在使用比 AMQP 0-9-1 和 AMQP 1.0 更少的資源時提供更高的輸送量。
+ **配額佇列支援訊息優先順序：**配額佇列訊息優先順序一律處於作用中狀態，不需要政策即可運作。一旦規定人數佇列收到具有優先順序設定的訊息，就會啟用優先順序。內部配額佇列僅支援兩個優先順序 - 高和正常。未設定優先順序的訊息將對應至正常，如同優先順序 0 - 4。優先順序高於 4 的訊息將映射至高。高優先順序訊息將以 2：1 的比例優先於一般優先順序訊息，也就是說，每 2 則高優先順序訊息，佇列將提供 1 則一般優先順序訊息 （如果有的話）。因此，規定人數佇列會實作一種非嚴格、「公平共享」的優先順序處理。這可確保在正常優先順序訊息上始終進行進度，但高優先順序是以 2：1 的比例有利。
+ **Khepri：**Khepri 用作 RabbitMQ 4 代理程式的預設中繼資料存放區
+ **相互 TLS (mTLS)：**Amazon MQ 支援 RabbitMQ 代理程式的相互 TLS (mTLS)，允許用戶端使用憑證進行身分驗證。如需詳細資訊，請參閱 [mTLS 組態](configure-mtls.md)。
+ **SSL 憑證驗證外掛程式：**SSL 身分驗證外掛程式使用來自 mTLS 連線的用戶端憑證來驗證使用者，允許使用 X.509 用戶端憑證進行身分驗證，而非使用者名稱和密碼憑證。如需詳細資訊，請參閱 [SSL 憑證身分驗證](ssl-for-amq-for-rabbitmq.md)。
+ **HTTP 身分驗證外掛程式：**HTTP 身分驗證後端外掛程式允許將身分驗證和授權委派給外部 HTTP 服務。如需詳細資訊，請參閱 [HTTP 身分驗證和授權](http-for-amq-for-rabbitmq.md)。
+ **JMS 支援：**代理程式現在支援已啟用 JMS 主題交換外掛程式的 JMS 工作負載，允許 JMS 應用程式使用 [RabbitMQ JMS 用戶端](https://github.com/rabbitmq/rabbitmq-jms-client)進行連線。

## 下列功能已從 Amazon MQ 上的 RabbitMQ 4 取代 Amazon MQ
<a name="rabbitmq-4-deprecations"></a>
+ **鏡射傳統佇列：**繼續支援傳統佇列，而不會對用戶端程式庫和應用程式進行任何中斷變更，但它們現在是非複寫佇列類型。用戶端將能夠連線到任何節點，以從任何未複寫的傳統佇列發佈和取用。為了複寫和資料安全，建議使用配額佇列。
+ **移除全域 QoS：**建議客戶設定每個消費者 QoS （非全域），而不是全域 QoS，其中整個頻道使用單一共用預先擷取。
+ **支援暫時性、非獨佔佇列：**暫時性佇列是生命週期連結至其宣告節點執行時間的佇列。在單一執行個體代理程式中，它們會在節點重新啟動時移除。在叢集部署中，當其託管的節點重新啟動時，它們會被移除。我們建議在閒置一段時間後，使用佇列 TTL 自動刪除未使用的閒置佇列。系統會繼續支援排入佇列，並在移除佇列的所有連線後刪除。

## 在 Amazon MQ 上升級至 RabbitMQ 4.2 時，下列重大變更可能會影響您的應用程式
<a name="rabbitmq-4-breaking-changes"></a>
+  **預設佇列類型：**RabbitMQ 4 代理程式上的預設佇列類型設定為規定人數。如果在建立佇列期間未指定佇列類型引數，則會建立規定人數佇列。
+ **規定人數佇列的預設重新傳遞限制設定為 20：**重新傳遞 20 次或更多次的訊息將會以無效字母表示或捨棄 （已移除）。如果每則訊息 20 個傳遞是佇列的常見案例，則必須為此類佇列設定無效字母目標或更高限制，以避免資料遺失。建議的做法是透過政策。
+ **amqplib：****早於 0.10.7 的節點 JS 用戶端 amqplib 版本**，或任何使用 **frame\_max < 8192 的 ** AMQP 用戶端程式庫將無法連線至 RabbitMQ
+ [預設資源限制：](rabbitmq-resource-limits-configuration.md)Amazon MQ for RabbitMQ 已針對連線、頻道、每個頻道的取用者、佇列、虛擬主機、鮑魚、交換和最大訊息大小引入預設資源使用限制。這些可做為保護代理程式可用性的護欄，並且可以使用組態進行自訂，以符合您的特定需求。

## Amazon MQ 上的 RabbitMQ 4 不支援下列功能
<a name="rabbitmq-4-not-supported"></a>
+ **本機隨機交換：**Amazon MQ 不支援本機隨機交換，因為 Amazon MQ 節點位於網路負載平衡器後方。
+ **訊息攔截器：**Amazon [ MQ 不支援 RabbitMQ 訊息攔截器](https://www.rabbitmq.com/docs/message-interceptors)。 Amazon MQ
+  **每個佇列指標：**Amazon MQ 不會透過 AWS CloudWatch 為 RabbitMQ 4 代理程式提供 RabbitMQ 佇列指標。Amazon MQ 仍會透過 AWS CloudWatch 提供代理程式層級指標。您可以使用 RabbitMQ 管理 API 查詢佇列指標。我們建議以一分鐘或更長的間隔頻率查詢特定佇列的指標。