我对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/)
实际上 Redis Pub/Sub 很好地处理了这种情况，因为 Redis 是一个异步非阻塞服务器，它可以廉价地容纳许多连接并且它可以很好地扩展。
Salvatore（又名 Redis 先生 :)描述了发布和订阅操作的 O(1) 时间复杂度：
您可以将订阅/取消订阅的工作视为一个恒定的时间操作，订阅和取消订阅都是 O(1)（实际上，如果您已经使用 同一个客户端订阅了许多模式，PSUBSCRIBE 所做的工作比这更多）。
...
关于内存，它与密钥使用的内存相似或更小，因此即使在小型服务器中订阅数百万个频道也不会有问题。
因此，Redis 不仅有能力，而且专为这种情况而设计，但正如 Tom 指出的那样，为了保持持久连接，用户将需要长时间运行的连接（又名 http-push / long-poll），并且每个活跃用户都会使用它的自己的线程。持有一个线程对于可扩展性来说并不是很好，从技术上讲，你最好使用像Manos de Mono或node.js这样的非阻塞 http 服务器，它们既是异步的又是非阻塞的，并且可以处理这种情况。注意：WebSockets 对于通过 HTTP 的实时通知更有效，因此理想情况下，如果用户浏览器支持它，您将使用它，如果不支持它，则回退到常规 HTTP（或者回退到在客户端上使用 Flash 进行 WebSockets）。
因此，不是 Redis 或其 Pub/Sub 无法在此处扩展，而是限制了 IIS 或 Apache 等线程 HTTP 服务器的并发连接数，也就是说您仍然可以支持相当数量的并发用户使用 IIS（这篇文章建议 3000）并且由于 IIS 是瓶颈而不是 Redis，您可以轻松地将额外的 IIS 服务器添加到混合中并分配负载。
对于这个应用程序，我强烈建议使用SignalR，它是一个 .Net 框架，可以实时推送到连接的客户端。
Redis 发布/订阅不是为这种情况而设计的——它需要与 redis 的持久连接，如果你正在编写一个工作进程，但当你处理无状态 Web 请求时，你不需要。
通过 http 为最终用户工作的发布/订阅系统需要更多的工作，但不会太多 - 最简单的方法是为每个频道使用排序集并记录用户上次收到通知的时间。您还可以使用列表记录每个频道的订阅者，并在添加通知时写入每个用户的收件箱列表。
使用其中任何一种方法，用户都可以非常快速地检索他们的新通知。这将是一种轮询形式，而不是真正的推送通知，但由于 http 的性质，您不会真正摆脱这种情况。
从技术上讲，您可以将 redis pub/sub 与长时间运行的 http 连接一起使用，但如果每个用户都需要自己的线程来使用活动的 redis 和 http 连接，那么可伸缩性就不会很好。