2

ゲームシステムにコールバック機能を提供するためにソケットに依存するシステムがあります。フェイルオーバーとスケーラビリティーのために、あるユーザーをあるソケットに接続し、同じチームの別のユーザーを別のソケットに接続することができます。

コントロール メッセージが届いたら、メッセージに応答するために必要なソケットの数を確認する必要があります。つまり、すべてのチーム メンバーが 1 つのソケットにいる場合、メッセージをチーム メンバーにプッシュする必要があるのは 1 つのソケットだけです。逆に、チーム メンバーが複数のソケット間で「負荷分散」されている場合、問題のソケットは、それぞれ接続されているメンバーにメッセージをプッシュする必要があります。

現在、ソケット ID (GUID) とソケットに接続されているメンバーを含むカスタム DB テーブルを照会するポーリング システムを使用しています。これはメッセージ自体に結合されるため、各ソケットがメッセージを処理することが保証されます。

大きな問題は、私は投票が嫌いだということです!

大きな問題は、これを最も効率的に達成するために、どのテクノロジを調査すればよいかということです。SQL Server の依存関係を調べましたが、これはクエリが満たされるまで DB 接続を開いたままにしているようです。

私も MSMQ を楽しみましたが、それは 1 つの「サブスクライバー」のみを許可するようで、複数の関心のあるソケットを除外します。

オープンソースの ESB についてはよくわかりません。ESB の前提は理解できますが、あるソケットがメッセージを処理し、別のソケットがまだメッセージを正常に処理していないことを示すにはどうすればよいですか。

次に、Message Brokering システム全体があります。私には不気味なまでに低レベルの ESB のように聞こえます。

エンタープライズ アーキテクトの皆さんに、この問題を解決するための支援をお願いします。

敬具

4

0 に答える 0