記事ディレクトリ

1 はじめに
2. クラシックキュー
3. クォーラムキュー
4. ストリームキュー
5. レイジーキュー
6. デッドレターキュー
6.1 概要
- 6.2 声明
- - 6.2.1 ポリシーステートメント
  - 6.2.2 クライアントの声明
要約する

1 はじめに

RabbitMQ は、分散システムでメッセージを配信および保存するための柔軟なメッセージングメカニズムを提供する、強力なオープンソースのメッセージキューイングミドルウェアです。RabbitMQ は、効率的で信頼性の高いミドルウェアとして、さまざまなアプリケーションシナリオや要件に適したさまざまなタイプのメッセージキューを提供します。この投稿では、クラシックキュー、クォーラムキュー、ストリームキュー、レイジーキュー、デッドレターキュー
など、RabbitMQ のさまざまなキュータイプについて詳しく説明します。各キューには独自の特性と利点、および対応する使用シナリオがあります。これは、前の記事でのJava クライアントの使用法をさらに詳しく調べて補足するものでもあります。開始する前に、RabbitMQ サービスをインストールして管理ページを開いている必要があります。また、使用するクライアントも必要です。

サービスのインストールと管理の背景、および Java クライアントの使用方法については、以前の記事で詳しく説明および紹介されています。

2. クラシックキュー

2.1 概要

クラシックキューは、 RabbitMQ によって提供される元のキュータイプです。これは、多くの使用例に適した汎用キュータイプである、非レプリケート FIFO キューの実装です。データストレージはクラシックキューを複製しないため、データセキュリティは最優先事項ではありません。データのセキュリティが重要な場合は、クォーラムキューとフローキューを使用することをお勧めします。

クラシックキューはデフォルトのキュータイプであり、クラシックキューメッセージストアには 2 つのバージョン (実装) とインデックスがあります。

バージョン 1
Classic のデフォルトおよびオリジナルのキュー実装。このリリースのインデックス作成には、ログファイルとセグメントファイルが使用されます。セグメントファイルからメッセージを読み取る場合、セグメントファイル全体がメモリに読み込まれるため、メモリの問題が発生する可能性がありますが、実行される I/O 量は減少します。このバージョンではインデックスに小さなメッセージが埋め込まれており、メモリの問題がさらに悪化しています。
バージョン 2 は、
パフォーマンスが向上した最新のストレージデバイスを利用する、推奨バージョンです。このバージョンのインデックス作成はセグメント化されたファイルのみを使用し、必要な場合にのみディスクからロードされます。現在の消費率に基づいて計算されます。このバージョンでは、インデックスにメッセージが埋め込まれませんが、代わりにキューごとのメッセージストアが使用されます。バージョン 2 は RabbitMQ 3.10.0 に追加され、RabbitMQ 3.12.0 で大幅に改善されました。現在、バージョン 1 とバージョン 2 を切り替えることができます。将来的には、バージョン 1 は削除され、アップグレード後のノード起動時にバージョン 2 への移行が自動的に実行される予定です。

デフォルトのバージョンは、Rabbitmq.confで設定することにより、構成によって設定できますclassic_queue.default_version。デフォルトのバージョンを変更すると、新しく宣言されたキューにのみ影響します。

注: エディションは、ディスク上でのデータの保存方法と読み取り方法にのみ影響します。すべての機能は両方のエディションで利用できます。

2.2 特徴

クラシックキューは、キューの排他性、キューとメッセージの TTL (存続時間)、キューの長さの制限、メッセージの優先順位、コンシューマの優先順位をサポートし、使用ポリシーによって制御される設定に従います。クラシックキューは有害なメッセージの処理をサポートしていないことに注意してください。公式 Web サイトの説明は次のとおりです。

クラシックキューは、クォーラムキューとは異なり、有害なメッセージの処理をサポートしません。クラシックキューは、クォーラムキューによってサポートされる少なくとも 1 回のデッドレターリングもサポートしません。

