Redis Pub/Sub核心局限性

Redis Pub/Sub “发后即忘” 且易因 Full GC 漏消息的问题非常精准，这也是它的核心局限性。但首先要明确：Redis Pub/Sub 依然有其适用场景，只是我们需要清楚它的设计定位和边界。

Redis Pub/Sub 并非为“可靠消息传递”设计，而是为轻量、低延迟、简单的实时通信而生，它的核心价值在于：

极简的实时通信能力 实现成本极低，只需 PUBLISH/SUBSCRIBE 两个核心命令，无需依赖额外组件（如 Kafka、RabbitMQ），适合对“可靠性要求低、实时性要求高”的场景：
- 实时通知（如前端页面的在线状态更新、操作提醒）；
- 日志广播（如多台机器同步收集日志）；
- 临时的事件分发（如开发/测试环境的简单消息通知）。
轻量无状态，性能极高 Pub/Sub 不持久化消息、不维护消费进度，Redis 仅做“消息转发”，单节点能支撑每秒几十万级的消息分发，资源消耗远低于专业消息队列。
与 Redis 生态无缝融合 如果系统已大量使用 Redis，无需引入新中间件即可快速实现简单的发布订阅，降低架构复杂度。

你提到的问题，核心是 Redis Pub/Sub 的无持久化、无确认、无重发设计：

发后即忘（Fire and Forget）
- 发布者 PUBLISH 消息后，Redis 仅会将消息转发给当前在线的订阅者，不会存储消息；
- 若订阅者离线（如 Full GC 停顿、网络中断），这期间的消息会直接丢失，Redis 不会缓存、不会重试。
Full GC 漏消息的具体过程
- 订阅者进程因 Full GC 暂停（比如停顿 100ms），此时 Redis 与订阅者的连接虽未断开，但订阅者无法处理网络数据；
- Redis 向该连接发送消息时，若订阅者的 TCP 接收缓冲区满，Redis 会直接丢弃消息（无重试逻辑）；
- GC 结束后，订阅者恢复，但丢失的消息已无法找回。

如果你的场景需要消息可靠性（不能漏消息），Redis Pub/Sub 完全不适用，建议：

替代方案：Redis Stream Stream 是 Redis 5.0 推出的专门解决“可靠消息队列”的功能，弥补了 Pub/Sub 的缺陷：
- 消息持久化：所有消息会存储在磁盘（可配置过期时间）；
- 消费确认：支持 ACK 机制，未确认的消息可重发；
- 消费进度：通过 Consumer Group 维护每个消费者的消费偏移量，即使 Full GC 停顿，恢复后可从上次的位置继续消费；
- 支持消息回溯：可读取历史消息，避免漏收。
简单示例（Stream 生产/消费）：
```
# 生产消息（往 stream 中添加消息）
XADD mystream * orderId 1001 status paid

# 创建消费组（首次使用）
XGROUP CREATE mystream mygroup $ MKSTREAM

# 消费者从消费组获取消息（阻塞 0 表示一直等）
XREADGROUP GROUP mygroup consumer1 COUNT 10 BLOCK 0 STREAMS mystream >

# 确认消息已处理（避免重发）
XACK mystream mygroup 1678900000000-0
```
临时规避（仅适用于非核心场景） 若暂时无法替换 Pub/Sub，可通过以下方式减少漏消息：
- 缩短 Full GC 时间：优化 JVM 参数（如使用 G1GC、调整堆大小），减少停顿时长；
- 增加缓冲区：调整订阅者的 TCP 接收缓冲区大小，降低因 GC 短暂停顿导致的缓冲区满；
- 兜底检查：关键消息在发布时额外写入 Redis Hash/List，订阅者恢复后主动拉取补全。

注意：本文归作者所有，未经作者允许，不得转载