github でコードを読む以外に、SignalR.Redis パッケージの仕組みに関するホワイト ペーパー タイプのドキュメントはありますか? 具体的には、Redis に追加するキー、更新/削除戦略などについて疑問に思っています。Redis の内部を見ると、次の呼び出しで指定された 1 つのキー (つまり、「SignalR.Redis.Sample」) だけが表示されます。
GlobalHost.DependencyResolver.UseRedis(server, Int32.Parse(port), password, "SignalR.Redis.Sample");
このキーは、Redis のカウンターのようです。Redis に接続された各アプリ サーバー間のメッセージを容易にするために、他のキーが作成され、すぐに削除されていると思います。
いいえ、ホワイトペーパーはありません。コードは 200 行程度なので、それほど多くは飲み込めません。
SignalR では、各メッセージはメッセージ バスと呼ばれるものを通過します。ノード (またはプロセスまたはアプリ ドメイン) 間でスケールアウトする場合、このバスの実装は、アプリケーションの各インスタンスと通信できる必要があります。これを行うには、RedisMessageBus を使用できます。Redis にはpub subメカニズムと、キーと値のペアを格納する機能があり、SignalR には前者のみを使用します。
OffTopic: これは非常に重要です。SignalR は信頼できるメッセージングではなく、接続の抽象化です。longpolling のためにメッセージをバッファリングすることはできますが、メッセージが永久に存在することに依存することは**できません*。保持する必要がある重要なメッセージがある場合は、それらを保持します。
各 Web サーバーは 1 つ (または新しい実装では複数) の redis イベントに接続して、それらの間でメッセージを送信します。1 つ以上のクライアントにメッセージが届くと、メッセージはバックプレーン (redis) に送信され、すべての Web サーバーに到着します。各 Web サーバーは、redis からメッセージを取得し、ローカル キャッシュに保存します。このローカル キャッシュは、SignalR クライアント (ブラウザーなど) が提供される場所です。
スケールアウト設計の重要な部分の 1 つはカーソルです。カーソルは、メッセージの無限ストリーム内で特定のクライアントがどこにいるかを表します。クライアントが接続をドロップした後に再接続するか、メッセージを取得した後にロングポーリング接続が戻ってくると、カーソル値以降のすべてを取得するようにバスに要求します。カーソルはメッセージ バスの実装によって定義され、最新のソースでこれを正規化しました (執筆時点ではまだリリースされていませんが、ここでは詳しく説明しません)。redis の現在の実装におけるカーソルは、インクリメントされる単なる数値であり、それほど複雑ではありません。
うまくいけば、それがどのように機能するかについてのアイデアが得られます。