ここに画像の説明を挿入

2.3 声明

パラメーターを指定しないキュー宣言は、実際にはクラシックキューを宣言します。

2.3.1 管理ページの宣言

管理ページの宣言は以下の通りです
ここに画像の説明を挿入
通常、仮想マシン作成時はデフォルトで内部で作成されるキュータイプが選択されます他所が知らない場合はデフォルトでこのパラメータに従ってキューが作成されます

2.3.2 クライアントの声明

クライアント側での宣言は比較的簡単で、クライアントの jar パッケージによって渡されるデフォルトのメソッドを使用するだけです。

//队列名称
String queueName = "classis-queue";
//声明队列
channel.queueDeclare(queueName, true, false, false, null);

2.4 オプションの構成パラメータ

クラシックキューを作成するためのインターフェイスは、さまざまなパラメーターの追加をサポートしています。

自動有効期限: 自動有効期限。キューの自動有効期限をミリ秒単位で設定します。アクションの対象はキューで、指定した時間内にキューが使用されない（プロデューサーまたはコンシューマー接続がない）場合、キューは自動的に削除されます。
例：「q1」という名前のキューを設定すると、10秒以内に使用されないと自動的に削除されます。

Map<String, Object> arguments = new HashMap<>();
// 10000 毫秒 = 10 秒
arguments.put("x-expires", 10000); 
channel.queueDeclare("q1", false, false, false, arguments);

メッセージ TTL : メッセージの有効期間。キュー内のメッセージの有効期間をミリ秒単位で設定します。アクションの対象はメッセージなので、メッセージ送信時だけでなくキュー宣言にも設定でき、メッセージがTTL以上キュー内に残ると期限切れとなり削除されます。
例: メッセージの TTL を 5 秒に設定します。

//在发送消息时设置
String message = "Hello, RabbitMQ!";
String queueName = "q2";
channel.queueDeclare(queueName, true, false, false, null);
AMQP.BasicProperties properties = new AMQP.BasicProperties.Builder()
                .expiration("5000")
                .build();
channel.basicPublish("", queueName, properties, message.getBytes());
//在声明队列时设置
String message = "Hello, RabbitMQ!";
String queueName = "q2";
channel.queueDeclare(queueName, true, false, false, null);
channel.basicPublish("", queueName, properties, message.getBytes());

注:

2 つの設定方法はいずれか 1 つだけ設定でき、混合することはできません。
メッセージを通じて時間を設定した場合、後続の時間を変更できます。たとえば、最初の時間を 5 秒、2 番目の時間を 10 秒にすることができます。
宣言キューモードを設定した後は変更できません。キューがすでに存在する場合は、一貫性がなければなりません

オーバーフロー動作: オーバーフロー動作。キュー内のメッセージが最大長または最大容量に達したときのオーバーフロー動作を設定します。オプションのオーバーフローアクションは、drop-head、reject-publishおよびreplace-publish-dlxです。

drop-head : ヘッドを削除します。新しいメッセージによってキューの先頭 (最も古いメッセージ) が破棄されます。ject
-publish : 新しいメッセージの受信を拒否します
。reject-publish-dlx : キューがいっぱいになると、新しいメッセージが破棄されます。 Discarded 拒否され、指定された Dead Letter Exchange に転送される
設定例: 「my_queue」という名前のキューを設定し、メッセージ数が 1000 に達した場合、リジェクトパブリッシュオーバーフロー動作を使用して新しいメッセージを拒否します。

例: 長さを 5 より大きく設定し、ヘッダーを削除するようにオーバーフローポリシーが設定されている

String queueName = "q3";
Map<String, Object> arguments = new HashMap<>();
arguments.put("x-max-length", 5);
arguments.put("x-overflow", "drop-head");
channel.queueDeclare(queueName, true, false, false, arguments);
for (int i = 0; i <= 10; i++) {
    
    
	String message = "Hello, RabbitMQ-" + i;
	channel.basicPublish("", queueName, null, message.getBytes());
}

