0

現在取り組んでいる Web アプリケーションにリアルタイム通知を統合することを計画しています。これには XMPP を使用することに決め、自分のニーズに適していると思われる Openfire サーバーを選択しました。

フロント エンドは strophe ライブラリを使用して、私の openfire サーバーから BOSH を使用して通知をフェッチします。ただし、通知は通知であり、他のメッセージはアプリケーションによって投稿されるため、このコードはバックエンドに存在する必要があると思います。最初は、XMPHP や JAXL などの PHP XMPP ライブラリを使用することを考えていましたが、各スクリプトが接続、認証などの同じ手順を実行する必要があるため、これにより多くのオーバーヘッドが発生し、PHP の終了が少し遅くなると思います。そして無反応。

現在、PHP が呼び出す Web サービスとして機能するミドルウェア アプリケーションを作成することを考えています。このアプリケーションは、XMPP サービスを処理します。これの利点は、このアプリ (場合によってはサーバー) が 1 回だけ接続する必要があり、そこに座ってポートをリッスンすることです。また、最初にPHPアプリからすべてのリクエストを受け取り、次にリクエストがなくなったときに非同期でビルドすることを計画しています。通知の公開作業に取り掛かります。SleekXMPP を使用して Python でこのサービスを作成する予定です。

これはまさに私が計画したことです。私は XMPP を初めて使用しますが、この Web サービス全体について、メモリや CPU の使用率、利点、欠点、スケーラビリティの問題、セキュリティなどの問題に関するコメントをお待ちしています。

前もって感謝します。

PS:-- また、このようなものが既に存在する場合 (Google で何度も検索しても見つかりませんでしたが)、そこに誘導してください。

編集 --- 中間レベルのサービスは次のことを行う必要があります (ただし、これに限定されません): 1. さまざまなレベルのグループおよびコミュニティ ページの通知を発行します。2. あるイベントでの単一ユーザーへの通知。3. ユーザー登録 (ただし、ユーザー サービス プラグインを使用して行うことができます)。

編集 --- また、pub-sub ノードを作成し、これらの pub-sub ノードからユーザーをサブスクライブおよびサブスクライブ解除する必要があります。

また、通知とメッセージをデータベースに保存したいと思います(openfireはそうではありません)。それは良い選択でしょうか?

4

1 に答える 1

0

通信が一方向であり、通知を送信しているだけであることを考えると、XMPPは、実行していることに対して少し重いソリューションであるように思えます(リアルタイムのマルチユーザーチャットなどはありません)。

サーバー<=>クライアントチャネルにはSocket.io(http://socket.io)のようなものを使用し、永続性にはRedis(http://redis.io)を使用することを検討します。

于 2012-12-10T08:07:50.617 に答える