6.5.1 单接收者发布/订阅替代方案

我们在 Redis 中发现的一个常见模式是，我们拥有各种类型的客户端（服务器进程、聊天用户等），它们在其自己的通道上监听或等待消息。 它们是唯一接收这些消息的人。 许多程序员最终会使用 Redis 的 PUBLISH 和 SUBSCRIBE 命令来分别发送消息和等待消息。 但是，如果我们需要接收消息，即使面对连接问题，PUBLISH 和 SUBSCRIBE 也帮不了我们太多。

Fake Garage Startup 脱离我们的游戏公司重点，希望发布一款移动消息应用程序。 此应用程序将连接到他们的 Web 服务器以发送和接收类似 SMS/MMS 的消息（基本上是文本或图片消息传递的替代方案）。 Web 服务器将处理身份验证和与 Redis 后端的通信，而 Redis 将处理消息路由/存储。

每条消息只会由单个客户端接收，这大大简化了我们的问题。 为了以这种方式处理消息，我们为每个移动客户端使用一个 LIST。 发送者导致消息被放置在接收者的 LIST 中，并且每当接收者的客户端发出请求时，它都会获取最新的消息。 借助 HTTP 1.1 的流水线请求能力，或者借助更现代的 Web 套接字支持，我们的移动客户端可以发出所有等待消息的请求（如果有的话），可以一次发出一个请求，或者可以获取 10 个项目并使用 LTRIM 删除前 10 个项目。

因为您已经知道如何从列表中推送和弹出项目（来自前面的章节，最近来自 6.4.1 节的先进先出队列），我们将跳过包含发送消息的代码，但是图 6.11 中说明了用户 jack451 的示例传入消息队列。

使用 LIST，如果接收者最近没有连接、没有收到他们之前的消息或者可能存在太多待处理消息，发送者也可以收到通知；所有这些都可以通过检查接收者的 LIST 中的消息来完成。 如果系统受到需要接收者始终连接的限制，就像使用 PUBLISH/SUBSCRIBE 一样，消息将会丢失，客户端将不知道他们的消息是否已发送，并且速度慢的客户端可能会导致传出缓冲区无限增长（在旧版本的 Redis 中）或断开连接（在较新版本的 Redis 中）。

在解决了单接收者消息传递问题后，现在是时候讨论当我们希望给定通道有多个侦听器时如何替换 PUBLISH 和 SUBSCRIBE。