RabbitMQ コンシューマープロパティ

確認応答モード。

バインディングに group プロパティがない場合、匿名の自動削除キューが宛先交換にバインドされます。このようなキューのデフォルトの命名戦略により、anonymous.<base64 representation of a UUID> という名前のキューが作成されます。このプロパティを設定して、プレフィックスをデフォルト以外のものに変更します。

DLQ を自動的に宣言し、それをバインダー DLX にバインドするかどうか。

キューを交換にバインドするためのルーティングキー（bindQueue が true の場合）。複数のキーにすることができます。bindingRoutingKeyDelimiter を参照してください。パーティション化された宛先の場合、-<instanceIndex> が各キーに追加されます。

これが null でない場合、"bindingRoutingKey" はこの値で区切られたキーのリストと見なされます。多くの場合、コンマが使用されます。

キューを宣言して宛先交換にバインドするかどうか。独自のインフラストラクチャをセットアップし、以前にキューを作成してバインドしたことがある場合は、false に設定します。

コンシューマータグを作成するために使用されます。#n が追加されます。ここで、n は、作成されたコンシューマーごとに増分します。例: ${spring.application.name}-${spring.cloud.stream.bindings.input.group}-${spring.cloud.stream.instance-index}。

使用するリスナーコンテナーの種類を選択します。詳細については、Spring AMQP ドキュメントのコンテナーの選択を参照してください。[rabbitmq-stream] も参照してください。

DLQ の名前

キューに割り当てる DLX。autoBindDlq が true の場合にのみ関連します。

キューに割り当てる DLX の型。autoBindDlq が true の場合にのみ関連します。

キューに割り当てるデッドレタールーティングキー。autoBindDlq が true の場合にのみ関連します。

宛先のデッドレター交換を宣言するかどうか。autoBindDlq が true の場合にのみ関連します。DLX が事前構成されている場合は、false に設定します。

宛先の交換を宣言するかどうか。

交換を Delayed Message Exchange として宣言するかどうか。ブローカーに遅延メッセージ交換プラグインが必要です。x-delayed-type 引数は exchangeType に設定されます。

dlq をデッドレター交換にバインドするときに適用される引数。headersdeadLetterExchangeType とともに使用して、一致するヘッダーを指定します。たとえば、…​dlqBindingArguments.x-match=any、…​dlqBindingArguments.someHeader=someValue。

DLQ が宣言されている場合、そのキューに割り当てる DLX。

DLQ が宣言されている場合、そのキューに割り当てるデッドレタールーティングキー。

未使用のデッドレターキューが削除されるまでの時間（ミリ秒単位）。

x-queue-mode=lazy 引数を使用してデッドレターキューを宣言します。“怠惰なキュー” (英語) を参照してください。ポリシーを使用すると、キューを削除せずに設定を変更できるため、この設定の代わりにポリシーを使用することを検討してください。

デッドレターキュー内のメッセージの最大数。

すべてのメッセージからのデッドレターキューの合計バイト数の最大数。

デッドレターキュー（0-255）内のメッセージの最大優先度。

dlqMaxLength または dlqMaxLengthBytes を超えたときに実行するアクション。現在 drop-head または reject-publish ですが、RabbitMQ のドキュメントを参照してください。

quorum.enabled=true の場合、配信制限を設定してから、メッセージがドロップまたはデッドレターになります。

true の場合、従来のキューの代わりにクォーラムデッドレターキューを作成します。

quorum.enabled=true の場合、初期クォーラムサイズを設定します。

true に設定すると、x-single-active-consumer キュープロパティが true に設定されます。

宣言されたときにデッドレターキューに適用されるデフォルトの存続時間（ミリ秒単位）。

サブスクリプションが永続的である必要があるかどうか。group も設定されている場合にのみ有効です。

declareExchange が true の場合、交換を自動削除する（つまり、最後のキューが削除された後に削除する）かどうか。

declareExchange が真の場合、交換が永続的であるかどうか（つまり、ブローカーの再起動後も存続するかどうか）。

交換型: パーティション化されていない宛先の場合は direct、fanout、headers または topic、パーティション化された宛先の場合は direct、ヘッダー、topic。

