7

Redis pubsubチャネルを使用して、ワーカープロセスのプールからASP.NETアプリケーションにメッセージを送信しています。メッセージを受信すると、アプリケーションはそのメッセージをSignalRを使用してクライアントのブラウザーに転送します。

Redisへのオープン接続を維持するためのこのソリューションを見つけましたが、接続を再作成するときにサブスクリプションは考慮されません。

現在、Global.asaxファイルでRedispubsubメッセージを処理しています。

public class Application : HttpApplication
{
    protected void Application_Start()
    {
        var gateway = Resolve<RedisConnectionGateway>();
        var connection = gateway.GetConnection();
        var channel = connection.GetOpenSubscriberChannel();

        channel.PatternSubscribe("workers:job-done:*", OnExecutionCompleted);
    }

    /// <summary>
    /// Handle messages received from workers through Redis.</summary>
    private static void OnExecutionCompleted(string key, byte[] message)
    {
        /* forwarded the response to the client that requested it */
    }
}

この問題は、現在のRedisConnectionが何らかの理由で閉じられたときに発生します。RedisConnectionGateway問題の最も簡単な解決策は、接続がリセットされたときにクラスからイベントを発生させ、新しいを使用して再サブスクライブすることRedisSubscriberChannelです。ただし、接続のリセット中にチャネルに公開されたメッセージはすべて失われます。

この状況を処理するための推奨される方法の例はありますか？

4

1 に答える 1

8

はい、接続が切断された場合（ネットワークの不安定性、リマスタリングなど）、作成したサブスクリプションを再適用する必要があります。再接続して再サブスクライブするイベントはごく普通のことであり、ここでSE / SOで使用するイベントと大差ありません（通常、より詳細なサブスクリプションを追跡し、それらすべてを処理するラッパーコードがある場合を除きます）。

はい、接続が切断されている間に公開されたイベントはすべて失われます。これがredispub/subの性質です。切断されたクライアントへの配信を保証するものではありません。これを約束するツールを使用するか、代わりにredisを使用してキューを駆動します-リストの両端にプッシュ/ポップすることは通常合理的な代替手段であり、（ソフトウェアがドロップしない限り）何も失われないようにしますリストからポップした後）。それが役に立ったら、ブロッキングポップメソッドを追加するリクエストがリストにあります-それらはマルチプレクサの意図を完全に破壊しますが、場合によっては本物の用途があるので、それらを追加することに反対していません。

于 2012-04-10T13:08:13.777 に答える