問題タブ [nservicebus-distributor]

NServiceBus を使用して処理パイプラインを構築していますが、プロセスの各ステップをスケーラブルにするためにディストリビューターの構成に問題があります。ここにいくつかの情報があります：

• パイプラインには、WorkItem の「OK、開始時間です」というマスター プロセスがあり、フローチャートのようなプロセスが開始されます。
• フローチャートの各ステップは計算コストがかかる可能性があるため、各ステップをスケールアウトできる機能が必要です。これは、各ステップに Distributor が必要であることを示しています。
• 後で追加のアクティビティをイベントにフックできるようにしたいと考えています。これは、Send() ではなく、完了時にメッセージを Publish() する必要があることを示しています。
• プロセスは、条件に基づいて分岐する必要がある場合があります。これは、プロセスが複数の種類のメッセージを発行できる必要があることを示しています。
• プロセスがフォークに参加する必要がある場合があります。これにはSagasを使用する必要があると思います。

これらの仮定が適切であることを願っています。

簡単にするために、分岐や結合については忘れて、ステップ A の後にステップ B が続き、ステップ C で終わる単純なパイプラインを考えてみましょう。各ステップは独自のディストリビューターを取得し、メッセージを処理する多くのノードを持つことができます。

• NodeA ワーカーには IHandleMessages プロセッサが含まれており、EventA を発行します
• NodeB ワーカーには IHandleMessages プロセッサが含まれており、イベント B を発行します
• NodeC ワーカーには IHandleMessages プロセッサが含まれており、パイプラインは完了しています。

構成ファイルの関連部分を次に示します。# はワーカーの番号を示します (つまり、入力キュー NodeA.1 と NodeA.2 があります)。

そして、ディストリビューター構成の関連部分は次のとおりです。

各ノードの 2 つのインスタンスを使用してテストしていますが、ノード B の途中で問題が発生しているようです。基本的に次の 2 つのことが発生する可能性があります。

1. ノード B の両方のインスタンスは、それが EventA をサブスクライブしていること、および NodeC.Distrib.Data@MYCOMPUTER がノード B がパブリッシュする EventB をサブスクライブしていることを報告します。この場合、すべてがうまく機能します。
2. ノード B の両方のインスタンスは、EventA をサブスクライブしていると報告しますが、一方のワーカーは NodeC.Distrib.Data@MYCOMPUTER が 2 回サブスクライブしていると言い、もう一方のワーカーはそれについて言及しません。

ディストリビューターがサブスクリプション メッセージをルーティングする方法によってのみ制御されるように見える 2 番目のケースでは、「オーバーアチーバー」ノードが EventA を処理する場合、すべてがうまくいきます。「未達成者」が EventA を処理すると、EventB のパブリッシュにはサブスクライバーがなく、ワークフローは停止します。

だから、私の質問：

1. このような設定は可能ですか？
2. 構成は正しいですか? 単純な 1 レベルのパブリッシャー/2 ワーカーのセットアップを超えて、ディストリビューターを使用した構成の例を見つけるのは困難です。
3. 計算集約型ではないすべてのトラフィック監視操作を実行し、タスクが長時間実行され、負荷分散が必要な場合にのみ、ディストリビューターの背後にあるプロセスにメッセージを送信する 1 つの中央ブローカー プロセスを持つ方が理にかなっていますか?
   • そうすれば、負荷分散されたノードは単純に中央ブローカーに返信することができます。これは簡単に思えます。
   • 一方で、それはNServiceBusの強みである分散化とは相反するように思えます。
   • そして、これが答えであり、長期実行プロセスの完了イベントが応答である場合、発行されたイベントで後で拡張できるようにする発行をどのように保持しますか?

ユーザーがサイトにログインしたときに、既存のコードベースで処理する負荷分散された Web サーバーがあります。サブスクライブしているアプリケーションに「x ログインしました」というブロードキャスト メッセージを送信したいのですが? そのため、多くの Web サーバーと多くのアプリケーションがサブスクライブしています。

nservicebus で検出作業/構成はどのように機能しますか? 各アプリケーションは各 Web サーバーを認識して個別にサブスクライブする必要がありますか、それともこれがディストリビューターの出番なので、Web サーバーはすべて 1 つのディストリビューターに送信し、すべてのアプリケーションは単一のディストリビューターにサブスクライブし、ディストリビューターはメッセージをリレーしますか?

これについて調べてみましたが、問題があります。

ありがとう

MrT

私たちは、電子メールを表示したりログ ファイルをチェックしたりするよりも操作が簡単な、インフラストラクチャ全体のシステムから生成された例外を報告するための洗練されたソリューションを見つけようとしています。サービス バスを介したパブリッシュ/サブスクライブ モデルは、この問題を非常にうまく解決します。サービスはエラー/イベントを公開し、サブスクライバは単純なパターン マッチングを使用してこれらのメッセージをフィルタリングできます。