実行後、キューにはまだ 5 つのメッセージしか残っていないことがわかります。
ここに画像の説明を挿入
メッセージを取得すると、6 番目のメッセージから開始されることがわかります。

単一のアクティブなコンシューマ: 単一のアクティブなコンシューマ。設定されたキュー内にアクティブなコンシューマが 1 つだけあり、コンシューマが切断されると、他のコンシューマがメッセージの処理を引き継ぐことができます。
例: アクティブなコンシューマを 1 つだけ許可する「q4」という名前のキューを設定します。

Map<String, Object> arguments = new HashMap<String, Object>();
arguments.put("x-single-active-consumer", true);
channel.queueDeclare("q4", false, false, false, arguments);

デッドレター交換: デッドレター交換。期限切れまたは拒否されたメッセージを受信する交換を設定します。メッセージはデッドレターになった後に指定された交換に転送されます。
例: 「q5」という名前のキューを設定します。メッセージが期限切れになるか拒否された場合、メッセージは「q5_dlx」という名前の交換に転送されます。

Map<String, Object> arguments = new HashMap<>();
arguments.put("x-dead-letter-exchange", "q5_dlx");
arguments.put("x-dead-letter-routing-key", "");
channel.queueDeclare("q5", false, false, false, arguments);

デッドレターメッセージになるには、次のいずれかを満たす必要があります。

メッセージは拒否され(basic.reject または Basic.nack)、requeue パラメーターは false に設定されます。これは、メッセージが再キューに入れられず、デッドレターとしてマークされ、デッドレター交換に送信されることを意味します。
メッセージはキュー内で期限切れになります。つまり、メッセージの生存時間が設定された x-message-ttl パラメータを超えます。
キューの長さの制限(x-max-length パラメーター) によりメッセージは破棄され、x-overflow パラメーターは拒否発行-dlx に設定されます。これは、メッセージがデッドレターとしてマークされ、デッドレター交換に送信されることを意味します。
メッセージが queue の最大長に達すると、つまり、x-max-length パラメータで設定された値に達し、x-overflow パラメータがreject-publish-dlx に設定されるため、メッセージはデッドレターを受け取り、デッドレター交換局に送信されます。
キューの有効期限が切れます。つまり、キューの生存時間が設定された x-expires パラメータを超えます。

デッドレタールーティングキー：デッドレタールーティングキー、デッドレターメッセージのルーティングキー（ルーティングキー）を設定します。メッセージがデッドレターになると、元のメッセージのルーティングキーを使用して、指定されたデッドレター交換局にメッセージが送信されます。
最大長: メッセージの最大数。キューの最大長を設定します。キュー内のメッセージ数がこの値に達すると、新しいメッセージはキューに入ることができなくなります。
最大長バイト: 最大キュー容量。キューの最大容量をバイト単位で設定します。キュー内のメッセージの合計バイト数がこの値に達すると、新しいメッセージはキューに入ることができなくなります。
例: 最大容量 10MB の「q6」という名前のキューを設定します。

Map<String, Object> arguments = new HashMap<>();
// 10MB
arguments.put("x-max-length-bytes", 10 * 1024 * 1024); 
channel.queueDeclare("q6", false, false, false, arguments);

リーダーロケーター: リーダーロケーターは、RabbitMQ によって内部的に使用されるパラメーターであり、メッセージキューのプライマリノードを決定するために使用されます。通常、このパラメータを手動で設定する必要はありません。
最大優先度: 最大優先度。このパラメータは、キュー内のメッセージの最大優先度を定義するために使用されます。優先度は負ではない整数で、値が大きいほど優先度が高くなります。x-max-priorityパラメーターが queue に設定されている場合、プロデューサーによって送信されるメッセージには、メッセージの優先度を指定する優先度属性を含めることができ、RabbitMQ はメッセージの優先度に従ってメッセージを並べ替えて配布します。優先度の高いタスクがより速く処理されるように、優先度の高いメッセージが最初に消費されます。このパラメータは1 ～ 255の正の整数である必要があり、公式の推奨事項は1 ～ 5 の間に設定することです。
例:キューq5の最大優先度を5 に設定する

