[解決済み] RabbitMQ - メッセージの配信順序

質問

新しいプロジェクトで、新しいキューブローカーを選択する必要があります。

今回はpub/subをサポートするスケーラブルなキューが必要で、メッセージの順序を保つことは必須です。

Alexisのコメントを読みました。彼はこう書いています。

確かに、RabbitMQはKafkaよりも強力な順序付けを提供すると思います。

rabbitmqのドキュメントでメッセージの順序付けのセクションを読みました。

"メッセージは、以下の機能を持つAMQPメソッドを使ってキューに戻すことができます。 requeue パラメータ (basic.recover, basic.reject and basic.nack) を備えた AMQP メソッドを使用して、あるいは未承認メッセージを保持したままチャネルが閉じられたために、メッセージがキューに戻されることがあります。 または、未承認のメッセージを保持したままチャネルが閉じることによってキューに戻されます。 リリース 2.7.0 以降では、キューに複数の購読者がいる場合、個々の消費者が順序を無視してメッセージを キューに複数の購読者がいる場合、個々の消費者が順序を無視してメッセージを観測することが可能です。これは これは、メッセージを再要求する可能性のある他の購読者の行動によるものです。キューの観点からは の観点からは、メッセージは常に公開順序で保持されます。

メッセージを順番に処理する必要がある場合、各コンシューマに排他的なキューを持つrabbitMQを使用するしかないのでしょうか？

RabbitMQは今でも順序付きメッセージキューイングの良い解決策と考えられていますか？

どのように解決するのですか？

さて、上記のシナリオを詳しく見てみましょう。重要なのは ドキュメント を貼り付けて、コンテキストを提供することが重要だと思います。

AMQP 0-9-1 コア仕様のセクション 4.7 では、順序付けが保証される条件について説明されています。 順序付けが保証される条件について説明しています。 1つのチャネルで発行され、1つの交換と1つのキューと1つの送信チャネルを通過するメッセージは、それらが発行されたのと同じ順序で受信されます。 送信されたのと同じ順序で受信されます。 というものです。RabbitMQは、リリース2.7.0以降、より強力な保証を提供しています。

メッセージは、以下の機能を持つAMQPメソッドを使用してキューに戻すことができます。 requeueパラメータ（basic.recover、basic.reject、basic.nack）、または 未承認のメッセージを保持したままチャネルが閉じられたことによるものです。これらのシナリオのいずれかが これらのシナリオのいずれかが、RabbitMQのキューの後ろにメッセージが再キューイングされる原因となっていました。 2.7.0より前のRabbitMQリリースでは、メッセージがキューの後ろに再キューイングされました。RabbitMQリリース 2.7.0以降では、メッセージは常に公開順にキューに保持されます。 は、リクエアリングやチャネルクローズがあっても、常に発行順にキューに保持されます。 (強調)

というわけで、RabbitMQは2.7.0以降、メッセージの順序付けに関して、オリジナルのAMQP仕様よりもかなり大幅な改善を行っていることがわかります。

複数の（並列）コンシューマーでは、処理の順序は保証されません。

3番目の段落（質問に貼り付けられている）では、免責事項が述べられており、私はそれを言い換えます："キューに複数のプロセッサがある場合、メッセージが順番に処理される保証はもはやありません。

ある銀行の顧客の列を考えてみましょう。この特定の銀行は、顧客が銀行に入ってきた順番に支援することを誇りにしています。 顧客は列に並び、利用可能な3人のテラーのうち次の人がサービスを提供します。

今朝、たまたま3人の窓口係が同時に空いたので、次の3人の客が近づいた。ところが突然、3人のうちの1人が激しく体調を崩し、列の先頭のお客さまに対応しきれなくなったのです。そのとき、2番窓口は2番目のお客さまへの対応を終えており、3番窓口は3番目のお客さまへの対応を始めていました。

さて、2つのうちの1つが起こる可能性があります。(1) 列の先頭の客が列の先頭に戻るか、(2) 先頭の客が3番目の客を先取りし、そのテラーに3番目の客への対応を止めさせ、先頭の客への対応を始めさせるかです。このタイプの先取りロジックは、RabbitMQでも、私が知る限り他のメッセージブローカーでもサポートされていません。どちらの場合でも、最初の顧客は実際には最初に助けられることはなく、2番目の顧客が助けられることになります。顧客が順番に対応することを保証する唯一の方法は、1人のテラーが一度に1人の顧客を対応することですが、これは銀行にとって大きな顧客サービスの問題を引き起こすことになります。

ご質問の問題点を説明するのにお役に立てれば幸いです。複数のコンシューマがある場合、すべての可能なケースでメッセージが順番に処理されることを保証することは不可能です。複数のキュー、複数の排他的コンシューマー、異なるブローカーなどがあっても関係ありません。- を保証する方法はありません。 先験的 を保証する方法はありません。しかし、RabbitMQはベストエフォートで対応します。