whats app やメッセンジャーのようなモジュールを設計する必要があります。
ハイレベルフロー
Client > Load Balancer > Web servers(assume 10 clustered server for now) > Rest based controller > Service > DAO > DB
チャレンジ ：-
フレンド 1 とフレンド 2 がオンラインであるとします。友人 1 は Web サーバー 1 への HTTP Web 接続を確立し、友人 2 は Web サーバー 2 への HTTP Web 接続を確立しました。友人 1 はメッセージを友人 2 に送信します。
メッセージが Web サーバー 1 に届くとすぐに、メッセージを Web サーバー 2 に伝達して、既に確立されている Web 接続を介してメッセージを友人 2 にプッシュバックできるようにする必要があります。
ここに関連する質問がいくつかあります:-
- 分散キューを使用 して、あるサーバーから別のサーバーにメッセージを伝達できます。メッセージが 1 つのサーバーに到達するとすぐに、メッセージ コンテンツ fromUserId、toUserId とともに分散キュー (負荷分散と高可用性のために分散キュー) にプッシュされます。私の質問は、適切なサーバー (この場合は Web サーバー 2) にどのように通知されますか? JMSキューを使用すると、リスナーを介して1つのサーバーのみに通知されるためです。トピックを使用すると、すべてのサーバーに通知されます。この場合、fromUserId が存在する 1 つのサーバーを除くすべてのサーバーがメッセージを拒否できます。キューがメタデータに基づいて適切なサーバーに通知するより良い方法はありますか?
また、destinationUserId がオフラインの場合は、メッセージをキューに戻す必要があります。どうすれば達成できるかわからない？JMSキュー/トピックの代わりに、他のキュー実装(おそらくJavaベースのメモリ内キュー)を使用する必要があると思いますか? サーバーコードは、クライアントから確認を取得した後、カスタムキューからメッセージを削除するだけです.
メッセージが送信された時点でいずれかのクライアントがオフラインである場合、そのクライアントがオンラインになると、彼はプル リクエストを送信します。サーバーは分散キューにリクエストを送信し、分散キューは適切な物理キューからメッセージをプルします。私の質問は、分散キューが宛先ユーザー ID とメッセージをメタデータの値として保持する必要がありますか?
DB vs Queue :-このアプローチでは、メッセンジャーのような非常にリアルタイムのアプリケーションでキュー(メモリ内キュー)よりもコストがかかる(時間の複雑さ)可能性があるメッセージをDBに格納する必要はないと考えています。ユーザー/グループの詳細を db に保存するだけです。
更新 :- quoraで関連リンクを見つけました。最後のポイントWhat protocol is used in Whatsapp app ?...、つまり Kah Seng Tay も queue を使用した simialr アプローチを確認していますが、キューに関する上記の質問にはまだ回答がありません。