Map<String, Object> arguments = new HashMap<>();
arguments.put("x-max-priority", 5);
channel.queueDeclare("q5", true, false, false, arguments);

Version : version。このパラメータはキューのバージョンを定義するために使用されます。キューバージョンの概念は RabbitMQ 3.8.0 で導入され、さまざまなタイプのキューをサポートするために使用されます。詳細については、上記 2.1 の概要セクションを参照してください。

3. クォーラムキュー

3.1 概要

クォーラムキューは、RabbitMQ によって実装され、Raft コンセンサスアルゴリズムに基づいた永続的な FIFO キューです。クォーラムキューとストリームは、元の複製されたミラーリングされたクラシックキューを置き換えるようになりました。ミラーリングされたクラシックキューは非推奨となり、将来削除される予定です。

3.2 特徴

また、クォーラムキューには、従来のミラーリングされたキューと比較して、動作に重要な違いがあり、たとえばコンシューマが同じメッセージを繰り返し再キューする場合など、ワークロード固有の制限も含まれます。
有害なメッセージの処理などの一部の機能は、クォーラムキューに固有です。公式は、クォーラムキューとクラシックキューの違いを比較した表を提供しています。
ここに画像の説明を挿入

3.3 声明

3.3.1 管理ページの宣言

管理ページは比較的シンプルで直接入力するだけです
ここに画像の説明を挿入

3.3.2 クライアントの声明

現時点では、クライアントのステートメントには特定の機能はなく、次のようなパラメータを設定することによってのみ設定できます。

String queueName = "q7";
Map<String, Object> arguments = new HashMap<>();
arguments.put("x-queue-type", "quorum");
channel.queueDeclare(queueName, true, false, false, arguments);

宣言後、管理の背景に移動して作成ステータスを表示します
ここに画像の説明を挿入

3.4 オプションの構成パラメータ

アービトレーションキューの設定可能なパラメータのほとんどは、クラシスキューのパラメータと同じです。前のセクション2.4を参照してください。クラシックキューと異なるアービトレーションキューのパラメータは次のとおりです。

配信制限: 配信試行の失敗が許容される回数。この回数を超えてメッセージの配信に失敗すると、キューの構成に応じてメッセージは破棄されるか、デッドレターキューに移動されます。
例: メッセージの最大配信時間を 5 に設定する

Map<String, Object> arguments = new HashMap<>();
arguments.put("x-delivery-limit", 5);
channel.queueDeclare("q-1", true, false, false, arguments);

初期クラスターサイズ: キューの初期クラスターサイズを設定します。このパラメーターは、RabbitMQ クラスターの初期ノード数を定義するために使用されます。RabbitMQ クラスターを作成するときは、初期クラスター構成を形成するノードの初期数を少なくとも指定する必要があります。後続のノードの参加と自動検出はクラスターによって自動的に管理されます。正しい初期クラスターサイズを設定することで、クラスターが適切に起動し、新しく参加したノードが既存のクラスターに正しく参加することを保証できます。
例: 初期クラスターサイズを 3 ノードに設定する

Map<String, Object> arguments = new HashMap<>();
arguments.put("x-quorum-initial-group-size", 3); 
channel.queueDeclare("quorum_queue", true, false, false, arguments);

デッドレター戦略: 有効な値はat-most-onceまたはat-least-onceです。デフォルト値は at-most-once (メッセージは最大 1 回配信されます) です。この設定はクォーラムキューにのみ適用されます。at-least-once (メッセージは少なくとも 1 回配信される) に設定されている場合、オーバーフロー動作はリジェクトパブリッシュに設定する必要があります。それ以外の場合、デッドレターポリシーは最大 1 回に戻ります。
例: デッドレターキューの処理例

