一文读懂 Redis 发布订阅 – wiki基地

作者： /

一文读懂 Redis 发布订阅：实时通信与异步解耦的轻量级利器

在构建现代分布式系统时，服务间的通信和事件通知是不可或缺的组成部分。无论是实时数据更新、系统通知、聊天应用，还是简单的异步任务触发，高效可靠的消息传递机制都能极大地简化系统设计并提升响应速度。在众多消息传递模式中，“发布/订阅”（Publish/Subscribe，简称 Pub/Sub）因其解耦特性和广播能力而备受青睐。

Redis，作为一款高性能的内存键值存储系统，不仅仅是缓存和数据存储的利器，它还内置了一套简洁而高效的 Pub/Sub 功能。不同于传统重量级消息队列（如 Kafka、RabbitMQ），Redis 的 Pub/Sub 更侧重于低延迟、高吞吐的即时广播，适用于需要将消息快速发送给多个对等接收者的场景。

本文将带你深入剖析 Redis 的发布订阅机制，从基本概念到工作原理，从核心命令到进阶用法，再到其优缺点与适用场景，力求让你“一文读懂” Redis Pub/Sub 的精髓。

第一部分：发布订阅模式的通用概念

在深入 Redis 实现之前，我们先理解发布订阅这种消息模式本身。发布订阅模式是一种异步消息通信模式，它将消息的发送者（发布者）与接收者（订阅者）解耦。

  1. 发布者 (Publisher)： 负责创建消息并将其发送到一个特定的“频道”（Channel）。发布者并不知道有哪些订阅者，甚至不知道是否有订阅者。
  2. 订阅者 (Subscriber)： 对某些特定频道的消息感兴趣。订阅者向消息代理（Broker）注册对这些频道的兴趣（即“订阅”）。当有消息发布到其订阅的频道时，消息代理会将消息投递给该订阅者。订阅者并不知道消息是由哪个发布者发送的。
  3. 频道 (Channel)： 是消息的逻辑载体或主题。发布者将消息发送到频道，订阅者从频道接收消息。频道是发布者和订阅者之间的桥梁。

核心特点：

  • 解耦： 发布者和订阅者之间无需直接知道彼此的存在，它们只与频道交互。这使得系统组件可以独立地开发、部署和扩展。
  • 异步： 发布消息的操作不会阻塞发布者，发布者只需将消息交给代理即可继续执行。消息的投递由代理在后台完成。
  • 广播： 一条消息可以被发布到频道，然后由该频道的所有活跃订阅者接收。

这种模式非常适合一对多的通信场景。

第二部分：Redis 发布订阅的实现

Redis 内置的 Pub/Sub 功能遵循上述通用模式，但有其特定的实现细节。

基本工作流程：

  1. 订阅者客户端向 Redis 服务器发送 SUBSCRIBE 或 PSUBSCRIBE 命令，指明它想订阅哪些频道或频道模式。
  2. Redis 服务器记录下这个客户端的订阅信息。
  3. 发布者客户端向 Redis 服务器发送 PUBLISH 命令，将消息发送到指定频道。
  4. Redis 服务器接收到 PUBLISH 命令后，查找所有订阅了该频道（或匹配该频道模式）的客户端。
  5. Redis 服务器将消息推送给所有匹配的订阅者客户端。

关键在于： Redis 服务器充当了消息代理（Broker）的角色。所有消息的路由和投递都由 Redis 负责。

第三部分：Redis Pub/Sub 核心命令详解

Redis 提供了几个简单的命令来实现发布订阅功能：

  1. PUBLISH channel message
  2. SUBSCRIBE channel [channel ...]
  3. UNSUBSCRIBE [channel [channel ...]]
  4. PSUBSCRIBE pattern [pattern ...]
  5. PUNSUBSCRIBE [pattern [pattern ...]]

下面详细解释这些命令及其行为。

1. PUBLISH channel message

  • 功能： 将一条消息发布到指定的频道。
  • 参数：
    • channel: 频道名称（字符串）。
    • message: 要发布的消息内容（字符串）。
  • 返回值： 接收到消息的订阅者数量。如果没有任何订阅者，返回 0。
  • 示例：
    bash
    PUBLISH news:global "Hello world from Redis Pub/Sub!"
    如果当前有 3 个客户端订阅了 news:global 频道，该命令将返回 3。

注意： PUBLISH 命令是非阻塞的。无论是否有订阅者，命令都会立即执行并返回。

