サーバー間通信用の (Java) インターフェースを設計する必要がありますが、この分野での経験はまったくありません。
私のサーバーは、さまざまなソースから情報を取得します。他のサーバーは、サーバーに接続して現在の情報を取得し、プッシュ通知を介して変更を受信できる必要があります。インターフェイスは、他のサーバーの特定のプログラミング言語やオペレーティング システムに依存しないようにする必要があります。私が最初に考えたのは、ソケットを使用し、ソケットを開いたままにして変更を送信することでした。これにもっと良い方法はありますか？
クライアントにデータをプッシュできるようにする必要があるため、これは明らかにソケットで可能ですが、他の複雑さが導入されるため、最も簡単な解決策はメッセージキューを使用することです。
メッセージ キューを使用するには、クライアントは、サーバーがリッスンしている既知のキューにメッセージを送信します。このメッセージにはreplyTo宛先 (通常は、クライアントが所有する一時キュー) が含まれている必要があります。メッセージを受信すると、サーバーは宛先を登録し、replyToこの宛先に通知を送信する必要がありreplyToます。
クライアントがデータを取得するために 2 つのメカニズムをサポートする必要がなくなるため、通常、すべてのデータ (初期ロードと更新の両方) に対して通知メカニズムを使用する方が簡単であることがわかりました。通知メッセージは発生しているイベントのタイプ (追加、更新、削除など) を示す必要があり、このリストに初期化タイプを導入するだけでよいため、これは非常に簡単です。
リアルタイム データで優れたパフォーマンスが必要な場合は、パブリッシュ/サブスクライブをサポートし、すべての主要言語に対応する多くのクライアントを備えたオールインメモリの nosql データベースである redis を検討できます。
パブリッシング サーバーはイベントをリッスンし、たとえば jedis (Java 用の redis クライアント) のおかげでデータを redis にプッシュします。その後、redis のパブリッシュ/サブスクライブ サポートのおかげで、redis チャネルにサブスクライブしている他のサーバーは更新を取得します。基本的に、redis をメッセージ ブローカーとして使用すると、うまく機能します。読み取りにインテリジェンスを追加したくない場合は、間違いなく redis が適しています。
ただし、Linux サーバーにデプロイする必要があります (実稼働用の Windows はありませんが、開発用に redis の Windows ポートを使用できます)。
Redis は複雑さを追加しますが、多くの優れた機能も備えており (zsets はデータのランキングをストックするのに最適です)、すべてがメモリ内にあるため (サーバーに十分な RAM があるかどうかを確認する必要があります)、パフォーマンスは非常に優れています。