問題タブ [nservicebus-distributor]

データベースから som id を選択し、いくつかのビジネス ロジックで順番に処理するサービスが 1 つあります。多くの内部スレッドを作成せずに、スケールアウトして並行して実行したい処理。

私の質問は：

Distributor を使用してスケールアウトしたい場合、どのようにすればよいですか?

解決策 1: サービスは 2 つに分割されます。

1. 元のサービスは、データベースから ID のみを選択してワーカーに送信するように変更されています。これがディストリビューターになります (RunDistributorWithNoWorkerOnItsEndpoint)。
2. ビジネス ロジックを保持し、ワーカーとして機能し、すべての受信 ID を処理する新しいサービス。より多くのワーカーが必要な場合は、同じプロセスを複数回開始するだけです。

解決策 2: サービスは 3 つに分割されます。

1. 元のサービスは、データベースから ID のみを選択してディストリビューターに送信するように変更されています。
2. ワーカーへの負荷分散のみを処理する新しいサービス、ディストリビューター (RunDistributorWithNoWorkerOnItsEndpoint)。
3. ビジネス ロジックを保持し、すべての着信 ID を処理する新しいサービス、worker(s)。

解決策 3: サービスは 2 つに分割されます。

1. 元のサービスは、データベースから ID のみを選択して送信するように変更されています。送信者として実行しています。
2. ビジネスロジックを保持し、ワーカーおよびディストリビューターとして機能し、すべての着信 ID を処理または配布する新しいサービス。

解決策 1 は私にとって非常に理にかなっていますが、それを使用すると、どういうわけかディストリビューターが 2 つの責任を持つことになります。

1. ID を選択します。
2. ID をワーカーに配布します。

しかし、NSB ドキュメントの ScaleOut の例を見ると、これが可能かどうか、またはアンチパターンであるかどうかはわかりません。

解決策 3 は、ドキュメントと ScaleOut の例をもう一度読んだ後、私が行くべきだと私が信じているものですが、まだよくわかりません。

NSB ディストリビューターを使用してスケールアウトすることで配管の問題を解決しようとしています。NServiceBus.Host.exe を使用するのではなく、独自のホスティングを行いたいと考えていますが、これは厳密な要件ではありません。

編集： デフォルトのキュー命名を使用している場合、キューを構成するタスクがソリューション2よりも小さいという利点があるため（私の意見では）、ソリューション3を使用することになりました。

敬具

NServiceBusでディストリビューターを使用していますが、DTCに関して無視の壁にぶつかりました。私は、プロセス間で何かを行うときにDTCを1回、おそらく2回しか使用していませんでした。そのため、DTCの概念全体に非常に慣れています。

私が尋ねる理由は、NSBがハンドラーなどの例外を検出できることを期待しているため、キューからメッセージを削除しないことでエラーに対応できるからです。したがって、DTCは必要ありません。もちろん、これは、ハンドラー内のデータベースまたは外部サービスへのアクセスでは、プログラマーが自分自身のロールバックなどを実行する必要があることを意味します。そのため、DTCは最善の方法のようです。したがって、DTCは（私が正しく理解していれば）私の観点からすると、ハンドラーが正しく実装され、他の外部サービスがDTCに参加している限り、メッセージがキューから失われることはなく、メッセージ処理が破損することはありません。 。

しかし、特にサーバー保守チームで尊敬されている人が「DTCはあなたに苦痛の世界を引き起こすでしょう！」という文を使用したので、よくわかりません。私が彼によってデータベースサーバー上でDTCをアクティブ化するというアイデアを実行したとき...しかし、彼はまだDTCにそれほど苦痛を感じている理由について議論をしていません...：/。

DTCとNSBをよく理解している人が、DTCの理解が完全にずれているかどうか、およびDTCで完全に見逃している大きな落とし穴があるかどうかを明確にするのを手伝ってもらえますか？

敬具

私は現在NSBでディストリビューターを評価しており、自分のマシンでディストリビューターと数人のワーカーを実行すると、各ワーカーのキュー名にGUIDが追加されることに気付きました。

マスター自身のUdiによると:)、この投稿では：同じマシンのディストリビューターとワーカーのエンドポイントキュー

その理由は、NSBはテストセットアップで実行していると想定しているためです。

質問：

しかし、1台の別々のマシンで4人のワーカーを実行するとどうなりますか？そのマシンのキュー名に再びGUIDが追加されますか、それともディストリビューターがリモートマシン上にあるという理由だけで、ワーカーは同じキューを共有できますか？

1台のリモートマシンに複数のワーカーが存在することを期待していたため、この質問は重要です。マシンが起動するたびに新しいキュー名を生成することは、メンテナンスの目的ではお勧めできません。

敬具

昨日、ディストリビューターとの非常に有望なテストの後で、NSB（36-80コア）のライセンスを購入するための追加予算を要求しました。

現在、配管の問題を解決するためにディストリビューターを使用しており、実際のビジネスイベントにはまだ使用していませんが、それは後で行われます。