2. SUBSCRIBE channel [channel …]

  • 功能： 订阅一个或多个频道。
  • 参数： 一个或多个频道名称。
  • 返回值：
    • SUBSCRIBE 命令本身成功执行时，会返回一个状态回复，格式为 (integer) 3（数组回复），包含三个元素："subscribe", 客户端订阅的频道名称, 客户端当前已订阅的频道数量。
    • 之后，当有消息发布到这些频道时，客户端会接收到格式为 (integer) 3 的消息回复，包含三个元素："message", 接收到消息的频道名称, 消息内容。
  • 示例：
    bash
    # 客户端 A 订阅 news:global 和 alerts
    SUBSCRIBE news:global alerts
    客户端 A 执行此命令后，将进入阻塞状态，等待接收消息。它会首先收到确认订阅的回复：
    1) "subscribe"
    2) "news:global"
    3) (integer) 1
    1) "subscribe"
    2) "alerts"
    3) (integer) 2
    （数字 1 和 2 表示当前该客户端的总订阅频道数）。
    如果客户端 B 执行 PUBLISH news:global "Breaking news!"，客户端 A 将收到：
    1) "message"
    2) "news:global"
    3) "Breaking news!"

重要特性： SUBSCRIBE 命令会使客户端进入订阅模式。一旦进入订阅模式，客户端就不能再执行除 SUBSCRIBE, PSUBSCRIBE, UNSUBSCRIBE, PUNSUBSCRIBE, PING, QUIT 之外的任何命令。这个连接专用于接收 Pub/Sub 消息。如果需要执行其他 Redis 命令（如 GET, SET），需要使用一个新的客户端连接。这是 Redis Pub/Sub 实现中的一个关键点，也是许多初学者容易困惑的地方。

3. UNSUBSCRIBE [channel [channel …]]

  • 功能： 退订一个或多个指定的频道。如果没有指定频道，则退订当前客户端订阅的所有频道。
  • 参数： 可选，一个或多个频道名称。
  • 返回值：
    • 退订成功时，返回一个状态回复，格式为 (integer) 3（数组回复），包含三个元素："unsubscribe", 退订的频道名称, 客户端当前剩余订阅的频道数量。
    • 当客户端退订所有频道后（即剩余订阅数量变为 0），客户端将退出订阅模式，可以重新执行常规的 Redis 命令。
  • 示例：
    bash
    # 退订 alerts 频道
    UNSUBSCRIBE alerts
    客户端会收到：
    1) "unsubscribe"
    2) "alerts"
    3) (integer) 1
    如果客户端之前只订阅了 news:global 和 alerts，现在剩余订阅数量为 1（news:global）。
    bash
    # 退订所有频道
    UNSUBSCRIBE
    如果客户端只订阅了 news:global，执行此命令后，会收到：
    1) "unsubscribe"
    2) "news:global"
    3) (integer) 0
    客户端退出订阅模式。

4. PSUBSCRIBE pattern [pattern …]

  • 功能： 订阅一个或多个符合指定模式的频道。
  • 参数： 一个或多个频道模式。模式中可以使用通配符：
    • *: 匹配任意数量（包括零个）的任意字符。
    • ?: 匹配恰好一个任意字符。
    • []: 匹配括号内的任意一个字符（例如 [abc] 匹配 ‘a’, ‘b’, 或 ‘c’）。可以使用 - 表示范围（例如 [0-9] 匹配数字）。
  • 返回值：
    • PSUBSCRIBE 命令本身成功执行时，会返回一个状态回复，格式为 (integer) 3（数组回复），包含三个元素："psubscribe", 客户端订阅的模式, 客户端当前已订阅的模式数量。
    • 之后，当有消息发布到符合这些模式的频道时，客户端会接收到格式为 (integer) 4 的消息回复，包含四个元素："pmessage", 接收到消息的模式, 接收到消息的频道名称, 消息内容。
  • 示例：
    bash
    # 客户端 C 订阅所有以 "chat:" 开头的频道
    PSUBSCRIBE chat:*
    # 客户端 D 订阅所有以 "logs:" 开头，后面跟着至少一个字符的频道
    PSUBSCRIBE logs:?*
    客户端 C 订阅成功后收到：
    1) "psubscribe"
    2) "chat:*"
    3) (integer) 1
    如果客户端 E 执行 PUBLISH chat:room1 "Hi room1!"，客户端 C 将收到：
    1) "pmessage"
    2) "chat:*" # 匹配到的模式
    3) "chat:room1" # 实际收到消息的频道
    4) "Hi room1!" # 消息内容
    如果客户端 E 执行 PUBLISH game:updates "New score!"，客户端 C 不会收到，因为它不匹配 chat:*。

