受信トレイからすべての電子メールを読み取り、解析してデータベースに挿入するメール読み取りサービスがあります。私が直面している問題は、メールを受信順に解析するという保証がないことです (これはビジネス要件です)。これに対する私の修正は、ある種の待ち行列システムを導入することです。このようにして、アイテムを受け取った順に処理します。これにより、メールの読み取りとデータベースへの解析/挿入を切り離すという利点も得られます。
だから私の質問は、メッセージをローカルに送信することだけを計画している場合、サービス バス (NServiceBus など) を使用するのはやり過ぎですか? つまり、電子メールを読み取るサービスと、データベース内の電子メールを解析/挿入するサービスが同じマシンに存在します。
ありがとうございました。
はい、特にNServiceBusはメッセージが順番に配信されることを保証しないため、これは明らかにやり過ぎです。
メッセージを順番に取り出す方法を知っていると仮定して、を使用できQueue<T>ます（これは、キューなどを使用しているかどうかではなく、問題が発生している場所のようです。取得方法を知っている必要があります。アイテムを正しい順序でキューに入れます）。
KISSとYAGNIはここで、一日中、毎日応募します。
持続性の問題については、MSMQ をお知らせください。一度入れれば、マシンの電源が落ちたり、他のアプリケーションがクラッシュしたりしても、そこにあることが保証されます。
場合によります。あなたのアプリケーションについては、私はJasonに同意します。サービスバスは、ローカルデータ構造よりも順番にメッセージを処理するのに役立ちません。そして、ジェイソンが言ったように、サービスバスのメッセージの順序が保証されていないことを考えると、それはおそらくもっと難しいでしょう。
ただし、サービスバスを使用してローカルにメッセージを送信すると非常に便利です。他のプロセスに非同期でメッセージを送信するのが非常に簡単になります。メッセージのコンシューマーは別のプロセスにあるため、スレッド化の懸念は実際にはありません。メッセージは耐久性があるので、何かが見落とされることを心配する必要はありません。また、新しいサブスクライバーを追加するだけで、事後にメッセージの処理を追加するのは非常に簡単です。追加のボーナスとして、システムが大きくなりすぎて1台のマシンで快適に実行できない場合は、バスを分散させるのは簡単です。
あなたの解決策にとって、それは不必要であり、問題を引き起こすかもしれません。ただし、ローカルでサービスバスを使用することが理にかなっている場合があります。
私が嫌いな言葉だろう。私の意見では、アプリケーションの許容可能なパフォーマンスの制限に影響を与えることなく、システムを可能な限り柔軟にします（あなただけが知っているかもしれません）。
一般的に：あなたが考えることができる最悪のマーケティング決定に備えてください。
これは、ZeroMQ がうまく機能する種類の仕事であり、副次的な利点は、他の言語や他のプラットフォームでも使用できるツールの使用方法を学ぶことです。