7

通知システム（つまり、Facebookなど）を提供するためのPub / Subパラダイムに興味があります。特に、パブリッシャー（同じWebサーバーIIS上の複数のWebアプリケーション）と1つ以上のサブスクライバーを持つWebアプリケーションに興味があります。フロントユーザーへの通知をWeb上に表示するために課金します。

Redisを見つけました。これは、キャッシュ（Memcachedなど）、Pub / Sub、キューなどの興味深い機能を提供する優れたサーバーのようです。

残念ながら、Webコンテキスト（ASP.NET、Ajax / jQueryを使用）では、WebSocketとNodeJSを除いて例は見つかりませんでしたが、これらを使用したくありません（早すぎます）。パブリッシャーからメッセージを受信するプロセス（サブスクライバー）が必要だと思いますが、Webアプリケーションでそれを行う方法がわかりません（pub / subは単体テストで正常に機能します）。

編集：現在、.NET（ASP.NETフォーム）を使用して、ServiceStack.Redisライブラリ（http://www.servicestack.net/）を試してみます

4

3 に答える 3

5

このアプリケーションでは、接続されたクライアントへのリアルタイム プッシュを可能にする .Net フレームワークであるSignalRを使用することを強くお勧めします。

于 2013-01-22T19:43:15.327 に答える
5

実際、Redis Pub/Sub はこのシナリオを非常にうまく処理します。Redis は非同期のノンブロッキング サーバーであるため、安価に多くの接続を保持でき、適切に拡張できます。

Salvatore (別名 Mr Redis :)は、Publish および Subscribe 操作の O(1) 時間の複雑さについて説明しています。

サブスクライブ/サブスクライブ解除の作業は、一定時間の操作、つまり、サブスクライブとアンサブスクライブの両方で O(1) と考えることができます (実際、 同じクライアントで既に多くのパターンにサブスクライブしている場合、PSUBSCRIBE はこれよりも多くの作業を行います)。

...

メモリについては、キーで使用されるものと同じかそれよりも小さいため、小さなサーバーでも数百万のチャネルを購読するのに問題はありません。

そのため、Redis はこのシナリオ向けに十分に機能し、設計されていますが、永続的な接続を維持するために Tom が指摘した問題は、ユーザーが長時間実行される接続 (別名 http-push / long-poll) を必要とし、アクティブな各ユーザーがその自分のスレッド。スレッドを保持することはスケーラビリティには適していません。技術的には、Manos de Monoやnode.jsなどの非ブロック HTTP サーバーを使用することをお勧めします。これらは非同期で非ブロックであり、このシナリオを処理できます。注: HTTP 経由のリアルタイム通知には WebSockets の方が効率的であるため、理想的には、ユーザーのブラウザーがサポートしている場合はそれを使用し、サポートしていない場合は通常の HTTP にフォールバックします (または、クライアントで WebSockets に Flash を使用するようにフォールバックします)。

したがって、ここでスケーリングしないのは Redis やその Pub/Sub ではなく、IIS や Apache などのスレッド化された HTTP サーバーが制限する同時接続の数であり、それでもかなりの数の同時ユーザーをサポートできると言われています。 IIS (この投稿は 3000 を示唆しています) を使用し、Redis ではなく IIS がボトルネックであるため、追加の IIS サーバーをミックスに簡単に追加して負荷を分散できます。

于 2011-06-22T15:30:17.597 に答える
3

Redis のパブリッシュ/サブスクライブは、このシナリオ用に設計されていません。redis への永続的な接続が必要です。これは、ワーカー プロセスを作成している場合は必要ですが、ステートレス Web リクエストを操作している場合はそうではありません。

http を介してエンド ユーザーに対して機能するパブリッシュ/サブスクライブ システムは、もう少し手間がかかりますが、それほど多くはありません。最も簡単な方法は、チャネルごとに並べ替えられたセットを使用し、ユーザーが最後に通知を受け取った時刻を記録することです。また、各チャネルのサブスクライバーを記録するリストを使用して、通知が追加されるたびにそれらの各ユーザーの受信トレイ リストに書き込むこともできます。

これらの方法のいずれかを使用すると、ユーザーは新しい通知を非常に迅速に取得できます。これは真のプッシュ通知ではなくポーリングの形式になりますが、http の性質上、それを回避することはできません。

技術的には、実行時間の長い http 接続で redis pub/sub を使用できますが、すべてのユーザーがアクティブな redis と http 接続で独自のスレッドを必要とする場合、スケーラビリティはあまり良くありません。

于 2011-06-22T11:27:25.380 に答える