El mantenimiento de una suscripción Redis PubSub abierto con Booksleeve

Question

estoy usando un canal pubsub Redis para enviar mensajes de un conjunto de procesos de trabajo a mi aplicación ASP.NET. Cuando se recibe un mensaje, mi aplicación reenvía el mensaje al navegador del cliente con SignalR.

Encontré this solution para mantener una conexión abierta a Redis, pero no tiene en cuenta las suscripciones cuando recrea la conexión.

Actualmente estoy manejo de mensajes PubSub Redis en mi archivo Global.asax:

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 */ 
    } 
} 

El problema se produce cuando el RedisConnection actual se cierra por cualquier razón. La solución más simple sería desencadenar un evento de la clase RedisConnectionGateway cuando la conexión se ha restablecido y volver a suscribirse utilizando un nuevo RedisSubscriberChannel. Sin embargo, se perderán todos los mensajes publicados en el canal mientras se restablece la conexión.

¿Hay ejemplos de formas recomendadas para manejar esta situación?

Answer 1

Sí, si la conexión muere (inestabilidad de la red, re-masterización, lo que sea), entonces tendrá que volver a aplicar cualquier suscripción que haya realizado. Un evento para reconectar y volver a suscribir es bastante normal, y no muy diferente de lo que usamos aquí en SE/SO (excepto que normalmente rastreamos suscripciones más granulares, y tenemos un código de envoltura que maneja todo eso).

Sí, eventos publicados, mientras que su conexión se interrumpió han desaparecido. Esa es la naturaleza de redis pub/sub; no garantiza la entrega a clientes desconectados. O bien utilizar una herramienta que hace promesa de esto, o Redis uso para conducir una cola en lugar - empujar/apareciendo a/desde los extremos opuestos de una lista suele ser una alternativa razonable, y asegura que nada se pierde (siempre y cuando su software doesn' t soltarlo después de sacarlo de la lista). Si ayuda, tengo en mi lista una solicitud para agregar los métodos pop de bloqueo: destruyen totalmente la intención del multiplexor, pero tienen un uso genuino en algunos casos, así que no estoy en contra de agregarlos.