重要特性： 与 SUBSCRIBE 类似，PSUBSCRIBE 也会使客户端进入订阅模式，且同样只能执行少数几个 Pub/Sub 相关命令以及 PING, QUIT。

5. PUNSUBSCRIBE [pattern [pattern …]]

  • 功能： 退订一个或多个指定的模式。如果没有指定模式，则退订当前客户端订阅的所有模式。
  • 参数： 可选，一个或多个频道模式。
  • 返回值：
    • 退订成功时，返回一个状态回复，格式为 (integer) 3（数组回复），包含三个元素："punsubscribe", 退订的模式, 客户端当前剩余订阅的模式数量。
    • 当客户端退订所有模式后，且如果也没有订阅任何频道，客户端将退出订阅模式。
  • 示例：
    bash
    # 退订 chat:* 模式
    PUNSUBSCRIBE chat:*
    客户端收到：
    1) "punsubscribe"
    2) "chat:*"
    3) (integer) 0
    （假设这是唯一订阅的模式）。客户端可能会退出订阅模式（如果也没有通过 SUBSCRIBE 订阅频道）。

注意：
* 一个客户端可以同时通过 SUBSCRIBE 和 PSUBSCRIBE 订阅频道和模式。
* 如果一个消息发布到一个频道，同时匹配了某个客户端通过 SUBSCRIBE 订阅的频道以及通过 PSUBSCRIBE 订阅的模式，该客户端会收到两条消息：一条是 "message" 类型的，一条是 "pmessage" 类型的。

第四部分：Redis Pub/Sub 的使用场景

Redis Pub/Sub 因其简洁和高性能，在以下场景中非常适用：

  1. 实时数据广播： 例如股票行情、体育比分、天气预报等，需要将更新的数据即时推送给所有关心这些数据的客户端。
  2. 系统通知与公告： 后台系统发布一条全局通知，所有在线用户端或相关的服务都能立即收到。
  3. 简单聊天室： 构建一个简单的多人聊天室，用户加入一个频道（房间），发送消息（发布到频道），接收消息（订阅频道）。
  4. 跨应用/服务通信（轻量级）： 当服务之间需要进行简单的事件通知或状态同步时，Pub/Sub 可以作为一种轻量级的解耦方式。例如，一个服务更新了某个配置，可以通过发布消息通知其他相关服务重新加载配置。
  5. 缓存失效通知： 在分布式缓存系统中，当某个节点的缓存数据发生变化时，可以通过 Pub/Sub 通知其他节点使对应缓存失效。
  6. 实时日志分析/分发： 收集器将日志发布到不同频道，不同的分析服务订阅感兴趣的频道进行处理。

第五部分：Redis Pub/Sub 的重要考虑事项与限制

虽然 Redis Pub/Sub 简单高效，但它并非适用于所有消息传递场景。理解其局限性至关重要。

  1. 无消息持久化 (No Message Persistence)： Redis 的 Pub/Sub 消息是即发即忘（Fire-and-Forget）的。Redis 服务器接收到 PUBLISH 命令后，会将消息立即推送给当前所有活跃的、订阅了相关频道或模式的客户端。一旦消息被推送（或没有订阅者），该消息就不会在 Redis 中存储。这意味着：

    • 如果一个订阅者客户端在消息发布时处于离线状态，它将永久丢失这条消息。 当它重新上线并重新订阅频道时，它只能接收到从那一刻起发布的新消息。
    • Redis 的 RDB 和 AOF 持久化机制不保存 Pub/Sub 相关的消息数据。它们只保存键值对数据。

  2. 无消息确认机制 (No Acknowledgement)： 发布者无法知道消息是否被任何订阅者成功接收。Redis 服务器也不会向发布者提供消息是否被投递的确认。订阅者接收到消息后也不会向 Redis 发送确认。

  3. 订阅者的阻塞特性 (Blocking Nature of SUBSCRIBE/PSUBSCRIBE)： 正如前面提到的，执行 SUBSCRIBE 或 PSUBSCRIBE 命令的客户端连接会进入订阅模式并阻塞，直到取消订阅。这意味着你不能在同一个连接上既订阅频道又执行常规的 GET/SET 等命令。通常需要为 Pub/Sub 使用单独的连接。现代 Redis 客户端库通常会抽象这一细节，提供回调函数或事件驱动的方式来处理接收到的消息，使得在应用代码中看起来是非阻塞的。

  4. 消息积压的处理 (Message Backlog)： Redis Pub/Sub 不提供消息积压（Backlog）功能。如果发布速度远超订阅者的处理速度，消息会在 Redis 服务器的网络缓冲区中排队等待发送给慢速的订阅者。如果积压严重，可能导致：

    • 慢速订阅者被服务器断开连接，因为服务器无法再缓冲更多消息给它（取决于服务器配置，如 client-output-buffer-limit pubsub）。
    • 虽然 Redis 服务器本身的 Pub/Sub 逻辑很快，但如果订阅者处理消息很慢，会占用服务器资源（如网络带宽、输出缓冲区）。

  5. 无竞争消费者模式 (No Competing Consumers)： Pub/Sub 模式是广播模式。一条消息会被投递给所有匹配的订阅者。这意味着如果你的需求是“一组工作者竞争获取队列中的一个任务来执行”，Pub/Sub 模式是不合适的。对于这种任务队列场景，Redis 的List（通过 BLPOP/BRPOP 实现）或更高级的Streams（通过 XREADGROUP 实现消费者组）是更合适的选择。

  6. 伸缩性考量 (Scalability Considerations):

    • 单个 Redis 实例的 Pub/Sub 性能非常高，可以处理大量的消息和订阅者。
    • 但所有的 Pub/Sub 流量都集中在单个 Redis 实例上。如果消息量或订阅者数量非常巨大，可能会达到单个实例的网络或 CPU 瓶颈。
    • Redis Pub/Sub 本身不直接支持跨多个 Redis 实例的横向伸缩。如果你需要跨集群发布和订阅消息，需要额外的中间层或应用逻辑来实现（例如，使用 Redis Cluster 的某些特定实现，或者在应用层面构建代理/转发逻辑）。