NServiceBus プロジェクトを調査して、要件を満たしているかどうか疑問に思っていました。PubSub サンプル ( http://docs.particular.net/samples/pubsub/ ) を見て、次の 2 つのシナリオが解決されないことに気付きました。

1. すべてのパブリッシャーが同じメッセージ タイプをパブリッシュする
2. サブスクライバーは、パブリッシャー エンドポイントの知識を必要としません。

これらの要件は達成できましたが、構成が正しいかどうかはわかりません。当社のソリューションは次のとおりです。

1. すべてのパブリッシャーは、ドキュメントhttp://docs.particular.net/nservicebus/messaging/publish-subscribe/の「サブスクリプション ストレージ」セクションで説明されている共有データベースである、同じサブスクリプション ストレージ構成 (DBSubscriptionStorage) を共有します。

2. すべてのパブリッシャー/サブスクライバーは、nservicebus Web サイトのドキュメントで説明されているように、ディストリビューターを使用するように構成されています。

これが NServiceBus パブリッシュ/サブスクライブ モデルの正しい実装かどうか、または目標を達成する別のソリューションがあるかどうかを知りたいですか?

プロジェクトで nservicebus 1.9 バージョンを使用しています。パブリッシャー - サブスクライバー モデルを使用している私のプロジェクト。同様のパブリッシャーはメッセージをディストリビューターに送信し、ディストリビューターは同じメッセージをサブスクライブしたサブスクライバーの 1 つに転送します。

しかし、私のプロジェクトでは、サブスクライバーが何らかの操作を行い、データをデータベースに挿入します。

私の要件は、サブスクライバーがデータベースにデータを挿入できなかった場合、ディストリビューターに送り返す必要があるということです。どうすればそれを行うことができますか？サブスクライバーはメッセージをディストリビューターに送り返すことができますか?

nRk

こんにちは
私は私のプロジェクトでNServiceBus1.9RTMを使用しています。
パブリッシャー-ディストリビューター-サブスクライバーモデルを使用しています。
サブスクライバーでは、次のコードを使用してサブスクライブしました

購読を解除したいときは

ただし、購読を解除したり、エラーをスローしたりすることはありません。スクライブを解除した後も、EventHandlerはディストリビューターからメッセージを受信して​​います。

足りないものはありますか…？誰でも私を助けることができます。

nRk

EDA と NServiceBus を使用して 2 つのアプリケーションを分離しようとしています。現在、販売MTと在庫MTを持っています。セールス MT を通じて販売が要求されると、承認される前に、セールス MT は在庫 MT を呼び出して、利用可能な在庫があることを確認します。これが機能する方法を変更して、Sales MT が自動的に承認し、非同期の「SaleCreated」イベントを発行し、Inventory MT と Billing MT がサブスクライブするようにしたいと考えています。在庫 MT は、在庫切れのアイテムがある場合、オフライン プロセスで販売にフラグを立てることができます。

私の問題は、販売 MT のインスタンスが 10 個、在庫 MT のインスタンスが 5 個、請求 MT のインスタンスが 3 個あることです。3 つのアプリケーションはすべて、10/5/3 サーバーの前にある LoadBalancer の上に独自の仮想 IP を持っています。したがって、基本的に、1 つの仮想パブリケーション (SaleCreated イベント) と 2 つの仮想サブスクリプション (Inventory および Billing サブスクライバー) があります。理想的には、Sales MT によって処理される Sale は、1 つの Inventory MT と 1 つの Billing MT に送信される SaleCreated イベント メッセージを作成する必要があります。NServiceBus サイトでこのシナリオの例を見たことがないので、これがどのように機能するのか本当に混乱しています。また、サブスクリプションごとに 1 つのディストリビューターにすべてのメッセージを送信したくありません。1 つのマシンがボトルネックになるからです。

これを行う方法はありますか？

私はNServiceBusディストリビューターにわずかな問題を抱えており、これはおそらく私自身の無知ですが、これが起こっていることです-

私が持っている-a
。2台のマシンで実行されている2人のワーカー（サーバー）プロセス
b。1ディストリビューターがワーカーにメッセージを投稿するプロセス
c。1クライアントプロセスがディストリビューターにメッセージを投稿する

これで、すべてのサーバーが稼働していれば、すべて正常に機能します。

たとえば、ワーカープロセス＃2のみが実行されるように、ワーカープロセス＃1をシャットダウンします。しばらく待ってからディストリビューターにメッセージを投稿し始めます。気付いたのは、常に一部のメッセージがワーカープロセス＃1（シャットダウンされたプロセス）のキューに入れられることです。

これは、シャットダウンする前にサーバーがディストリビューターに準備ができていることを示し、ディストリビューターがこれらの制御メッセージに応答していたために発生したと思います。

私の質問は、ディストリビューターに接続されているワーカーを正常に閉じて、これ以上メッセージをキューに入れてはならないことを通知する方法があるということです。

ありがとう。

スケールアウトされたパブリッシャー (DB サブスクリプション ストレージを使用) からの複数のパブリケーションと、スケールアウトされたサブスクライバー (ディストリビューターを使用) による複数のサブスクリプションのコンテキストで、次の質問を検討してください。自動化された MSI を使用して、初期展開、アップグレードなどのためにインストールとアンインストールが定期的に行われます。 .

1. DB サブスクリプション ストレージを使用している場合、DB がダウンした場合はどうなりますか? メッセージを公開するためにサブスクリプション DB へのアクセスが必要な場合、メッセージはどのように配信されますか? それは失われますか？Bus.Publish の呼び出しは例外をスローしますか?
2. ダウンタイムの展開が必要ないと仮定すると、特定のパブリケーションのサブスクリプション DB を別のサーバーに移動したい場合はどうなるでしょうか? このような移行をどのように管理しますか?
3. サブスクライバー側のディストリビューターについても同じ質問があります。ディストリビューター エンドポイントを移動したい場合はどうすればよいでしょうか? 考えられるシナリオの 1 つは、単一のディストリビューター マシンを使用する複数のサブスクリプションがある場合、それらの一部を別のディストリビューター サーバーに移動して負荷を軽減するのが難しい場合です。
4. このようなセットアップの場合、インストール/アンインストールのシナリオはどのようになりますか (最初のアップグレードと継続的なアップグレードの両方)? 「論理パブリケーション」とサブスクリプション DB の展開、および「論理サブスクリプション」とディストリビュータ用の特別なインストール/アンインストール スクリプトが必要なようです。パブリッシャー インスタンスには、特別なインストール/アンインストール ロジックは必要ありません (構成されたサブスクリプション DB を使用してメッセージのパブリッシュを開始し、アンインストールされると停止するため)。サブスクライバー ワーカー ノードは、ディストリビューター エンドポイントの正しい構成以外に、インストール時に特別なことは必要ありませんが、ワーカー ノードのディストリビューター リストから確実に削除されるように、アンインストール ロジックが必要です。

ディストリビューターを使用せずにサブスクライバー ワーカー ノードの負荷を分散することはできますか? これが私が考えていることです：

ディストリビューターにパブリケーションをサブスクライブさせ、各ワーカー ノードに "義務を報告" させてメッセージを処理させる代わりに、各ワーカー ノードを仮想 IP の背後に置き、この仮想 IP をパブリケーションにサブスクライブするとどうなるでしょうか? 仮想 IP の背後にあるマシンに MSMQ メッセージを送信できますか?

NServiceBusディストリビューター（基本的にはソフトウェアロードバランサーです）を使用する代わりに、ネットワークロードバランサーを使用してサブスクライバーインスタンス間のメッセージの負荷を分散することを検討しています。各サブスクライバーインスタンスには、配信されるメッセージ用の同じ名前のキューがあり、サブスクライバー間でラウンドロビンする仮想IPがあります。パブリッシャーは、仮想IPとキュー名についてのみ知っています。

これを行うことの長所と短所として私が理解していることは次のとおりです。

1. 長所
   • NServiceBusDistributorをインストールする必要はありません
   • スケールアウト時に管理/更新する必要があるものが1つ少なくなります（これらのマシンの負荷分散にはすでにF5を使用しており、データセンターの購入者は手の甲のようにそれを知っています）
   • 単一障害点が1つ少なくなります（はい、NLBは失敗する可能性がありますが、それに直面しましょう。F5は、Windowsで実行されているNServiceBusディストリビューターよりもはるかに安定しています）
   • クラスター化されたMSMQを使用するために、クラスター化されたサーバーを用意する必要はありません。2台のサーバーは、F5に別のVIPを追加するよりもはるかに高価です。
2. 短所
   • NServiceBusディストリビューターを使用すると、モニターできるディストリビューターに単一のキューがあるため、メッセージのバックログをより簡単に確認できます。これにより、ワーカーノードをいつ追加する必要があるかを簡単に知ることができます。
   • NServiceBusディストリビューターは、ワーカースレッドの数などの制御に関してよりスマートです。NLBよりも詳細な制御を提供しますか？（これについてはわかりません）

これを正確にキャプチャしましたか？NServiceBusディストリビューターを使用することをお勧めします。その推奨に反対する前に、その理由を詳しく知りたいと思います。