Map<String, Object> arguments = new HashMap<>();
// 设置死信策略为 at-least-once
arguments.put("x-dead-letter-strategy", "at-least-once"); 
// 设置溢出行为为 reject-publish
arguments.put("x-overflow", "reject-publish"); 
// 设置死信队列的交换机为 dlx_e
arguments.put("x-dead-letter-exchange", "dlx_e"); 
channel.queueDeclare("q-1", true, false, false, arguments);

リーダーロケーター: クラスターノード上でキューを宣言するときに、キューリーダーが配置される場所を決定するためのルールを設定します。有効な値はクライアントローカル (デフォルト) とバランスです。

client-local : キューリーダーはクライアントに最も近いノードに配置されます。これはデフォルトであり、キュー操作が最も近いノードにルーティングされ、ネットワーク遅延が短縮されるため、ほとんどの場合最高のパフォーマンスが得られます。
Balanced : キューリーダーは、クラスターのさまざまなノードにバランスのとれた方法で配置されます。これにより、クラスター内のキューのリーダーの役割を均等に分散でき、負荷のバランスがより良くなります。一部のシナリオでは、このアプローチによりパフォーマンスが向上する場合があります。

Map<String, Object> arguments = new HashMap<>();
// 设置主节点定位器为 client-local
arguments.put("x-queue-leader-locator", "client-local"); 
channel.queueDeclare("quorum_queue", true, false, false, arguments);

4. ストリームキュー

4.1 概要

ストリームは、非破壊的なコンシューマセマンティクスを備えた追加専用ログをモデル化する、新しい永続的で複製されたデータ構造です。これらは、RabbitMQ クライアントライブラリ (キューであるかのように) または専用のバイナリプロトコルプラグインおよび関連クライアントを通じて使用できます。後者のオプションは、すべてのストリーム固有の機能へのアクセスを提供し、最高のスループット (パフォーマンス) を提供するため推奨されます。

4.2 特徴

主な特徴：

長さ制限: キューの最大長を設定できます。キュー内のメッセージの合計サイズがこの値を超えると、最も古いメッセージが削除されます。
保持時間: キュー内のメッセージの最大保持時間を設定でき、この時間を超えたメッセージは自動的に削除されます。
メッセージのセグメント化: 大きなメッセージをセグメントに保存することをサポートし、各セグメントのサイズを設定できます。これにより、メモリ使用量が最適化され、メモリ消費量が削減されます。
高可用性: フローキューは Raft コンセンサスアルゴリズムを使用してレプリケーションを実装し、クラスター内のメッセージの高可用性とデータセキュリティを確保します。

4.3 声明

4.3.1 管理ページの宣言

ストリームキューが無限に大きくなるのを防ぐために、通常はx-max-length-bytesとx-stream-max-segment-size-bytesを設定する必要があります。具体的な例については4.4 を参照してください。
ここに画像の説明を挿入

4.3.2 クライアントの声明

以下の 4.4 の例を参照してください。

4.4 オプションの構成パラメータ

最大長バイト:セクション 2.4 を参照
最大保持時間: フローキューのデータ保持時間を時間単位 (Y=年、M=月、D=日、h=時、m=分、s=秒) で設定します。
最大セグメントサイズ (バイト) : ディスク上のストリームセグメントの合計サイズ。このパラメータは、フローキューの最大セグメントサイズ、つまりキュー内のメッセージの最大ストレージユニットのサイズを設定するために使用されます。メッセージのサイズがこの制限を超えると、メッセージは複数のセグメントに分割されて保存されます。
初期クラスターサイズ: セクション 3.4 を参照*
リーダーロケータ:セクション 3.4 を参照
ストリームキューのパラメータは通常、個別に設定することはできませんが、組み合わせて設定する必要があります。以下は一般的に使用されるストリームキュー宣言の例です

