あなたが説明しているユースケースは非常に狭いです。これは「ソケットまたはキュー」だけのケースではありませんが、他の考慮事項をビジネス ケースに織り込む必要があります。
- 物事はどのように監視および管理されますか? システムの状態を NOC に報告し、メッセージの統計情報を提供するすべての部分を作成する必要がありますか? それとも、MQ が提供するものを使用できますか?
- キューイングが必要ですか、それとも本当に同期アプリですか?
- これは本当にポイント ツー ポイントなのか、それとも関連するアプリがサービスのエコシステムとアップストリーム/ダウンストリーム接続に参加しているのか? 他に何と統合する必要がありますか?
- メッセージのエンリッチメント、ルーティング、ファンイン、ファンアウト、pub/sub、またはその他の機能が必要ですか? コードを書くか、WMQ/WMQ Broker のネイティブ機能を使用しますか?
- 接続には認証が必要ですか? 暗号化？コードを書くか、WMQ ネイティブ機能を使用しますか?
- 関連する規制順守要因はありますか? もしそうなら、カスタム コードと COTS トランスポートの監査コストはいくらですか?
- ショップには C++ の深いスキルがあり、コードの存続期間中その深さのベンチを維持する準備ができていますか?
- 接続構成はどのように管理され、HA と DR をシームレスにサポートしますか? コードを書くか、WMQ ネイティブ機能を使用しますか?
- 例外ロジックと自動再接続はどのように管理されますか? コードを書くか、WMQ ネイティブ機能を使用しますか?
ビジネス ケースでは、生の速度以上のことを考慮する必要があります。これは、両方の代替手段がスループット要件を満たすことができる場合に特に当てはまります。機能要件が満たされたら、ビジネス ケースで考慮しなければならないのは、これらすべての他の側面 (および、頭の中で考えていなかったその他の側面) です。
具体的な質問については...
キューへのアクセスは、希望どおりに管理されます。複数のスレッドが同じメッセージを求めて競合しますが、あるスレッドに配信されたメッセージは別のスレッドには配信されません。例外は、メッセージがロールバックされて再び利用可能になった場合、またはアプリが pub/sub を使用してメッセージの複数のコピーを意図的に受信した場合です。
アプリ側では、呼び出しはセッション内でスレッド セーフです。したがって、すべてのスレッドが同じセッションCOMMITを一緒に使用します。通常、リクエスト/リプライを使用するスレッドのペアが協調して動作します。それ以外の場合は、スレッドごとに 1 つのセッションで必要なものが得られます。
パフォーマンスに関しては、これはリンゴとオレンジの比較です。問題は、非同期メッセージング トランスポートのすべてのサービス、診断、回復力、およびその他の機能を提供する C++ ソケット プログラムが、そのトランスポートと同等に機能するかどうかです。答えは通常ノーです。WMQ は、1 つのことを非常にうまく行うために 20 年間最適化されてきました。新しいカスタム C++ ソケット プログラムはデータをより高速に移動しますが、同じ機能は提供しません。したがって、最終的には、アプリが WMQ の機能をほとんど必要としないため、必要ないくつかの機能をカスタム コードでコーディングし、それをアプリの存続期間にわたって維持する方が長期的に安価になるかどうかにかかっています。繰り返しますが、答えは通常ノーです。
メッセージ スループット レートの詳細については、SupportPacsページに移動し、必要なプラットフォームとバージョンの MP__ で始まる名前のものを探してください。小さなメッセージで 10k MPS を達成することは、控えめなハードウェアでも可能です。