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

# RabbitMQ 4.2
<a name="rabbitmq-42"></a>

 Amazon MQ 支援 RabbitMQ 4.2 RabbitMQ 作為 4 系列的第一個版本。 RabbitMQ 4.2 引入 AMQP 1.0 作為核心通訊協定，Khepri 作為預設中繼資料存放區，規定人數佇列訊息優先順序，以及新的身分驗證外掛程式，包括 mTLS 和 HTTP 身分驗證。如需此版本的詳細資訊，請參閱 GitHub 網站上的 [RabbitMQ4.0.0 版本備註](https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.0.0)。

## Amazon MQ RabbitMQ 4.2 版中的新功能和增強功能
<a name="rabbitmq-42-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 更少的資源時提供更高的輸送量。
+ **配額佇列支援訊息優先順序：**配額佇列訊息優先順序一律處於作用中狀態，不需要政策。當規定人數佇列收到優先順序設定的訊息時，就會啟用優先順序。配額佇列僅支援兩個內部優先順序層級：高和正常。

   RabbitMQ 會將沒有優先順序的訊息，並將優先順序為 0–4 的訊息映射至正常。優先順序高於 4 的訊息會映射至高。高優先順序訊息以 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)進行連線。
+ **可設定的儲存大小：**部署在 CLUSTER\_MULTI\_AZ 模式中的 RabbitMQ 4.x 代理程式支援可設定的 EBS 儲存大小。如需詳細資訊，請參閱 [mq.m7g 執行個體類型。](rmq-broker-instance-types.md#instance-types-m7g-cluster)

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

## 在 RabbitMQ Amazon MQ 上中斷 4.2 中的變更
<a name="rabbitmq-42-breaking-changes"></a>

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