Map<String, Object> arguments = new HashMap<>();
arguments.put("x-queue-type", "stream"); 
//流队列大小是10G
arguments.put("x-max-length-bytes", 10_000_000_000L); 
//每个segment的大小是100M
arguments.put("x-stream-max-segment-size-bytes", 100_000_000); 
//流队列的数据保留时间1个月
arguments.put("x-max-age", "1M"); 
channel.queueDeclare("stream_queue", true, false, false, arguments);

5. レイジーキュー

5.1 概要

クラシックキューは遅延モードで動作できます。RabbitMQ 3.12 以降、キューモードは無視され、クラシックキューは遅延キューのように動作します。ただし、消費率に応じて、少数のメッセージ (現時点では最大 2048) をメモリ内に保持する場合があります。遅延モードで実行されるクラシックキューは、その内容をできるだけ早くディスクに移動し、コンシューマからの要求に応じてメモリにロードするため、遅延キューという名前が付けられます。遅延キューの主な目標の 1 つは、非常に長いキュー (数百万のメッセージ) をサポートできるようにすることです。キューはさまざまな理由で非常に長くなることがあります。

コンシューマがオフライン/クラッシュ/メンテナンス中です
メッセージ入力が突然急増し、プロデューサーの数がコンシューマーを上回ります
消費者の方が遅い

5.2 特徴

デフォルトでは、キューはメモリ内メッセージキャッシュを保持し、メッセージが RabbitMQ にパブリッシュされるとこのキャッシュが埋められます。このキャッシュの目的は、メッセージをできるだけ早く消費者に配信できるようにすることです。永続メッセージはブローカーに入るときにディスクに書き込まれ、同時にメモリに残る場合があることに注意してください。
ブローカーがメモリを解放する必要があると判断すると、キャッシュ内のメッセージはディスクにページングされます。メッセージのバッチをディスクにページングすると時間がかかり、ページング中にキュープロセスが新しいメッセージを受信できなくなります。RabbitMQ の最近のバージョンではページングアルゴリズムが改善されていますが、キュー内にページングが必要な数百万のメッセージが存在する可能性があるユースケースには依然として理想的ではありません。
遅延キューはメッセージをできるだけ早くディスクに移動します。つまり、通常の動作のほとんどの状況では、メモリ内に保持されるメッセージが大幅に少なくなります。これには、ディスク I/O オーバーヘッドの増加が伴います。

5.3 遅延キューモードを有効にする

5.3.1 クライアントモード

Map<String, Object> args = new HashMap<String, Object>();
args.put("x-queue-mode", "lazy");
channel.queueDeclare("myqueue", false, false, false, args);

5.3.2 戦略

ポリシーを使用してキューモードを指定するには、ポリシー定義にキーキューモードを追加し、サーバーによって提供されるRabbitmqctlツールを使用して実行します。次に例を示します。

rabbitmqctl set_policy Lazy "^lazy-queue$" '{"queue-mode":"lazy"}' --apply-to queues

キューモードがポリシーによって設定されている場合は、キューを削除したり再宣言したりせずに、実行時に変更できます。「lazy-queue」という名前のキューにデフォルト (非遅延) モードを使用させるには、その一致ポリシーを更新して別のキューモードを指定します。

rabbitmqctl set_policy Lazy "^lazy-queue$" '{"queue-mode":"default"}' --apply-to queues

コマンドの説明:

Rabbitmqctl : RabbitMQ サーバーを管理するための RabbitMQ の管理コマンドラインツールです。
set_policy : ポリシーを設定するコマンドです。
Lazy : 戦略セットの名前です。ここでは「Lazy」という名前です。
** "^lazy-queue $キュー名を照合するために使用される正規表現です。ここでの正規表現は「^lazy-queue」です。$ "の場合、キュー名が「lazy-queue」のキューのみと一致します。
'{"queue-mode":"default"}' : これは、戦略の特定の構成パラメーターです。ここでは、キューモードが「デフォルト」に設定されており、キューがデフォルトモードを採用していることを示している。
--apply-to queues : ポリシーをキューに適用するオプションです。

