6

MassTransit で pub/sub プロジェクトのサンプルを読んだ後、頭を悩ませました。

サンプルでは、​​クライアント アプリケーションはサブスクライバー アプリケーションが架空のユーザーのパスワードを更新するための要求を発行します。このサンプル コードは問題なく動作し、このプロジェクトの跳ねるボールを簡単にたどることができます。

でも -

実際の環境では、pub/sub の目的は (私の理解では)、少数のパブリッシャーが多数のサブスクライバーとやり取りすることです。何らかの種類の CRUD 操作を実行するサブスクライバーの場合、通信パターンによって、複数のサブスクライバーがメッセージを処理できなくなるのではないでしょうか? たとえば、20 人のサブスクライバーが同じデータベース レコードを更新しようとするのは望ましくありません。

これは単なる見当違いのサンプル プロジェクトのケースですか?

pub/sub を CRUD 操作に使用できる場合、フレームワークをどのように構成して、1 つのサブスクライバーのみが操作を実行できるようにしますか?

パブリッシュ/サブスクライブの目的に関する基本的な情報が完全に欠落しているだけですか?

提供された説明に感謝します...

デビッド

4

2 に答える 2

5

あなたが参照するシナリオは、通常「競合する消費者」と呼ばれ、パブ/サブの非常に典型的なものです。

各コンシューマーが独自の一意のキュー名を持っている場合、各コンシューマーは独自のメッセージのコピーを受け取ります。

あるいは、競合するコンシューマーの動作を取得するために、コンシューマーが同じキュー名を共有している場合、メッセージごとにコンシューマー間で競合が発生します (したがって、各メッセージは 1 回だけ受信されます)。

于 2012-01-24T19:22:09.177 に答える
3

任意のパブ/サブシステムで、n 対 n、多対少数、または少数対多のパブリッシャーとサブスクライバーを使用できます。与えられたメッセージに何人のアクターに応答してもらいたいかが問題です。

サンプル プロジェクトは最適ではないかもしれませんが、何が起こっているかを示していると感じています。ただし、実際のケースでは、CRUD タイプの動作に使用できます。ただし、多くのフロント エンドが「データの読み込み」タイプのメッセージをミドルウェア (キャッシュ) に送信し、同じデータの応答を要求する傾向にあります。そのデータが何らかの形でフロントエンドで更新された場合、複数のミドルウェア (キャッシュ、バックエンド ストアなど) を更新する必要があることを示すメッセージを発行する必要があります。[ CQRSを参照]

一般的にメッセージングは​​、切断されたシステムでの作業に関するものです。あなたの特定の世界は、消費者と発行者の構造に関するものです。私は MassTransit の実装を見てきましたが、ほとんどのルートが静的であり、実際には pub/sub ではなく、システムの既知のトポグラフィに沿って多くの送信が行われていました。概念を本当に理解している私が知っている最高の本はEnterprise Service Bus: Theory in Practiceです。

これが役立つことを願っています！

編集:ドキュメントも参照してください。いくつかの概念はそこで触れられています。

于 2012-01-25T04:02:16.020 に答える