今日、私の非常に熟練した同僚もバスを使い始めました。彼のプロジェクトの性質上、彼のパフォーマンス要求だけが私のものよりもはるかに高くなっています。したがって、彼のテストでは、ディストリビューターが現在私に提供している平均30〜50msgpr秒よりもはるかに多くの時間が必要です。

私たちがやろうとしたことは何でも：

1. より多くの労働者。
2. ワーカーに関するスレッドが増えました。
3. ディストリビューターのスレッドが増えました。
4. DTCの有効化/無効化
5. 上記のすべては、IDのみを含むメッセージを使用した概念実証のセットアップです。約100msgの分散PRを取得できませんでした。労働者に次ぐ。

私はすでにより多くの予算を申請しているので、これは非常に悪いことです。パフォーマンスをすぐに上げることができない場合は、プロジェクトを中止する必要があり、深刻な問題が発生します：S。

質問：

現在使用している開発者ライセンスに制限があり、この制限が発生していますか、またはたとえばここで説明されているように、MSMQに重大なパフォーマンスの問題がありますか？http：//ayende.com/blog/4251/what-am-i- missing-msmq-perf-issue。

私はnservicebus自身のサイトでライセンスについてたくさん読んでいますが、開発者ライセンスの制限についての明確な説明はどこにもありません。

誰かが私を助けてくれることを願っています:)。

[アップデート]

基本に戻り、10000個のメッセージを送信してワーカー/ディストリビューターがどのように反応するかを確認することで、NSB独自のコードサンプルScaleOutの問題を再現しようとしました。そこで、ディストリビューターと2人のワーカー（ワーカーにはそれぞれ100個のスレッドがあります）を起動し、問題が再び発生したことを推測します。

1. 幸い、これは、ディストリビューター/ワーカーのセットアップが完全に間違って構成されていないことを示しています。
2. 残念ながら、これはディストリビューターのパフォーマンスにまだ問題があることを意味します。

次に、これが実際に当てはまるのかどうか疑問に思い、ディストリビューターとワーカーを使用してテストを調整しながら、いくつかの単純な数のスレッドを実行し始めました。何度か試した後、サンプルで最大400〜500 msgprsecのスループットが得られました。これが私が発見したものです：

観察/解決策：

1. ディストリビューターには、1つだけではなく、より多くのスレッドが必要です。現在、2つのスレッドを実行しています。労働者私は起動します。
2. 20または100スレッドを実行している場合、ワーカーは通常同じパフォーマンスになります。そのため、スレッドの数を増やす代わりに、ワーカーの数を増やしました。これでうまくいきました。
3. ディストリビューターまたはワーカーのいずれかのスレッドの数が多すぎると、MSMQトランザクションの競合が発生しているように見えます。そこでは、スレッドが相互にブロックし、システムがバーストで詰まります。ScaleOutサンプルと自分のコードを使用して、詰まりを簡単に再現できますが、TXの戦いは、私が読んだ記事に基づく単なる推測であり、これが起こっていることを証明するものではありません。

フォローアップの質問：

1. 今何をする？MSMQを別のものに置き換える必要がありますか、それともこの問題はNSBの内部にあるものであり、後のバージョンで最適化/修正される可能性がありますか？
2. これは、ディストリビューターが機能するための意図された方法ですか？つまり、私たちの唯一の解決策は、より多くの労働者を解雇することです。
3. 同じエンドポイントに複数のワーカーがありますが、ディストリビューターとは異なるマシンが実行されていても、ワーカー間でMSMQ TXの競合を引き起こす可能性のある、競合するコンシューマーの状況は発生しませんか？
4. サンプルと独自のコードには重要な違いが1つあります。Ravenサブスクリプションストレージを無効にし、純粋にMSMQで実行していますが、私が知る限り、ディストリビューターはストレージにRavendbを使用していません。私は間違っていますか？これはパフォーマンスを得る場所になる可能性がありますか？

ディストリビューターと同じマシンではなく、同じマシンで複数のワーカーを起動する際に問題が発生するかどうかを確認するために、現在いくつかの分散テストを実行しています。ワーカー用に追加のサーバーをすでに注文しており、それ以上の予算がないため、ワーカーごとに個別のキューを設定しなくても、これが可能になることを願っています。

これまでのところ、ワーカーのスレッド数を単純に増やして1人のワーカーから始めて、後でそれぞれ1人のワーカーを持つより多くのマシンにスケールアウトすることができないことに少しがっかりしています。現在、1台のマシンに複数のワーカーを配置する必要があります：/。

ディストリビューター/ワーカーが足りないという小さな点があれば、共有してください。これが私を夢中にさせているからです：/。

[更新2]

NServiceBus.Integration NServiceBus.Distributor / Workerと1人のワーカーを使用してVisualStudioの外部でScaleOutサンプルを実行すると、4〜500msg/秒のスループットを得ることができます。

これは素晴らしいことですが、私たちがセルフホスティングしている私たち自身のセットアップで私が間違ったことを説明していません。私たちの構成を見て、何か怪しいものがあるかどうか教えてください：

卸売業者：

ワーカー：

パフォーマンスの違いを引き起こす可能性のある、ここで間違っていることはありますか？

敬具。

