クリティカルミッションシステム向けの分散型n-Producers / 1-Consumerサービスの実装
クリティカルミッションシステム用に分散バージョンのmulti-producer / 1-consumerを実装しようとしています。RDBMSに基づく現在のアプローチに代わる優れた方法を探しています。
問題
このシステムは、1秒あたり数千のインスタンスを継続的に生成するサーバー（50以上）のプロデューサーで構成されています。各インスタンスは、明確に定義され、タイムスタンプが付けられ、フラットな構造になっています。各インスタンスは、プロデューサーによって単一のキューに格納されます。
反対側には、FIFO方式でインスタンスを消費するコンシューマーがあります。
プロデューサーとコンシューマーは、TCP / IPプライベートネットワークで接続された異なるマシンで実行されます。
完全を期すために、2つの強力な要件があります
- コンシューマーは同じリソースを2回消費することはできません。エラーです。
- すべてのリソースは、コンシューマーによって消費される必要があります。リソースが失われた場合、それは損失です
さらに、ソリューションはLinuxおよびWindowsサーバーで実行する必要があります。
現在のアプローチ
現在のバージョンでは、システムはリレーショナルデータベースをデータバスとして使用することでこのソリューションを実装しています。
すべてのプロデューサーとコンシューマーをサポートするデータベースサーバーが1つあります。上の画像に示されているように、プロデューサーは決定されたテーブルにリソースを挿入し、コンシューマーはそのテーブルのリソースを消費します。
データベースサーバー/ JDBCトランザクションモデルでは、キューの破損を回避するために挿入/削除を制御できます。
その現在のアプローチはうまく機能しますが：
- データの関係が不要なタスクのために、リレーショナルデータベースサーバー全体を維持するオーバーヘッドを導入します。
- リレーショナルデータベースサーバーは、データベースサーバーインスタンスが専用でない場合、一部の実際の設定では達成が難しい重要なミッションの要件に適合している必要があります
代替案
ここに、現在のリレーショナルデータベースサーバーのデータバスアプローチの代替案をいくつか示します。
専用の軽量リレーショナルデータベースサーバー
これが最も簡単なアプローチのようです。専用の軽量リレーショナルデータベースサーバーをHSQLDB、Apache Derby、またはH2として使用します。
長所
MS SQL Server、Oracle DB Server、さらにはMySQLなどのRDBMSと比較した場合、維持するオーバーヘッドが大幅に少なくなります。さらに、これらは基本的に現在のソリューションで使用されているようなSQLエンジンであるため、コードの変更やテストは少なくて済みます。
短所
これらはリレーショナルデータベースサーバーであるため、リレーションシップのないタスクを実行するには、まだある程度のオーバーヘッドが存在することがわかります。もう一つのポイントは、クリティカルミッションの側面です。組み込みモードとネットワークモードの両方でリアルタイムのシステム監視を行うために、DerbyDBを社内で長年使用しています。それはうまく機能し、クラッシュもデータ破損もありません。ただし、その新しい使用法の1秒あたりのトランザクション量は多くなります。
Redisサーバー
一見すると、Redisはこのユースケースに最適に見えます。メモリ内では、高速で、データの関係に過剰な影響はなく、簡単です。データバスとして広く使用されており、信頼できると報告されています。しかし、Windows用ではありません。ドキュメントに記載されているように、WindowsでのRedisは推奨されていません。Microsoft Windowsのポートはもはや維持されて2016年、最後のリリース日を有望ないシステムルックスにRedisのを取り付けるようにします。
ソリューションを最初から実装する
言い換えれば、それは生産者/消費者問題です。TCPまたはCamelなどのより洗練されたものを使用してネットワークサービスを実装し、内部で並行キューといくつかのローカル永続化エンジンを使用すると、時間とコストがかかり、車輪の再発明が行われますが、それでもオプションです。
これらは、これまで検討してきた代替案です。誰かが洞察や推奨を提供してくれれば幸いです。
回答
メッセージキューを探しているようです。技術スタックに応じて、ZeroMQやRabbitMQなど、関心のある分散キューのさまざまな実装があります。
ZeroMQのようないくつかのアプローチは、メッセージブローカーがなくても実行できます。つまり、プロデューサーとコンシューマーは、キューを調整/ブローカー化するための別のサービスやデータベースを必要とせずに直接対話します。ブローカーレスであることには、ブローカー化されたメッセージキューよりも運用管理がはるかに簡単であり、理解とスケーリングおよびカスタマイズが簡単であるという利点がありますが、主な欠点は、ブローカーによって通常提供されるサービスが不足していることです。オフラインの場合、メッセージが失われる可能性があります。メッセージを確実に処理する必要がある場合は、コンシューマーが利用できない場合に再送信を処理できるようにプロデューサーを設計する必要があります。また、正常な配信を確認するメカニズムを追加する必要があり、コンシューマーのニーズべき等になるように設計されている（重複メッセージを検出して破棄できる）。ブローカーレスであることの主な利点は、アプリケーションが必要とするだけのブローカーの動作を自由に実装できるため、特定のブローカーの動作に縛られることがないことです。
RabbitMQのようなブローカーメッセージキューは、プロデューサーとコンシューマーに実装を要求するのではなく、キューシステムのファブリックに永続性とメッセージングの信頼性レイヤーを追加するため、使用中はややシンプルですが、ブローカー管理の複雑さとオーバーヘッドが追加されます、およびブローカーはレイテンシーを追加するため、ミリ秒が重要なシナリオや、ターゲットのスケーラビリティレベルがブローカーシステムで達成できるレベルを超えるシナリオには適さない場合があります。
関係のないタスクを実行するには、まだある程度のオーバーヘッドがあります
アプリケーションのプロファイルを作成して、それが実際に重要かどうかを実際に確認することをお勧めします。インプロセスSQLデータベースが非並行アプリケーションに十分でない場合は、関係管理自体のパフォーマンスの問題ではなく、非効率的に使用している可能性があります。