3、Redis发布订阅模式：PUB/SUB原理、频道与模式匹配、在任务通知中的局限性
Redis 的发布/订阅（PUB/SUB）是一种消息通信模式，发送者（Publisher）将消息发送到频道（Channel），订阅者（Subscriber）可以订阅一个或多个频道来接收消息。这种模式在异步任务通知中曾被广泛使用，但随着系统复杂度的提升，其局限性也逐渐暴露。
3.1 PUB/SUB 核心原理
PUB/SUB 模式的核心是“频道”与“订阅”的解耦。发布者无需关心谁在订阅，订阅者也无需关心谁在发布，两者通过 Redis 服务器作为消息代理进行通信。
- 发布者（Publisher）：向指定频道发送消息，使用
PUBLISH channel message命令。 - 订阅者（Subscriber）：通过
SUBSCRIBE channel命令订阅一个或多个频道，进入阻塞监听状态。 - 频道（Channel）：消息的命名通道，发布者与订阅者之间的逻辑桥梁。
- 消息分发：Redis 服务器收到发布消息后，立即推送给所有订阅该频道的客户端。
关键特性：PUB/SUB 是“即发即忘”模式，消息不会被持久化。如果订阅者不在线，消息将永久丢失。
适用场景：实时性要求高、允许少量消息丢失的场景，如实时聊天、在线状态广播、系统监控告警。
3.2 频道与模式匹配
Redis 支持两种订阅方式：精确频道订阅和模式匹配订阅。
| 订阅方式 | 命令 | 匹配规则 | 示例 |
|---|---|---|---|
| 精确频道 | SUBSCRIBE channel |
完全匹配频道名称 | SUBSCRIBE task:notify |
| 模式匹配 | PSUBSCRIBE pattern |
支持 glob 风格通配符（*、?、[） |
PSUBSCRIBE task:* |
模式匹配订阅极大地增强了灵活性。例如，订阅 task:* 可以接收所有以 task: 开头的频道消息，无需逐个订阅。Redis 内部使用前缀树（Trie）结构来高效匹配模式。
# 发布者
PUBLISH task:email "send_welcome_email"
PUBLISH task:image "resize_avatar"
# 订阅者（模式匹配）
PSUBSCRIBE task:*
# 输出：
# 1) "pmessage"
# 2) "task:*"
# 3) "task:email"
# 4) "send_welcome_email"
# 1) "pmessage"
# 2) "task:*"
# 3) "task:image"
# 4) "resize_avatar"3.3 在任务通知中的局限性
尽管 PUB/SUB 模式简单高效，但在异步任务编排场景中，其固有缺陷非常明显，往往成为系统稳定性的隐患。
核心痛点：PUB/SUB 的“即发即忘”特性与任务通知的“可靠性要求”之间存在根本性矛盾。
3.3.1 消息丢失风险
- 订阅者离线丢失：如果订阅者在消息发布时断开连接，消息将永久丢失，无法重试。
- 网络闪断丢失：短暂的网络抖动可能导致消息推送失败，Redis 不会进行重试。
- 缓冲区溢出丢失：当订阅者消费速度远低于发布速度时，客户端输出缓冲区可能被撑爆，导致连接断开，后续消息全部丢失。
3.3.2 缺乏消息确认机制
- 发布者无法知道消息是否被成功接收或处理。
- 订阅者处理失败时，无法通知发布者重新发送。
- 没有 ACK（确认）机制，无法实现“至少一次”或“恰好一次”的语义保证。
3.3.3 不支持消息回溯与持久化
- 消息一旦被分发，立即从内存中删除，无法回溯历史消息。
- 新加入的订阅者无法获取历史消息，只能接收订阅之后的消息。
- Redis 重启后，所有 PUB/SUB 状态丢失。
3.3.4 性能与扩展性问题
- 单线程瓶颈：Redis 主线程处理 PUB/SUB 消息分发，大量消息可能阻塞其他命令。
- 扇出放大：一个频道有大量订阅者时，消息需要复制多份发送，消耗网络带宽和 CPU。
- 无消费组：无法实现“工作队列”模式，即一条消息只能被一个消费者处理。
3.4 局限性总结与替代方案
下表总结了 PUB/SUB 在任务通知场景中的关键局限，并给出了推荐的替代方案。
| 需求维度 | PUB/SUB 表现 | 推荐替代方案 |
|---|---|---|
| 消息持久化 | 不支持，丢失风险高 | Redis Streams / 消息队列（RabbitMQ、Kafka） |
| 消息确认 | 无 ACK 机制 | Redis Streams（XACK）/ 消息队列 |
| 消费组 | 不支持，广播模式 | Redis Streams（Consumer Group）/ 消息队列 |
| 消息回溯 | 不支持 | Redis Streams（范围查询）/ 消息队列 |
| 延迟消息 | 不支持 | Redis Keyspace Notifications + 延迟队列 / 消息队列 |
| 优先级 | 不支持 | Redis Sorted Set / 消息队列 |
实践建议：在异步任务编排中，优先使用 Redis Streams 替代 PUB/SUB。Streams 提供了持久化、消费组、ACK 确认、消息回溯等关键特性，同时保持了 Redis 的高性能。对于跨系统的任务通知，建议引入专业的消息队列（如 RabbitMQ、Kafka）来保证可靠性。
PUB/SUB 模式在简单的实时广播场景中仍有其价值，但在需要可靠性保证的任务通知系统中，其局限性是致命的。理解这些局限，是设计健壮异步任务编排系统的第一步。