弱网下pub/sub连接秒断主因是空闲tcp链路被nat/云lb/防火墙静默关闭，需服务端tcp-keepalive与timeout、客户端分连接心跳、dns刷新及节点校验四者协同；单靠重连无法解决。

弱网下Pub/Sub连接为什么秒断不是客户端代码写得烂

根本原因是Redis Pub/Sub连接本身不发心跳，TCP空闲链路在NAT、云LB或防火墙眼里就是“死连接”，60–300秒内被静默掐断——而订阅者还在等消息，既不发命令也不响应，服务端timeout和客户端tcp-keepalive若没对齐，断开就是必然。这不是重连逻辑能兜住的，是连接存活机制缺失。

Lettuce/Redisson/Jedis的心跳配置必须分开通用连接和Pub/Sub连接

通用连接池里的pingBeforeActivateConnection(true)或setHeartbeatInterval()默认只作用于命令连接，StatefulRedisPubSubConnection要单独处理：

• Lettuce：监听onException后手动调connection.ping()，不能依赖自动探测
• Redisson：必须显式设setHeartbeatInterval(15000)且setSubscriptionConnectionPoolSize(20)，否则单连接排队导致心跳超时
• Jedis：得在JedisPubSub子类里起独立定时器，每15秒调jedis.ping()，且必须复用同一个Jedis实例，混用连接池会报RedisConnectionClosedException

重连风暴的根源是没做状态隔离和退避控制

多个频道共用一个StatefulRedisPubSubConnection，一个频道消费慢就拖垮整条连接；重连时又不检查connection.isOpen()，直接subscribe()触发RedisConnectionClosedException，形成循环异常。正确做法是：

Redis Skill - 高性能缓存管理

Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。

下载

• 每个业务频道用独立连接池，避免互相干扰
• 用AtomicBoolean connected控制重连状态，禁止并发subscribe
• 重连失败后按指数退避重试：1s → 2s → 4s → 8s，上限卡在30s
• 重连前先INFO replication校验当前节点是否仍是master，防止连到只读副本后PUBLISH失败

别指望纯Pub/Sub扛住弱网，得加一层List兜底

Pub/Sub断连必丢消息，这是协议设计决定的。真要可靠，就得把“通知”和“数据”拆开：

• 发布端严格按顺序执行：r.lpush('queue:order', data) → r.publish('ch:order', '1')
• 订阅端启动时先lrange queue:order 0 -1补读，再ltrim queue:order 0 -1清空（或lrem按值删）
• 务必限制List长度，比如ltrim queue:order -1000，否则内存持续涨

真正难的不是写重连代码，是让心跳、连接池、DNS刷新、节点校验四件事在弱网下始终同步生效——少一环，重连就变成无效轮询。