明日は、インプロセス メッセージ キューの実装を選択する理由を説明しますが、その理由を明確に説明することはできません。私の共同設計者は、ジョブの基本的なリストとミューテックスを使用してアクセスを制御する単純な非同期キューを実装することを提案しています。私は組み込みモードの ActiveMQ を提案しています。私は個人的に ActiveMQ に非常に感銘を受けました。私の直感的な印象を裏付けるために、いくつかの適切で確固たる議論をしたいと思います。
それが重要な場合、アプリケーションは基本的に 1 つのプロデューサー/n 人のコンシューマーであり、処理される個々のジョブに固有の優先度とタイプの情報があります。
これまでのところ、ソリューションの管理性と拡張性は強力な議論になっていないことに注意してください。誰かが私の主張にもっとパンチを与えてくれたら嬉しいです. フォーラムはそれについて私を助けることができますか?
あなたの同僚の主張には、根拠がないわけではありません。プロジェクトに ActiveMQ を追加すると、さらに別の依存関係が追加されます。おそらく使用がより複雑になり、カスタム ソリューションよりもフットプリントが大きくなります。また、それを採用しているので、バグやその他すべてを維持し、スムーズに動作し続けることがあなたの責任になる可能性があります。
そうは言っても、ActiveMQ (およびその他のキュー) は、自分で記述できることを実行しますが、面倒であることが判明する可能性があります。JMS API 全体をサポートすることもその 1 つです (ただし、Java を使用していると仮定していますが、Java を使用していない場合、この点は無効です)。メモリが多い状況で余分なメッセージをディスクにシリアライズすることも別の方法です。永続的なサブスクライバーとメッセージ セレクターは、頭に浮かぶ他のいくつかのものです。ほとんどの場合、必要に応じてさまざまな機能を備えているように見えますが、メッセージを確実に配信するためには、これらの機能が非常に重要になります。
何を決定するにしても、メッセージ ブローカーの最終的な選択をカプセル化して、クライアント コードから切り離し、切り替えを容易にします。
管理性と拡張性が優先度の高いものではない場合、管理しやすいメッセージ キューを使用したい理由は何でしょうか? おそらくあなたの同僚は正しく、追加の機能セットは本当に必要ないのでしょうか?
奇妙なエッジケースで同時実行コードをデバッグする必要がないことは、大きな利点です。プロジェクト全体の一部としてこの構造がどれほど重要かはわかりませんが、メッセージ キューがプロジェクトの大部分を占める場合は、他の誰かが作成し、既にデバッグしている実装を使用することで、多大な利益を得ることができます。あなたのために維持します。それが重要でないサブシステムの 1 回限りの部分である場合、最終的に何をするかはおそらく問題ではありません。しかし、それが重大な場合は、同時実行コードのデバッグに時間を費やすよりも、むしろバグ レポートを提出した方がよいでしょう (私はすでに恐怖で後ずさりし始めています!)。
簡単に言うと、NIH 症候群のせいで、他人の仕事を利用して自分の仕事をより速く、より良く、より安く終わらせるのをやめさせないでください。しかし、モグラ塚から山を作ってはいけません。