第六部分：Redis Pub/Sub 与传统消息队列的对比

与 Kafka, RabbitMQ 等传统消息队列相比，Redis Pub/Sub 的差异非常明显，这决定了它们的适用场景不同：

特性 Redis Pub/Sub 传统消息队列 (Kafka, RabbitMQ等)
消息持久化 无（即发即忘） 通常支持（可选或默认）
离线消息投递 无（离线会丢失消息） 通常支持（消息保留直到被消费）
消息确认机制 无 通常支持（消费者确认消费成功）
消息顺序性 同一个发布者到同一个频道的消息基本有序 通常支持分区内有序或全局有序（取决于实现）
消费模式 广播（一条消息给所有订阅者） 广播（Pub/Sub）和竞争消费（Queue/Consumer Group）都支持
消息积压处理 输出缓冲区有限，积压可能导致订阅者被断开连接 支持消息积压到磁盘，可处理生产者速度远大于消费者的情况
复杂性 非常简单 通常更复杂，功能更丰富（路由、交换机、消费者组等）
性能 低延迟，高吞吐（内存操作），适用于即时广播 高吞吐（通常磁盘持久化），功能全面，延迟相对较高
典型用途 实时广播、简单通知、缓存失效、轻量级解耦 任务队列、事件流处理、跨服务可靠通信、大数据管道

总结来说：

  • 选择 Redis Pub/Sub： 当你需要一个简单、快速、低延迟的机制来实现即时广播，并且可以容忍订阅者离线时丢失消息的场景。
  • 选择传统消息队列： 当你需要可靠的消息投递（不丢失离线消息）、消息持久化、消息确认、复杂的路由、或者竞争消费模式时。

Redis Pub/Sub 更像是一个高效的内存事件总线，而不是一个可靠的消息队列中间件。

第七部分：实践中的客户端与注意事项

在实际应用中，你不会直接在命令行中频繁使用 SUBSCRIBE。你会使用各种编程语言的 Redis 客户端库。这些客户端库通常会：

  1. 为你抽象出订阅模式的阻塞特性。你通常会提供一个回调函数或事件监听器。当收到消息时，客户端库会在一个独立的线程或事件循环中调用你的回调函数来处理消息，而不会阻塞你的主程序流程。
  2. 管理多个 Redis 连接：一个连接用于订阅，其他连接用于执行常规命令。

示例 (Python Pseudocode):