6. デッドレターキュー

6.1 概要

キューからのメッセージは「デッドレター」になる可能性があります。つまり、次のいずれかのイベントが発生すると交換に再発行されます。

コンシューマは、 basic.rejectまたはBasic.nackを使用してメッセージを否定的に確認し、requeue パラメータを false に設定します。
TTL プロパティの設定によりメッセージの有効期限が切れました
キューの長さ制限を超えたためにドロップされたメッセージ

キューの有効期限が切れても、キュー内のメッセージはデッドレターにならないことに注意してください。

Dead Letter Exchange (DLX) は通常の交換です。これらは任意の一般的な型にすることができ、従来どおりに宣言されます。
特定のキューについて、DLX はキューを使用するクライアントのパラメータによって定義することも、使用ポリシーをサーバーで定義することもできます。ポリシーとパラメーターの両方で DLX を指定する場合、パラメーターで DLX を指定すると、ポリシーで指定されたパラメーターがオーバーライドされます。

6.2 声明

6.2.1 ポリシーステートメント

アプリケーションの再展開を伴わない DLX の再構成が可能になるため、ポリシーを使用した構成をお勧めします。サービスによって提供されるRabbitmqctlツールを使用します。
例: すべてのキューにデッドレタースイッチを設定します。

rabbitmqctl set_policy DLX ".*" '{"dead-letter-exchange":"my-dlx"}' --apply-to queues

Rabbitmqctl:: は RabbitMQ の管理コマンドラインツールで、RabbitMQ サーバーの管理に使用されます。
set_policy: ポリシーを設定するコマンドです。
DLX: これはポリシーセットの名前で、ここでは「DLX」という名前です。
". ": は、キュー名を照合するために使用される正規表現です。ここでの正規表現は「.」で、すべてのキューの名前と一致することを意味します。
'{"dead-letter-exchange":"my-dlx"}': は、ポリシーの特定の構成パラメータです。ここではデッドレター交換、すなわち「デッドレター交換」が設定されています。
--apply-to queues: ポリシーをキューに適用するオプションです。

6.2.2 クライアントの声明

キューのデッドレター交換を設定するには、キューを宣言するときにオプションのx-dead-letter-exchangeパラメーターを指定します。値は、同じ仮想ホスト内の交換名である必要があります。

channel.exchangeDeclare("some.exchange.name", "direct");
Map<String, Object> args = new HashMap<String, Object>();
args.put("x-dead-letter-exchange", "some.exchange.name");
channel.queueDeclare("myqueue", false, false, false, args);

上記のコードは、「some.exchange.name」という新しい交換を宣言し、この新しい交換を新しく作成されたキューのデッドレター交換として設定します。キューを宣言するときに交換を宣言する必要はありませんが、メッセージをデッドレターキューに転送する必要があるときに交換がすでに存在している必要があることに注意してください。その時点で交換が存在しない場合、メッセージは警告なしに破棄されます。。
メッセージを配信不能キューに転送するときに使用するルーティングキーを指定することもできます。設定されていない場合、メッセージは独自のルーティングキーを使用します。

args.put("x-dead-letter-routing-key", "some-routing-key");

デッドレター交換が指定されている場合、ユーザーは、宣言されたキューに対する通常の構成権限に加えて、キューへの読み取りアクセスとデッドレター交換への書き込みアクセスも必要です。権限はキューの宣言時に検証されます。

要約する

この記事では、クラシックキュー、クォーラムキュー、フローキュー、レイジーキュー、デッドレターキューなど、RabbitMQ のさまざまな種類のキューを紹介し、その特徴と宣言方法について詳しく説明します。これらのさまざまなキューの種類を理解することで、ビジネスニーズに応じて適切なキューを選択し、メッセージングシステムのパフォーマンスと信頼性を最適化するのに役立つことを願っています。

RabbitMQ 入門ガイド: さまざまな種類のキューの詳細な分析