排他的なコンシューマーを作成するかどうか。これが true の場合、同時実行性は 1 である必要があります。厳密な順序付けが必要な場合によく使用されますが、障害後にホットスタンバイインスタンスが引き継ぐことができます。スタンバイインスタンスが消費を試みる頻度を制御する recoveryInterval を参照してください。RabbitMQ 3.8 以降を使用する場合は、代わりに singleActiveConsumer の使用を検討してください。

未使用のキューが削除されるまでの時間（ミリ秒単位）。

キューが欠落している場合に、キューからの消費を試行する間隔（ミリ秒単位）。

スタックトレースを DLQ メッセージヘッダーに追加するときに他のヘッダー用に予約するバイト数。すべてのヘッダーは、ブローカーで構成された frame_max サイズ内に収まる必要があります。スタックトレースは大きくなる可能性があります。サイズにこのプロパティを加えたものが frame_max を超える場合、スタックトレースは切り捨てられます。警告ログが書き込まれます。例外をキャッチし、スタックトレースが小さいものをスローすることにより、frame_max を増やすか、スタックトレースを減らすことを検討してください。

受信メッセージからマッピングされるヘッダーのパターン。

x-queue-mode=lazy 引数を使用してキューを宣言します。“怠惰なキュー” (英語) を参照してください。ポリシーを使用すると、キューを削除せずに設定を変更できるため、この設定の代わりにポリシーを使用することを検討してください。

コンシューマーの最大数。containerType が direct の場合はサポートされません。

キュー内のメッセージの最大数。

すべてのメッセージからのキュー内の合計バイト数の最大数。

キュー内のメッセージの最大優先度（0-255）。

キューが見つからない場合、その状態を致命的なものとして扱い、リスナーコンテナーを停止するかどうか。デフォルトは false であるため、コンテナーはキューからの消費を継続します。たとえば、クラスターを使用していて、非 HA キューをホストしているノードがダウンしている場合です。

maxLength または maxLengthBytes を超えたときに実行するアクション。現在 drop-head または reject-publish ですが、RabbitMQ のドキュメントを参照してください。

プリフェッチカウント。

destination およびキューの名前に追加されるプレフィックス。

キューを取引所にバインドするときに適用される引数。headersexchangeType とともに使用して、一致するヘッダーを指定します。たとえば、…​queueBindingArguments.x-match=any、…​queueBindingArguments.someHeader=someValue。

キューが欠落している場合に、キューからの消費を再試行する回数。missingQueuesFatal が true の場合にのみ関連します。それ以外の場合、コンテナーは無期限に再試行し続けます。containerType が direct の場合はサポートされません。

true の場合、group と等しい名前のキューから消費します。それ以外の場合、キュー名は destination.group です。これは、たとえば、Spring Cloud Stream を使用して既存の RabbitMQ キューから消費する場合に役立ちます。

quorum.enabled=true の場合、配信制限を設定してから、メッセージがドロップまたはデッドレターになります。

true の場合、従来のキューの代わりにクォーラムキューを作成します。

quorum.enabled=true の場合、初期クォーラムサイズを設定します。

接続回復の試行間隔（ミリ秒単位）。

再試行が無効になっている場合、または republishToDlq が false の場合に、配信の失敗を再キューイングする必要があるかどうか。

republishToDlq が true の場合、再発行されたメッセージの配信モードを指定します。

デフォルトでは、再試行が終了した後に失敗したメッセージは拒否されます。デッドレターキュー（DLQ）が構成されている場合、RabbitMQ は失敗したメッセージ（変更なし）を DLQ にルーティングします。true に設定されている場合、バインダーは、失敗したメッセージを、最終的な失敗の原因からの例外メッセージやスタックトレースなど、追加のヘッダーとともに DLQ に再発行します。frameMaxHeadroom プロパティも参照してください。

true に設定すると、x-single-active-consumer キュープロパティが true に設定されます。

トランザクションチャネルを使用するかどうか。

宣言されたときにキューに適用するためのデフォルトの存続時間（ミリ秒単位）。

ラック間の配信数。containerType が direct の場合はサポートされません。