redis订阅长连接易断的根本原因是tcp全连接队列溢出或客户端输出缓冲区满导致强制关闭：需同步调优net.core.somaxconn、tcp-backlog和client-output-buffer-limit pubsub三参数，并协同配置tcp-keepalive与内核keepalive参数防中间设备断连。
Redis订阅（SUBSCRIBE）长连接对TCP参数极其敏感，不调优会导致连接频繁断开、消息延迟飙升甚至客户端收不到推送——根本原因不是Redis扛不住，而是内核TCP全连接队列溢出或客户端缓冲区被填满后触发强制驱逐。
为什么Redis PUB/SUB长连接特别容易掉？
订阅连接是典型“低频发、高保活、单向流”场景：客户端建连后几乎不发命令，只等服务器推送；Redis主线程在aeProcessEvents中轮询时，若client-output-buffer-limit pubsub被突破，会直接关闭连接，且不报错；同时，net.core.somaxconn过小会让新订阅请求在三次握手完成后就被内核静默丢弃，ss -s里listen overflows非零就是铁证。
- 常见错误现象：
Connection refused（新订阅失败）、READONLY You can't write against a read only replica（实为连接已断但客户端未感知）、PUBSUB NUMSUB返回数远低于实际客户端数 - 关键区别：普通Redis命令连接可快速完成并释放，而SUBSCRIBE连接会长期空闲，
timeout和tcp-keepalive必须协同生效，否则NAT/防火墙会主动斩断 - 性能影响：一个未调优的64G服务器，在10万SUBSCRIBE连接下，
instantaneous_ops_per_sec可能骤降至个位数——瓶颈不在Redis命令处理，而在内核协议栈无法及时把消息推到socket发送缓冲区
必须同步修改的三个核心参数
单改任一参数都无效，三者必须严格对齐：
linux-performance-analyzer
下载
Linux 性能分析与调优专家，覆盖 CPU、内存、磁盘 I/O、网络、内核参数、编译优化、容器/K8s。适用场景：系统卡顿/高负载、内存不足/OOM/Swap 高、CPU 异常/iowait 高。
-
net.core.somaxconn：Linux全连接队列上限。默认128，10万订阅连接至少设为65535（sudo sysctl -w net.core.somaxconn=65535，并写入/etc/sysctl.d/99-redis.conf） -
tcp-backlog：Redis配置中redis.conf里的tcp-backlog 65535（Redis 6.2+生效；老版本需确认glibc支持，否则仍卡在511） -
client-output-buffer-limit pubsub：这是订阅场景独有的生死线。默认值33554432 8388608 60（32MB硬限 + 8MB软限/60秒）极易触发断连。建议改为client-output-buffer-limit pubsub 268435456 134217728 60（256MB硬限 + 128MB软限），尤其当发布端批量PUBLISH大消息时
长连接保活与缓冲区适配要点
订阅连接空闲时间远超普通连接，必须防止中间设备（如云厂商SLB、企业防火墙）无感知断连：
-
tcp-keepalive 300（Redis配置）仅控制Redis是否向客户端发心跳包，但真正起效依赖内核net.ipv4.tcp_keepalive_time（默认7200秒）。建议统一设为1800（30分钟），避免心跳间隔过长 -
net.ipv4.tcp_rmem和net.ipv4.tcp_wmem需匹配万兆网卡带宽：若单台Redis承载5万订阅，平均每个连接每秒推送1KB，则总吞吐约50MB/s，缓冲区最大值应≥16777216（16MB），否则内核会反复收缩窗口导致推送卡顿 - 禁用
tcp_slow_start_after_idle（设为0）：防止连接空闲后重传速率归零，这对持续推送消息的场景致命
验证是否真正生效的检查点
改完不验证等于没改：
- 看队列长度：
ss -lnt | grep :6379，Send-Q列必须显示65535（不是511或128） - 看溢出计数：
netstat -s | grep "listen overflows"，重启Redis后该值应保持为0；若上升，说明somaxconn或tcp-backlog仍不足 - 看缓冲区占用：
redis-cli INFO clients | grep client_longest_output_list，若长期＞1000，说明client-output-buffer-limit pubsub设置过低或发布端消息过大 - 看连接状态：
ss -tn state established '( dport = :6379 )' | wc -l，对比redis-cli CLIENT LIST | grep "cmd=subscribe" | wc -l，二者应基本一致；若前者远大于后者，说明大量连接已被Redis主动关闭但客户端未重连
最易被忽略的是client-output-buffer-limit pubsub的软限触发逻辑：它不是内存用满才断，而是在60秒内累计超过128MB就强制关闭连接，且不会记录到SLOWLOG——这个阈值必须根据你实际发布的消息大小和频率反向推算，不能照搬文档示例值。
