RabbitMQ Binder 參考指南

本指南描述了 Spring Cloud Stream Binder 的 RabbitMQ 實現。它包含有關其設計、用法和配置選項的資訊，以及 Stream Cloud Stream 概念如何對映到 RabbitMQ 特定構造的資訊。

用法

要使用 RabbitMQ binder，您可以透過使用以下 Maven 座標將其新增到 Spring Cloud Stream 應用程式中

<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。每個消費者例項為其組的 Queue 都有一個相應的 RabbitMQ Consumer 例項。對於分割槽生產者和消費者，佇列以分割槽索引為字尾，並使用分割槽索引作為路由鍵。對於匿名消費者（沒有 group 屬性的消費者），使用一個 auto-delete 佇列（帶有一個隨機的唯一名稱）。

透過使用可選的 autoBindDlq 選項，您可以配置 binder 來建立和配置死信佇列 (DLQ)（以及一個死信交換機 DLX，以及路由基礎設施）。預設情況下，死信佇列的名稱是目標名稱，並附加 .dlq。如果啟用了重試（maxAttempts > 1），失敗的訊息在重試耗盡後會被髮送到 DLQ。如果停用了重試（maxAttempts = 1），您應該將 requeueRejected 設定為 false（預設值），以便失敗的訊息被路由到 DLQ，而不是被重新排隊。此外，republishToDlq 會使 binder 將失敗的訊息釋出到 DLQ（而不是拒絕它）。此功能允許在訊息頭中新增額外的資訊（例如 x-exception-stacktrace 頭中的堆疊跟蹤）。有關截斷堆疊跟蹤的資訊，請參見 frameMaxHeadroom 屬性。此選項無需啟用重試。您可以在僅嘗試一次後重新發布失敗的訊息。從版本 1.2 開始，您可以配置重新發布訊息的投遞模式。請參見 republishDeliveryMode 屬性。

如果 stream 監聽器丟擲 ImmediateAcknowledgeAmqpException，則繞過 DLQ 並直接丟棄訊息。從版本 2.1 開始，無論 republishToDlq 設定如何，這都適用；以前只有當 republishToDlq 為 false 時才如此。

將 requeueRejected 設定為 true（同時 republishToDlq=false）會導致訊息被重新排隊並持續重新投遞，這可能不是您想要的，除非失敗的原因是瞬態的。通常，您應該透過將 maxAttempts 設定為大於一或將 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` 消費者（一個監聽多個佇列的消費者）僅支援訊息驅動的消費者； polled 消費者只能從單個佇列檢索訊息。

配置選項

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

有關常規繫結配置選項和屬性，請參見 Spring Cloud Stream 核心文件。

章節摘要