RabbitMQで複数のコンシューマを持つキューのタスクオーダー処理を保証するにはどうすればよいですか？

Question

は私がこれらの

AとBの間の友情を終了したいと

AとBの間の友情を開始したいと言うが、私は、複数の消費者（労働者）を持つキューに送信する二つのタスクです。

私は保証処理注文をしたいので、最初の作業の前に2番目の作業を避けるにはどうしたらいいですか？

私のソリューション：make tasks sticky（Aに関するタスクは常に同じコンシューマに送信されます）。

実装：RabbitMQの交換番号を使用し、利用可能なコンシューマにタスクを割り当てます。

Aをコンシューマにマップするにはどうすればよいですか？私はnginxのip_hashについて考えている。私は似たものが必要だと思う。

関連性があるかどうかわかりませんが、AとBはuuid.v4() UUIDです。

マッピングを行うために必要なアルゴリズムを教えてください。

Answer 1

さて、2つのオプションがあります。

1. は、すべてのイベントの1つの交換/キューを作成し、それらが適切な順序で挿入するつもりだことを保証します。それらのために1人のワーカーを作成します。これは、データを挿入する際のコストが高くなります（スケーラビリティのオプションはありません）。
2. このような状況に備えてアプリを準備します。あなたがメッセージを得ると破壊する友情と友情は存在しない - 将来の友情の終わりを含むdbにメッセージを保存する。そうすれば、複数の労働者が友情を作り破壊することができ、適切な秩序を気にする必要はありません。単純にあなたの仕事をして、友人を作り、友情の終わりについての行がDBにあれば - それを破壊する（または単に作成しないでください）。もちろん、作成/破壊時間のタイムスタンプをチェックし、破壊時間が作成時間後であるかどうかをチェックする必要があります。

もちろん、A/Bのハッシュを何とか数えることができますが、IMOの方がコストがかかります。 excahnges/queuesを使ってアプリケーションをスケーリングするのは本当に良いことではありません - あなたはより多くのキューを作り、それはrabbitmqのあまりにも多くのキュー/エクスチェンジで終わります。

指定したソリューションを使用する必要がある場合は、たとえばAとBからcrc32を数え、キューのタスクを送信する値calcalateを使用できます。しかし、複数の消費者がいると、ここで間違っているかもしれません。消費者の一人が何とかブロックされ、他の人が友情を破壊してメッセージを受け取るとどうなりますか？このソリューションを使用すると、A/Bのグループごとに1人以上の作業者を持つことは危険であると言えます。