“`python
import redis

— Subscriber —

def message_handler(message):
# message 是一个字典，通常包含 ‘type’, ‘channel’, ‘data’
print(f”Received message on channel {message[‘channel’]}: {message[‘data’]}”)

r_sub = redis.Redis(…)
pubsub = r_sub.pubsub() # 创建 Pub/Sub 对象

订阅频道

pubsub.subscribe(‘my-channel’, ‘another-channel’)

订阅模式

pubsub.psubscribe(‘pattern:*’)

在一个独立的线程或协程中监听消息

pubsub.run_in_thread(daemon=True) # 或者使用 listen() 方法在循环中处理

你的主程序可以继续执行其他任务

…

— Publisher —

r_pub = redis.Redis(…)

发布消息

r_pub.publish(‘my-channel’, ‘Hello from publisher!’)
r_pub.publish(‘pattern:topic1’, ‘Message for pattern subscribers’)

…

— Unsubscribe (optional) —

pubsub.unsubscribe(‘my-channel’)

pubsub.punsubscribe(‘pattern:*’)

pubsub.unsubscribe() # 退订所有频道和模式

pubsub.close() # 关闭 Pub/Sub 连接

“`

客户端库的使用极大地简化了 Redis Pub/Sub 的集成。关键是记住底层连接的阻塞特性和消息的“即发即忘”性质。

第八部分：深入理解 SUBSCRIBE/PSUBSCRIBE 的回复格式

当客户端处于订阅模式时，它接收到的回复不再是常规的命令回复（如字符串、整数、数组等），而是特定格式的数组回复。这些回复数组的第一个元素表明了回复的类型。

接收到的回复类型主要有三种：

  1. 订阅确认回复 ("subscribe" / "psubscribe")

    • 格式：[type, channel/pattern, subscribed_count]
    • type: "subscribe" 表示订阅频道成功，"psubscribe" 表示订阅模式成功。
    • channel/pattern: 成功订阅的频道名称或模式字符串。
    • subscribed_count: 当前客户端所有订阅的频道和模式的总数量（整数）。
    • 用途：客户端知道自己已经成功订阅了哪些频道/模式，以及当前的总订阅状态。

  2. 消息回复 ("message")

    • 格式：["message", channel, message_content]
    • type: "message".
    • channel: 接收到消息的频道名称。
    • message_content: 接收到的消息内容。
    • 用途：这是通过 SUBSCRIBE 订阅的频道接收到的消息。

  3. 模式消息回复 ("pmessage")

    • 格式：["pmessage", pattern, channel, message_content]
    • type: "pmessage".
    • pattern: 接收到消息的频道所匹配的模式。
    • channel: 实际接收到消息的频道名称。
    • message_content: 接收到的消息内容。
    • 用途：这是通过 PSUBSCRIBE 订阅的模式接收到的消息。一个消息发布到一个频道，如果匹配了多个模式，订阅了这些模式的客户端会收到多条 "pmessage" 回复，每条对应一个匹配的模式。

  4. 退订确认回复 ("unsubscribe" / "punsubscribe")

    • 格式：[type, channel/pattern, remaining_count]
    • type: "unsubscribe" 表示退订频道成功，"punsubscribe" 表示退订模式成功。
    • channel/pattern: 成功退订的频道名称或模式字符串（如果未指定退订目标，则返回 nil）。
    • remaining_count: 当前客户端所有剩余订阅的频道和模式的总数量（整数）。
    • 用途：客户端知道自己已经成功退订，并且了解当前还剩余多少订阅。当 remaining_count 变为 0 时，客户端退出订阅模式。

理解这些回复格式对于开发 Pub/Sub 客户端程序，特别是使用底层连接自己处理消息时非常重要。

总结

Redis 的发布订阅功能是一个简单、快速、基于内存的即时消息广播机制。它通过 PUBLISH、SUBSCRIBE、UNSUBSCRIBE、PSUBSCRIBE、PUNSUBSCRIBE 等命令实现发布者与订阅者之间的解耦通信。其核心优势在于低延迟和高吞吐，非常适合需要将消息快速推送给大量在线接收者的场景，如实时通知、数据更新广播、简单聊天等。

然而，它的最大限制在于缺乏消息持久化和离线投递保证。消息一旦发布，如果订阅者不在线或处理缓慢导致积压，消息就会丢失。这使得 Redis Pub/Sub 不适用于需要高可靠性、消息不丢失、或者需要处理离线消息、历史消息的场景。对于这些需求，传统的重量级消息队列或者 Redis 的 Streams 数据结构是更合适的选择。

一言蔽之，将 Redis Pub/Sub 视为一个高效的实时事件通知总线，而非功能完备的持久化消息队列，你就能更准确地理解和使用它。掌握了它的特性和局限，你就能在合适的场景下充分发挥其轻量、高速的优势，同时避免在不适用的场景中踩坑。

希望本文能帮助你全面而深入地理解 Redis 发布订阅机制！

发表评论

您的邮箱地址不会被公开。 必填项已用 * 标注

滚动至顶部