如何在 Web 应用程序中使用 ServiceStack Redis 以利用 pub/sub 范式

Question

我对 Pub/Sub 范式很感兴趣，以便提供 通知系统（即：如 Facebook），尤其是在具有发布者的网络应用程序中（在同一 Web 服务器 IIS 上的多个 Web 应用程序）和一个或多个订阅者，负责在 Web 上显示前端用户的通知。

我发现了 Redis，它似乎是一个很棒的服务器，它提供了有趣的功能：缓存（如 Memcached）、Pub/Sub、队列。

不幸的是，除了 WebSockets 和 NodeJS，我没有在 Web 上下文（ASP.NET，使用 Ajax/jQuery）中找到任何示例，但我不想使用这些示例（为时过早）。我想我需要一个进程（订阅者）来接收来自发布者的消息，但我不知道如何在 Web 应用程序中执行此操作（pub/sub 与单元测试配合得很好）。

编辑：我们目前使用 .NET (ASP.NET Forms) 并试用 ServiceStack.Redis 库 (http://www.servicestack.net/)

Answer 1

Redis 发布/订阅不是为这种情况而设计的 - 它需要与 Redis 的持久连接，如果您正在编写工作进程，则可以使用此连接，但在处理无状态 Web 请求时则不需要。

通过 http 为最终用户工作的发布/订阅系统需要更多的工作，但不会太多 - 最简单的方法是为每个频道使用排序集并记录用户上次收到通知的时间。您还可以使用列表记录每个频道的订阅者，并在添加通知时写入每个用户的收件箱列表。

使用其中任何一种方法，用户都可以非常快速地检索他们的新通知。这将是一种轮询形式，而不是真正的推送通知，但由于 http 的性质，您不会真正摆脱它。

从技术上讲，您可以将 redis pub/sub 与长期运行的 http 连接一起使用，但如果每个用户都需要自己的线程来使用活动的 redis 和 http 连接，那么可伸缩性就不会很好。

Answer 2

实际上，Redis Pub/Sub 很好地处理了这种情况，因为 Redis 是一个异步非阻塞服务器，它可以廉价地容纳许多连接并且它可以很好地扩展。

Salvatore（又名 Redis 先生：）describes the O(1) time complexity of Publish and Subscribe operations：

你可以考虑 订阅/取消订阅 恒定时间操作，O(1) 对于两者 订阅和取消订阅 （实际上 PSUBSCRIBE 做了更多的工作 如果您订阅了，则比这 已经有很多模式了 同一个客户端）。

...

关于内存，类似或更小 比钥匙使用的那个，所以你 订阅应该没有问题 数以百万计的频道，即使在一个 小型服务器。

因此，Redis 的功能不止于此，而且专为这种情况而设计，但正如 Tom 指出的那样，为了保持持久连接，用户需要长时间运行的连接（又名 http-push / long-poll）和每个活跃用户将采取自己的线程。持有一个线程对于可扩展性来说并不是很好，从技术上讲，你最好使用像 Manos de Mono 或 node.js 这样的非阻塞 http 服务器，它们既是异步的又是非阻塞的，并且可以处理这种情况。注意：WebSockets 对于通过 HTTP 的实时通知更有效，因此理想情况下，如果用户浏览器支持它，您可以使用它，如果不支持它，则回退到常规 HTTP (or fallback to use Flash for WebSockets on the client)。

因此，不是 Redis 或其 Pub/Sub 无法在此处扩展，而是限制了 IIS 或 Apache 等线程 HTTP 服务器的并发连接数，也就是说您仍然可以支持相当数量使用 IIS (this post suggests 3000) 的并发用户数，由于 IIS 是瓶颈而不是 Redis，您可以轻松地添加额外的 IIS 服务器并分配负载。

Answer 3

对于这个应用程序，我强烈建议使用SignalR，这是一个.Net 框架，可以实时推送到连接的客户端。