使用Booksleeve维护打开的Redis PubSub订阅

Question

我使用Redis pubsub通道将消息从工作进程池发送到我的ASP.NET应用程序。当收到消息时，我的应用程序使用SignalR将消息转发到客户端浏览器。

我发现this solution用来维护到Redis的开放连接，但当它重新创建连接时，它不会考虑订阅。

我目前在我的Global.asax文件中处理Redis pubsub消息：

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重新订阅。但是，在重置连接时发布到通道的任何消息都将丢失。

有没有推荐的处理这种情况的方法的例子？

Answer 1

是的，如果连接中断(网络不稳定、重新主控等)，那么您将需要重新应用您所做的任何订阅。重新连接和重新订阅事件是很正常的，与我们在SE/SO上使用的没有太大区别(除了我们通常跟踪更细粒度的订阅，并有一些包装器代码来处理所有这些)。

是的，在您的连接中断时发布的任何事件都将消失。这就是redis pub/sub的本质；它不保证交付到断开连接的客户端。或者使用一个支持这一点的工具，或者使用redis来驱动一个队列--推送/弹出列表的两端通常是一个合理的选择，并且确保不会丢失任何东西(只要你的软件在将它从列表中弹出后不会丢弃它)。如果有帮助，我的列表中有一个添加阻塞pop方法的请求-它们完全破坏了多路复用器的意图，但在某些情况下它们有真正的用途，所以我不反对添加它们。