redis高并发卡顿根本原因是linux内核accept队列满：net.core.somaxconn与redis tcp-backlog需同步设为65535，否则队列堆积致连接超时或丢弃；epoll边缘触发下须配tcp-nodelay、调大tcp_rmem/wmem、启用tcp_tw_reuse；fork失败主因vm.overcommit_memory未设为1。
为什么Redis在高并发下会卡在accept队列？
根本原因不是Redis本身慢，而是Linux内核的连接队列满了。当客户端发起大量TCP连接时，内核把已完成三次握手的连接放进accept queue，Redis主线程调用accept()从中取走。如果Redis处理不过来（比如阻塞在慢命令或持久化），队列就会堆积，新连接超时或被丢弃，netstat -s | grep "listen drops"会显示非零值。
关键参数是net.core.somaxconn和tcp-backlog，二者必须匹配：
-
net.core.somaxconn是内核层面的最大队列长度，需在/etc/sysctl.conf中设为至少65535 -
tcp-backlog是Redis配置里的tcp-backlog值，必须≤net.core.somaxconn，建议也设为65535 - 若两者不一致，Redis启动时会警告“backlog setting ignored”，实际生效的是较小值
epoll边缘触发模式下，哪些TCP参数必须调？
Redis在Linux默认用epoll，且是边缘触发（ET）模式——它只在socket状态变化时通知一次。如果一次没读完数据，后续不会再次提醒，导致命令解析卡住或客户端假死。这时tcp_nodelay和缓冲区参数就至关重要：
- 强制关闭Nagle算法：
tcp-nodelay yes（Redis配置），避免小包合并延迟 - 增大接收/发送缓冲区：
net.ipv4.tcp_rmem和net.ipv4.tcp_wmem三元组设为4096 65536 16777216，防止缓冲区满丢包 - 启用快速回收TIME_WAIT：
net.ipv4.tcp_tw_reuse = 1，尤其在短连接密集场景（如HTTP代理后端）能显著提升连接复用率
fork失败、内存分配卡顿，跟哪个内核参数直接相关？
vm.overcommit_memory设为0时，Redis执行bgsave或bgrewriteaof会因fork()失败报Cannot allocate memory。这不是真没内存，而是内核拒绝过度承诺。
必须设为1：
-
vm.overcommit_memory = 1表示“允许overcommit”，让fork()总能成功（写时复制机制保证安全） - 顺带调整
vm.swappiness = 1，禁止swap干扰Redis低延迟要求 - 禁用透明大页：
echo never > /sys/kernel/mm/transparent_hugepage/enabled，否则fork()会卡几百毫秒
为什么调了参数还是有大量CLOSE_WAIT？
CLOSE_WAIT堆积说明客户端已发FIN，但Redis没及时调用close()。这通常不是内核参数问题，而是应用层逻辑卡住：
- 检查是否有长耗时命令（如
KEYS *、大HGETALL）阻塞事件循环 - 确认客户端是否正确释放连接（未调用
disconnect或连接池泄漏） -
tcp_keepalive参数（Redis配置中的tcp-keepalive）仅对空闲连接有效，无法解决主动关闭流程卡顿 - 真正要调的是
net.ipv4.tcp_fin_timeout（建议30），缩短TIME_WAIT持续时间，间接缓解CLOSE_WAIT观察偏差
网络参数调优不是“改完就快”，而是让Redis单线程模型不被内核拖住——重点永远在accept queue、fork和epoll ET这三个交界点上。漏掉任何一个，吞吐量都卡在瓶颈处不动。
