Redis发布订阅模式优化长连接处理的实用技巧

Redis 服务端建议必须配置tcp-keepalive=60和timeout=600，避免Pub/Sub长时间空闲连接被静默断开；客户端还需要根据Lettuce、Redisson或Jedis的实现差异开启心跳机制，并持续校验DNS解析与节点状态。

Redis服务端必须配置tcp-keepalive和timeout

在默认配置下，Redis 可能会静默关闭空闲连接——timeout 默认值通常为 300 秒（5 分钟），而 Pub/Sub 订阅连接本身几乎不会主动发送命令，长期处于等待消息状态，因此非常容易被服务端断开。仅依赖客户端自动重连，通常无法从根本上解决问题。

建议在 redis.conf 中明确添加以下配置：

• tcp-keepalive 60：开启操作系统内核层的 TCP 保活探测，每 60 秒发送一次 ACK 检测，可更快识别 NAT、云负载均衡或防火墙造成的中途断连
• timeout 600：将 Redis 服务端的空闲连接关闭阈值提升到 10 分钟，为客户端执行心跳检测、异常识别和重连恢复预留缓冲时间

这两项配置必须写入配置文件，并执行 CONFIG REWRITE 或通过重启使其生效，否则实例重启后配置会丢失。还要注意：tcp-keepalive 0 代表关闭该功能，不能忽略不配。

Lettuce/Redisson/Jedis 的心跳配置差异非常明显

客户端启用 autoReconnect=true 并不意味着连接一定稳定，也不代表 Pub/Sub 长连接不会进入僵死状态。不同 Redis 客户端对心跳探测和订阅连接的处理方式差别很大，而且多数默认并不会自动开启完整心跳能力：

• Lettuce（Spring Boot 常见默认客户端）：spring.redis.lettuce.keep-alive=true 主要作用于普通命令连接；对于 StatefulRedisPubSubConnection，通常仍需结合异常监听，在 onException 回调后主动调用 connection.ping() 做连接探测
• Redisson：建议显式配置 setHeartbeatInterval(15000)（15 秒）开启心跳，同时设置 setSubscriptionConnectionPoolSize(20)，避免订阅连接过少导致排队阻塞，影响订阅线程处理效率
• Jedis：本身没有内置的 Pub/Sub 心跳机制，需要在订阅线程中自行启动定时任务，周期性执行 jedis.ping()；并且必须复用当前 PubSub 绑定的那个 Jedis 实例，不能随意从连接池中重新取一个连接替代

DNS 缓存和 VIP 漂移会引发“假连接”问题

很多客户端连接 Redis 时使用的是域名，例如 redis-prod.cluster.example.com。如果 DNS 缓存时间设置过长，或者云 Redis 的 VIP 发生漂移，客户端保留的旧连接就可能仍然挂在已经失效或下线的节点上。此时问题往往非常隐蔽：PING 似乎还能返回正常结果，但 PUBLISH 却无法真正写入，报错可能是 READONLY You can't write against a read only replica，也可能表现为长时间无响应。

常见优化方式包括：

• JVM 启动参数增加 -Dsun.net.inetaddr.ttl=60，将 DNS 缓存强制设置为 60 秒刷新一次
• Redisson 用户应检查 dnsMonitoringInterval 配置，建议维持默认 5000ms，或根据实际网络环境调整到 3000ms
• 所有客户端都应定期执行 INFO replication 或 CLUSTER NODES，确认当前连接是否依旧指向可写的有效 master 节点

不要把 Pub/Sub 直接当作可靠消息队列使用

Redis 的 Pub/Sub 本质上是实时内存转发机制，不具备持久化、消息确认或失败重试能力。只要订阅者在离线或断连期间错过消息，这些消息就会直接丢失，重新上线后也不会收到补发。

如果业务场景对消息可靠性要求较高，可以考虑：

• 改用 Stream + XREADGROUP，支持消费者组、ACK 确认以及消息重放，更适合可靠消息处理场景
• 在应用层增加兜底方案：发布消息前先写入 DB 或 LIST，再执行 PUBLISH 发送通知；订阅端收到通知后主动拉取最新数据或状态

真正稳定的 Redis Pub/Sub 长连接，不是单靠“断了再重连”，而是要确保连接在空闲期间能够持续被探测、被校验、被刷新。只要其中任意一个环节缺失，在高并发场景或复杂云网络环境下，就很容易演变成偶发性的消息收不到问题。