必须换用STREAM才能解决Redis Pub/Sub网络抖动导致的消息丢失,因其纯内存广播、无持久化、无offset,断连期间消息彻底消失,重连后无法回溯;STREAM提供持久化、消费者组、ACK确认和消息回溯能力。

Redis Pub/Sub 无法从网络抖动中“恢复”丢失的消息——它压根就不存,也无 offset 可回溯。必须在应用层补重连逻辑,或直接换用 STREAM。
redis-py 的 PubSub 断连后 listen() 直接抛 ConnectionError
这不是 bug,是设计如此:PubSub.listen() 是一个阻塞迭代器,底层 TCP 断开时会立即退出循环,不会等待、不重试、不缓存。常见错误是把 for msg in pubsub.listen(): 包在 try/except 里——异常一抛就跳出循环,后续消息永远收不到。
- 正确做法:整个
listen()循环必须包在外层while True:中,每次异常后重建连接 - 每次断连后必须新建
redis.Redis()实例和新的pubsub = r.pubsub()对象,不能复用旧对象 - 重订阅必须一次性调用
pubsub.subscribe('a', 'b', 'c'),漏掉任意一个 channel 就会永久失联 - 别用
time.sleep(1)硬等,生产环境要用指数退避(如 1s → 2s → 4s → 最大 30s),避免雪崩式重连打满 Redis 连接数
Lettuce 自动重连不等于自动重订阅
ClientOptions.builder().autoReconnect(true) 只能重建 TCP 连接,PUBSUB 订阅状态不会同步回服务端。重连后若不手动 subscribe(),连接看似正常,但消息一个都收不到。
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis,支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 必须监听
StatefulRedisPubSubConnection的onConnected事件,在回调里重新subscribe() - 配置里还要加
disconnectedBehavior(RECONNECT_AND_QUEUE_COMMANDS),否则重连前发的命令直接丢弃 -
Spring Boot用户注意:spring.redis.lettuce.pool配置对 Pub/Sub 完全无效——Pub/Sub 走的是独占长连接,不走连接池 - 如果用
RedisClusterClient,别配集群地址;Pub/Sub 不支持集群模式,静默失败且无报错
Java 客户端缓冲区溢出导致静默断连
Jedis 默认无自动重连,Lettuce 默认 Netty 接收缓冲区仅 16KB。消费者处理慢(比如 DB 写入卡顿)→ 缓冲区填满 → Redis 主动 CLIENT KILL → 连接关闭 → 消息永久丢失。这个过程往往没有日志,只表现为“某段时间没收到消息”。
- Jedis 必须在重连前显式调用
jedis.close(),否则旧连接资源泄漏,容易触发maxclients限制 - Lettuce 建议用
ClientResources.builder().nettyCustomizer()扩大接收缓冲区,或加ChannelMessageListener异步消费,避免阻塞 Netty 线程 - 监控关键指标:
redis-cli --stat看pubsub_channels是否突降;client list查连接状态;pubsub numsub channel确认订阅数是否为 0
为什么重连 + 幂等处理仍不能解决“断连期间消息丢失”?
因为 Pub/Sub 根本不存那段时间的消息。重连后 SUBSCRIBE 只从当前时刻开始收,之前发布的所有内容已进黑洞。所谓“幂等”,只是防重复,不是补缺失。
- 真正要补历史,必须换用
STREAM:用XADD mystream * event data发布,再用XREADGROUP GROUP mygroup consumer1 STREAMS mystream 0-0从头读 - 别指望
mkstream=True自动创建流——XGROUP CREATE必须显式执行,否则XREADGROUP报错 - 消费者重启后,若不主动
XRANGE mystream - + COUNT 10扫积压,或不用XREADGROUP ... 0-0回溯,照样漏消息
真正难的不是写对 XADD 和 XACK,而是把“谁负责创建组、谁兜底重试、积压怎么监控”这些生命周期动作嵌进业务流程里——这一步漏了,换 STREAM 也照样丢。

















