Recv-Q长期>0说明Redis处理新连接能力不足，队列开始积压；若接近Send-Q（如65530/65535）则需调大net.core.somaxconn至65535并同步配置redis.tcp-backlog；若稳定在100～500波动，则主因是Redis主线程阻塞，应查SLOWLOG、persistence及instantaneous_ops_per_sec。
ss -lnt 显示 Recv-Q 长期 > 0 说明什么
Recv-Q 是内核 accept 队列里等待被 Redis 主线程 accept() 的连接数。它持续非零，不是“连接慢”，而是 Redis 已经来不及处理新连接了——队列开始积压。这时候不能只盯着 Redis 日志或 INFO clients，得看系统层是否在丢 SYN 包。
什么时候该调 net.core.somaxconn，调多少才有效
只有当 ss -lnt 输出中 Recv-Q 接近 Send-Q（比如 65530/65535）时，才说明队列真满了，net.core.somaxconn 确实是瓶颈。默认值通常是 128 或 511，对高并发场景远远不够。
- 生产环境建议设为
65535，这是 Linux 内核支持的合理上限 - 必须同步改
redis.conf中的tcp-backlog，且不能小于somaxconn值；否则 Redis 启动时会默默降级使用默认值（通常是511），等于白调 - 改完要执行
sudo sysctl -p生效，重启 Redis 才能真正启用新 backlog
调了 somaxconn 还卡？可能是假瓶颈
如果 Recv-Q 稳定在 100～500 之间频繁波动，而不是顶到上限，大概率不是队列长度问题，而是 Redis 自身卡住了：
- 查
SLOWLOG GET 5，看有没有阻塞命令（如KEYS、大HGETALL）拖住主线程 - 运行
INFO persistence，确认bgrewriteaof_in_progress是否为1，AOF 重写可能吃满 CPU 或磁盘 IO - 观察
INFO stats中的instantaneous_ops_per_sec是否骤降——降了说明主线程已无法及时响应
这种情况下硬调 somaxconn 只会让积压更隐蔽，实际吞吐没变，还可能掩盖真正的阻塞点。
别碰 net.ipv4.tcp_max_syn_backlog，除非你被 SYN Flood 攻击
这个参数控制的是“半连接队列”（SYN_RCVD 状态），只在遭遇大量伪造 SYN 包时起作用。Redis 正常高并发下，它几乎不会成为瓶颈。
验证方法：运行 netstat -s | grep "SYNs to LISTEN sockets dropped"，输出为 0 就说明完全不用动它。乱调反而可能干扰 TCP 握手行为，引发不可预期的连接失败。
真正要盯紧的，永远是 ss -lnt 的 Recv-Q + Redis 主线程状态，而不是堆参数。
