最新の安定バージョンについては、spring-cloud-stream 4.2.1 を使用してください。 |
RabbitMQ バインダーリファレンスガイド
このガイドでは、Spring Cloud Stream バインダーの RabbitMQ 実装について説明します。設計、使用箇所、構成オプションに関する情報、StreamCloudStream の概念が RabbitMQ 固有の構成にどのようにマッピングされるかに関する情報が含まれています。
使用方法
RabbitMQ バインダーを使用するには、次の Maven 座標を使用して、Spring Cloud Stream アプリケーションに追加できます。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-stream-binder-rabbit</artifactId>
</dependency>または、次のように Spring Cloud Stream RabbitMQ スターターを使用することもできます。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-stream-rabbit</artifactId>
</dependency>RabbitMQ バインダーの概要
次の簡略図は、RabbitMQ バインダーがどのように動作するかを示しています。
デフォルトでは、RabbitMQ バインダーの実装は各宛先を TopicExchange にマップします。コンシューマーグループごとに、Queue はその TopicExchange にバインドされます。各コンシューマーインスタンスには、そのグループの Queue に対応する RabbitMQ Consumer インスタンスがあります。パーティション化されたプロデューサーとコンシューマーの場合、キューにはパーティションインデックスが接尾辞として付けられ、ルーティングキーとしてパーティションインデックスが使用されます。匿名のコンシューマー（group プロパティを持たないコンシューマー）の場合、自動削除キュー（ランダム化された一意の名前）が使用されます。
オプションの autoBindDlq オプションを使用することにより、デッドレターキュー（DLQ）（およびデッドレター交換 DLX、およびルーティングインフラストラクチャ）を作成および構成するようにバインダーを構成できます。デフォルトでは、デッドレターキューには宛先の名前があり、.dlq が追加されています。再試行が有効になっている場合（maxAttempts > 1）、再試行が終了した後、失敗したメッセージが DLQ に配信されます。再試行が無効になっている場合（maxAttempts = 1）、requeueRejected を false （デフォルト）に設定して、失敗したメッセージが再キューイングされるのではなく、DLQ にルーティングされるようにする必要があります。さらに、republishToDlq により、バインダーは失敗したメッセージを（拒否するのではなく）DLQ に発行します。この機能により、追加情報（x-exception-stacktrace ヘッダーのスタックトレースなど）をヘッダーのメッセージに追加できます。切り捨てられたスタックトレースについては、frameMaxHeadroom プロパティを参照してください。このオプションでは、再試行を有効にする必要はありません。失敗したメッセージは、1 回試行するだけで再公開できます。バージョン 1.2 以降、再発行されたメッセージの配信モードを構成できます。republishDeliveryMode プロパティを参照してください。
ストリームリスナーが ImmediateAcknowledgeAmqpException をスローした場合、DLQ はバイパスされ、メッセージは単に破棄されます。バージョン 2.1 以降、これは republishToDlq の設定に関係なく当てはまります。以前は、republishToDlq が false の場合のみでした。
requeueRejected を true に設定すると（republishToDlq=false を使用）、メッセージは継続的に再キューイングおよび再配信されます。これは、失敗の理由が一時的なものでない限り、意図したものではない可能性があります。一般に、maxAttempts を 1 より大きい値に設定するか、republishToDlq を true に設定することにより、バインダー内で再試行を有効にする必要があります。 |
バージョン 3.1.2 以降、コンシューマーが transacted としてマークされている場合、DLQ への公開はトランザクションに参加します。これにより、何らかの理由で公開が失敗した場合（たとえば、ユーザーがデッドレターエクスチェンジへの公開を認可されていない場合）にトランザクションをロールバックできます。さらに、接続ファクトリが発行者の確認または返送用に構成されている場合、DLQ への発行は確認を待機し、返されたメッセージを確認します。否定応答または返されたメッセージが受信された場合、バインダーは AmqpRejectAndDontRequeueException をスローし、ブローカーが republishToDlq プロパティが false であるかのように DLQ への公開を処理できるようにします。
これらのプロパティの詳細については、RabbitMQ バインダーのプロパティを参照してください。
フレームワークは、デッドレターメッセージを消費する（またはそれらをプライマリキューに再ルーティングする）ための標準的なメカニズムを提供していません。いくつかのオプションはデッドレターキュー処理で説明されています。
Spring Cloud Stream アプリケーションで複数の RabbitMQ バインダーが使用されている場合、2 つのバインダーに RabbitAutoConfiguration の同じ構成が適用されないように、"RabbitAutoConfiguration" を無効にすることが重要です。@SpringBootApplication アノテーションを使用して、クラスを除外できます。 |
バージョン 2.0 以降、RabbitMessageChannelBinder は RabbitTemplate.userPublisherConnection プロパティを true に設定して、非トランザクションのプロデューサーがコンシューマーのデッドロックを回避するようにします。これは、ブローカーのメモリアラーム (英語) のためにキャッシュされた接続がブロックされた場合に発生する可能性があります。
現在、multiplex コンシューマー（複数のキューをリッスンしている単一のコンシューマー）は、メッセージ駆動型のコンシューマーに対してのみサポートされています。ポーリングされたコンシューマーは、単一のキューからのみメッセージを取得できます。 |
構成オプション
このセクションには、RabbitMQ バインダーとバインドされたチャネルに固有の設定が含まれています。
一般的なバインディング構成オプションとプロパティについては、Spring Cloud Stream コアドキュメント (英語) を参照してください。
