订阅Redis频道的程序运行一段时间就断线，重连后又能继续。网络抖动是一种可能，消费者读取消息太慢、服务端输出缓冲区积压也值得检查。
先定位断线原因，不要直接把缓冲区上限调到无限大。积压会持续占用Redis内存。
先核对客户端类型与现象
记录断线时间、订阅频道、消息峰值和客户端日志，确认是Pub/Sub连接还是普通命令连接。Redis官方客户端文档说明，不同类型连接的输出缓冲区限制不同，不能把普通连接设置直接套用到订阅客户端。
同时检查服务端日志中与输出缓冲区相关的断开提示。客户端主动断开、空闲超时和服务端保护断开需要分开处理。
用CLIENT LIST观察积压
在有权限的管理连接上执行CLIENT LIST TYPE PUBSUB，按地址或客户端名称定位订阅者，并观察输出缓冲区相关字段。官方文档说明omem表示该连接输出缓冲区使用的内存。
单次快照不足以判定长期积压。应在消息高峰连续观察增长趋势，并与消费者处理速度对应。
区分两类内存保护
Redis的输出缓冲区限制针对单个连接的待发送数据；官方文档还描述maxmemory-clients控制全部客户端连接的聚合内存并可驱逐占用大的连接。后者从Redis 7.0起提供，复制连接不受该客户端驱逐机制影响。
这两类限制不是同一个开关。要结合当前Redis版本和生效配置核对，不能仅凭断线现象判断。
先处理慢消费者
检查订阅者是否在收到消息后同步执行慢查询、外部API调用或大对象反序列化。减少单条消息体积、改善消费循环和处理能力，比持续扩大服务端缓冲区更稳妥。
临时调整缓冲阈值前应评估峰值连接数和VPS可用内存。阈值提高会增加内存风险，并不会修复客户端不读取的问题。
验证稳定性
在隔离环境复现高峰发布速率，可使用萤光云或LightNode的独立VPS模拟订阅端。观察断线率、omem、总客户端内存与业务消息处理延迟。
验收标准是高峰期间订阅连接稳定，缓冲区不会持续累积，且Redis内存仍有安全余量。
FAQ
问：Pub/Sub客户端空闲会被普通timeout断开吗？答：官方文档说明普通连接的空闲超时不适用于Pub/Sub连接，应查其他断线原因。
问：能靠重连避免消息丢失吗？答：Pub/Sub本身不提供离线消息补发；需要可靠消费语义时应评估其他数据结构或消息方案。
温馨提示
温馨提示：变更阈值前先记录旧配置、连接数量和内存使用量，并在高峰业务流量下观察恢复效果。
