4. 基于 Pub/Sub 的发布订阅模式：SUBSCRIBE/PUBLISH 实现广播消息、与 List 队列的区别、消息丢失风险

Redis 的 Pub/Sub（发布/订阅）是一种消息通信模式，发送者（Publisher）将消息发送到指定的频道（Channel），而订阅者（Subscriber）可以订阅一个或多个频道并实时接收消息。这种模式在广播通知、实时数据推送、事件驱动架构中应用广泛。本章将深入剖析 Pub/Sub 的核心机制、与 List 队列的差异以及其固有的消息丢失风险。

4.1 Pub/Sub 核心机制与命令

Pub/Sub 模式的核心是“频道”概念。发布者向频道发送消息，所有订阅该频道的客户端都会立即收到消息。这种模式是典型的“扇出”（Fan-out）模型，消息被广播给所有订阅者。

4.1.1 基本命令

4.1.2 工作流程

1. 订阅者连接：客户端通过 SUBSCRIBE 命令连接到 Redis 服务器，并指定要监听的频道。
2. 频道注册：Redis 服务器维护一个“频道-订阅者”映射表，将订阅者加入对应频道的订阅者列表。
3. 消息发布：发布者通过 PUBLISH 命令向指定频道发送消息。
4. 消息分发：Redis 服务器遍历该频道的所有订阅者，将消息逐条推送给每个订阅者的连接缓冲区。
5. 实时接收：订阅者从连接中读取消息，完成一次消息传递。

4.2 Pub/Sub 与 List 队列的对比

虽然 Pub/Sub 和 List 队列都能实现消息传递，但它们在设计哲学、消息模型、可靠性等方面存在本质差异。理解这些差异对于选择正确的消息模式至关重要。

4.3 消息丢失风险分析

Pub/Sub 模式最大的缺陷在于消息丢失风险。以下场景会导致消息无法到达订阅者：

4.3.1 订阅者离线

如果订阅者在消息发布时未连接到 Redis 服务器，该消息将永久丢失。Pub/Sub 没有消息持久化或重传机制。

4.3.2 网络中断

当订阅者与 Redis 之间的网络连接中断时，中断期间发布的消息会丢失。Redis 不会为断线的订阅者缓存消息。

4.3.3 客户端缓冲区溢出

如果订阅者消费消息的速度慢于发布者发送消息的速度，客户端的输出缓冲区可能被填满。当缓冲区达到 client-output-buffer-limit 配置的限制时，Redis 会强制断开该订阅者的连接，导致后续消息丢失。

4.3.4 服务器故障

Redis 服务器宕机或重启时，所有未持久化的 Pub/Sub 消息都会丢失。即使启用了 RDB 或 AOF 持久化，Pub/Sub 消息也不会被保存。

4.4 实战：使用 Pub/Sub 实现广播通知

以下示例展示如何使用 Redis Pub/Sub 实现一个简单的系统状态广播通知。发布者定期发送系统健康状态，所有订阅的管理员客户端实时接收。

4.4.1 发布者代码（Python）

import redis
import time
import json

r = redis.Redis(host='localhost', port=6379, decode_responses=True)

channel = 'system:health'
while True:
    status = {
        'cpu': '45%',
        'memory': '62%',
        'disk': '78%',
        'timestamp': time.time()
    }
    message = json.dumps(status)
    # 发布消息到频道
    r.publish(channel, message)
    print(f"Published: {message}")
    time.sleep(5)  # 每5秒发布一次

4.4.2 订阅者代码（Python）

import redis

r = redis.Redis(host='localhost', port=6379, decode_responses=True)

channel = 'system:health'
pubsub = r.pubsub()
# 订阅频道
pubsub.subscribe(channel)

print(f"Subscribed to {channel}, waiting for messages...")
for message in pubsub.listen():
    if message['type'] == 'message':
        print(f"Received: {message['data']}")
        # 在这里处理消息，例如发送告警或更新仪表盘

4.5 总结