コンポーネントをデプロイするたびに、次の例外を受け取りました。コンポーネント自体が開始されないこともあれば、サービス コンソールが開始済みと表示されることもありますが、サービスはメッセージを処理しません。エラーは非常に簡単です。まだプレフィックスをリッスンしている別の HttpListener があります。

深い分析を行うとき。

1. この問題は、NServiceBus.Master プロファイルを実行している場合にのみ発生します
2. この問題は、サービス コンソールから実行サービスを再起動するたびにのみ発生します
3. 実行する WorkerThreads の数に関係ありません

NSB コードをさらに深く読むと、オブジェクトの Dispose 中に HttpListener が閉じられていることがわかりました。これに加えて、サービスを停止すると、プロセス自体が強制終了されるため、指定された URL プレフィックスをリッスンするオブジェクトがマシン上に存在しなくなります。しかし、私たちは間違っていました。多くの閉鎖を分析したところ、Service-Console がサービスが停止したと見なした後でも、NServinceBus.Host プロセスがまだ実行されていることがわかりました。サービス コンソールでサービスを停止するたびに、プロセスはマシン上でまだアクティブであり、完全にシャットダウンするのにかなりの時間がかかりました。そのため、再起動を実行すると、現在のサービスのプロセスのインスタンスが複数存在する可能性があります。1 つが開始しようとしていて、別のインスタンスがまだ停止しようとしています。再起動プロセスで上記の例外がスローされることを確認しました。

シャットダウンしていたプロセスのダンプを取得しました。サービス コンソールでステータスが停止と表示されていても、バックグラウンド スレッドがまだプロセス上でアクティブであることがわかりました。破棄中にロック/ObjWait が大量に発生します。停止したサービスがまだ HttpListener オブジェクトを閉じていないことを確認してください。

HttpListener がアクティブでリッスンしていることがわかりました。

質問: プロセスがまだマシン上でアクティブであるにもかかわらず、サービス コンソールがサービスが停止していると報告するのはなぜですか

注:この問題を再現するには、NServiceBus.Master プロファイルを使用してホストを Windows サービスとしてインストールし、サービスの再起動を試行する必要があります。この問題を解決するには、さらに試行が必要になる場合があります。

アップデート：

HttpChannelReceiver.Start() で NSB コードを読むと、新しいスレッドでリスナーが開始されます。

1. このリスナー スレッドはフォアグラウンド スレッドです。(他のすべてのワーカー スレッドは BG スレッドです)
2. このフォアグラウンド スレッドに停止信号は送信されません
3. このスレッドの参照を保持する変数/フィールドはありません。中止はできません。

このリスナー スレッドは、ServiceHost が現在のプロセスのメモリを強制終了したときにのみ再利用されます。ServicHost がそれを収集するまで、このスレッドは現在のプロセスを終了できません。

私たちは、フェデレーテッド システムのメッセージング フレームワークとして NServiceBus を使用するライセンス製品です。

新しい機能でそれを使用する機会を探しています-各サイト/ノードがメッセージを生成し、複数のノード/サイトにあるワーカーに配信するマルチサイト システム (スケールアウト) を構築する方法はありますか? 各ディストリビューターとワーカーは、独自のサイト (同じ LAN) でホストでき、各サイトはいつでもダウンできます。すべてのディストリビューターとワーカーは対称である必要があります。

最初は、古典的な「多くの生産者と多くの競合する消費者」の問題のように見えました。しかし、NServiceBus でそれを達成するための組み込みの方法を見つけることができません。私が見たところ、各ワーカーは健康歌を 1 つのディストリビューターにしか送信できないためです (これについては間違っている可能性があります)。

私が直面したもう 1 つの問題は、ディストリビュータ サブスクリプションを保持する集中型の RavenDB インスタンスを使用することです。RavenDB を独自の「可用性グループ」に含めるには、追加のリソースが必要です。RavenDB インスタンスを同じサイトでホストし、各サイトがローカル DB インスタンスを使用している間にデータをレプリケートする方法はありますか? これにより、ディストリビューターの HA もサブスクリプション DB にバインドされます。

このディスカッションを読む- http://tech.groups.yahoo.com/group/nservicebus/message/18412 NServiceBus には、公開されたデータの HA を維持するためにクラスターが必要なようです。しかし、ディストリビューターは、メッセージがワーカーによって正常に消費および処理されたという確認応答を待つことができず、同じワーカーまたは別のワーカーへの発行を再試行し続けることができないのはなぜですか? このようにして、VM がキュー内のデータでダウンした場合でも、データはその時点で使用可能な別のノードに送信されます。

編集: NServiceBus 公式 Yahoo グループで同じことを尋ねようとしましたが、yahoo グループ内で pythonError を取得し続けます。

前もって感謝します、Rami Prilutsky、dbMotion

ディストリビューター/ワーカーで遊んでいましたが、アプリケーションを再起動している間、毎回一意の ID で新しいワーカー キューを作成していました。

どんな手掛かり？？ディストリビューター/ワーカーとその構成について理解するのに最適な場所はどこですか。

DistributorDataAddress とは何ですか? WorkerNode での使用は何ですか????

すべてのスケーリングの例で、これが Worker でセットアップされていることがわかります。