Redis を使用しました 、NGINX＆PHP-私のチャットプロジェクトのFPM。あまりエレガントではありませんが、それでうまくいきます。パズルにはいくつかのピースがあります。
-
クライアントコマンドを受け取り、それらを1つの大きなリストに入れる非常に単純なPHPスクリプトがあります。また、すべてのルームリストとユーザーのプライベートリストをチェックして、配信する必要のあるメッセージがあるかどうかを確認します。これはjQueryで記述されたクライアントによってポーリングされ、数秒ごとに実行されます。
-
サーバー側を1秒間に20回、無限ループで操作するコマンドラインPHPスクリプトがあります。このスクリプトは、このリストをチェックしてから、これらのコマンドを処理します。スクリプトは、誰がどの部屋にいて、スクリプトメモリの権限を処理します。この情報はRedisに保存されません。
-
Redisには、各部屋のリストと、プライベートキューとして動作する各ユーザーのリストがあります。また、ユーザーがいる部屋ごとに複数のカウンターがあります。ユーザーカウンターが部屋のメッセージの総数より少ない場合は、差を取得してユーザーに送信します。
私はこのソリューションのストレステストを行うことができませんでしたが、少なくとも私の基本的なベンチマークからは、おそらく1秒あたり数千のメッセージを処理できるでしょう。これをNode.jsのようなものに移植して、パフォーマンスを向上させる機会もあります。 Redisも成熟しており、Pub / Subscribeコマンドなどの興味深い機能がいくつかあります。これらの機能は、サーバー側のポーリングを削除する可能性があります。
私はCometベースのソリューションを調べましたが、それらの多くは複雑で、文書化が不十分であるか、まったく新しい言語（Jetty-> Java、APE-> Cなど）を学ぶ必要があります...コメットの問題になります。だから私は投票にこだわっています。
MongoDBでも同様のことができると思います。部屋ごとのコレクション、ユーザーごとのコレクション、そしてカウンターを維持するコレクション。これらのメッセージの送信先の管理を処理するには、バックエンドデーモンまたはスクリプトを作成する必要があります。 MongoDBの「限定コレクション」を使用することもできます。これにより、ドキュメントが並べ替えられ、古いメッセージが自動的に消去されますが、適切なカウンターを維持するには複雑になる可能性があります。