RabbitMQ Binder 參考指南

本指南描述了 Spring Cloud Stream Binder 的 RabbitMQ 實作。它包含關於其設計、用法和組態選項的資訊，以及 Stream Cloud Stream 概念如何對應到 RabbitMQ 特定結構的資訊。

用法

若要使用 RabbitMQ binder，您可以將其新增至您的 Spring Cloud Stream 應用程式，方法是使用下列 Maven 坐標

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-stream-binder-rabbit</artifactId>
</dependency>

或者，您可以如下所示使用 Spring Cloud Stream RabbitMQ Starter

<dependency>
  <groupId>org.springframework.cloud</groupId>
  <artifactId>spring-cloud-starter-stream-rabbit</artifactId>
</dependency>

RabbitMQ Binder 總覽

以下簡化圖表顯示 RabbitMQ binder 的運作方式

預設情況下，RabbitMQ Binder 實作會將每個目的地對應到一個 TopicExchange。對於每個消費者群組，一個 Queue 會綁定到該 TopicExchange。每個消費者實例都有一個對應的 RabbitMQ Consumer 實例，用於其群組的 Queue。對於分割的生產者和消費者，佇列會加上分割索引作為後綴，並使用分割索引作為路由金鑰。對於匿名消費者（沒有 group 屬性的消費者），會使用自動刪除佇列（具有隨機唯一的名稱）。

透過使用可選的 autoBindDlq 選項，您可以設定 binder 來建立和組態死信佇列 (DLQ)（以及死信交換器 DLX，以及路由基礎架構）。預設情況下，死信佇列的名稱為目的地名稱，並附加 .dlq。如果啟用重試 (maxAttempts > 1)，則在重試耗盡後，失敗的訊息會傳遞到 DLQ。如果停用重試 (maxAttempts = 1)，您應該將 requeueRejected 設定為 false（預設值），以便將失敗的訊息路由到 DLQ，而不是重新排隊。此外，republishToDlq 會導致 binder 將失敗的訊息發布到 DLQ（而不是拒絕它）。此功能可讓額外資訊（例如 x-exception-stacktrace 標頭中的堆疊追蹤）新增至訊息標頭中。請參閱 frameMaxHeadroom 屬性，以取得關於截斷堆疊追蹤的資訊。此選項不需要啟用重試。您可以在僅嘗試一次後重新發布失敗的訊息。從 1.2 版開始，您可以設定重新發布訊息的傳遞模式。請參閱 republishDeliveryMode 屬性。

如果 stream listener 拋出 ImmediateAcknowledgeAmqpException，則會繞過 DLQ，且訊息會直接丟棄。從 2.1 版開始，無論 republishToDlq 的設定為何，都是如此；先前僅在 republishToDlq 為 false 時才是這種情況。

將 requeueRejected 設定為 true（且 republishToDlq=false）會導致訊息重新排隊並持續重新傳遞，除非失敗的原因是暫時性的，否則這可能不是您想要的。一般而言，您應該透過將 maxAttempts 設定為大於 1 或將 republishToDlq 設定為 true，在 binder 內啟用重試。

從 3.1.2 版開始，如果消費者標記為 transacted，則發布到 DLQ 將參與交易。這允許在發布因某些原因失敗時（例如，如果使用者未被授權發布到死信交換器），交易可以回滾。此外，如果連線工廠已針對發布者確認或退回進行組態，則發布到 DLQ 將等待確認並檢查退回的訊息。如果收到負面確認或退回的訊息，binder 將拋出 AmqpRejectAndDontRequeueException，允許 broker 處理發布到 DLQ，如同 republishToDlq 屬性為 false。

請參閱 RabbitMQ Binder 屬性，以取得關於這些屬性的更多資訊。

框架未提供任何標準機制來消費死信訊息（或將它們重新路由回主要佇列）。死信佇列處理中描述了一些選項。

當 Spring Cloud Stream 應用程式中使用多個 RabbitMQ binder 時，務必停用 'RabbitAutoConfiguration'，以避免來自 RabbitAutoConfiguration 的相同組態套用至兩個 binder。您可以使用 @SpringBootApplication 註解排除該類別。

從 2.0 版開始，RabbitMessageChannelBinder 將 RabbitTemplate.userPublisherConnection 屬性設定為 true，以便非交易式生產者避免在消費者上發生死鎖，如果快取連線因 broker 上的 記憶體警報 而被封鎖，則可能會發生死鎖。

目前，僅訊息驅動的消費者支援 multiplex 消費者（單一消費者監聽多個佇列）；輪詢消費者只能從單一佇列檢索訊息。

組態選項

本節包含特定於 RabbitMQ Binder 和綁定通道的設定。

關於一般綁定組態選項和屬性，請參閱 Spring Cloud Stream 核心文件。

章節摘要