驚異的並列問題（N個の独立したセクションに分割できる問題）に紺碧のサービスバスを使用しようとしています。これは本質的にマップ/リデュースの問題ですが、リアルタイムの回答が必要なため、Hadoopを使用したくありません（<1秒）
私の最初の計画は、それぞれがデータベースの1/Nスライスを持つ多数のワーカーを持つことです。次に、バスにN個の探索問題を配置すると、各ワーカーがその処理を実行します。アグリゲーターは結果を結合します。
ここで間違った木を吠えていますか？これは、この種の問題を解決するための間違った方法ですか？
あなたの一般的なシナリオは健全であり、非同期/並列システムを構築する多くの人が毎日使用するシナリオです。
ただし、結果を1秒未満で集計するという要件は、より問題になる可能性があります。メッセージをキューにスローするということは、メッセージが永続化され、ストーリーのワーカースレッドの最後で逆シリアル化されることを意味します。次に、ワーカースレッドはいくつかの作業を実行し、結果をキューまたはストレージにスローして、後で集約する必要があります。
1秒未満のレイテンシ要件を一貫して達成できることに気付くかもしれませんが、そうではないかもしれません。テストすることによってのみ、パフォーマンスとレイテンシの要件に到達できるかどうかがわかります。作業をキューに入れるアプリを作成し、作業をプルして意味のあることを実行してから応答を返すワーカーの役割を作成することをお勧めします。
測定、微調整、測定、微調整。その後、あなたは知っているでしょう;）
レイテンシーが最も重要であり、ServiceBusが必要なパフォーマンスを提供できない場合は、永続性のオーバーヘッドを回避することを検討し、代わりに、作業データのバッチを共有キャッシュにスローして、作業が必要になったときにワーカーに通知することをお勧めします。
ただし、このインフラストラクチャの多くは、ワーカー通知メカニズム、再試行、処理中のマークの処理など、ServiceBusが自動的に提供するものを含めて自分で構築する必要があることに注意してください。
HTH。