Redis主从复制失败常因maxclients耗尽，需同步调高maxclients、ulimit -n及tcp-backlog参数，并验证/proc/*/limits和Redis日志确保生效。
Redis主从复制连接数不够，maxclients 是第一道关卡
Redis 主从复制失败、从节点日志反复出现 Connection refused 或 Client closed connection，但网络和认证都正常——大概率是 maxclients 被耗尽了。Redis 默认只允许 10000 个客户端连接，而每个从节点至少占用 2 个连接（一个用于命令同步，一个用于 PSYNC 的 backlog 传输），再加上业务客户端，很容易撞上限。
实操建议：
-
maxclients必须在主节点和从节点上分别设置，主节点压力更大，建议优先调高 - 修改
redis.conf中的maxclients值（例如maxclients 20000），然后重启 Redis 或执行CONFIG SET maxclients 20000（注意：动态设置不持久化） - 确认当前已用连接数：
INFO clients查看connected_clients和client_recent_max_input_buffer等指标 - 若
maxclients设得过高但启动失败，Redis 会报错ERR maxclients cannot be set to a value less than the current number of clients，需先 kill 部分连接或等低峰期再调整
Linux 文件描述符限制（ulimit -n）比 maxclients 更底层
Redis 启动时会检查系统级文件描述符上限，如果 ulimit -n 小于 maxclients + 32（Redis 自身预留），它会自动把 maxclients 降低到 ulimit -n - 32，且不报错、不提示——这是最隐蔽的“调了没用”原因。
实操建议：
- 运行
ulimit -n查看当前 soft limit；用ulimit -Hn查看 hard limit - 临时提高：在启动 Redis 前执行
ulimit -n 65536（仅对当前 shell 及子进程有效） - 永久生效需改三处：
/etc/security/limits.conf（加redis soft nofile 65536和redis hard nofile 65536）、/etc/systemd/system/redis.service中添加LimitNOFILE=65536（若用 systemd）、确保pam_limits.so已启用 - 改完必须重启 Redis 进程，且验证方式不是只看
ulimit -n，而是用cat /proc/$(pidof redis-server)/limits | grep "Max open files"
主从连接被当成普通 client，无法绕过 maxclients
有人误以为主从复制走的是内部通道，不受 maxclients 约束——完全错误。Redis 把每个从节点当作一个普通 client 连接处理，同样计入 connected_clients 计数，同样受 maxclients 和系统 ulimit 双重限制。
实操建议：
- 不要试图用
replica-announce-ip或replica-announce-port来“欺骗”连接逻辑，它们只影响从节点对外广播的地址，不改变连接计数行为 - 监控主节点的
INFO replication输出中connected_slaves是否稳定；若频繁断连且connected_clients接近maxclients，基本可锁定为连接数瓶颈 - 若集群规模大（比如 1 主 10 从），单主模式下光从节点就占 20+ 连接，务必预留足够余量给业务 client，别刚好卡在 10000 边界
调整后仍断连？检查 tcp-backlog 和内核参数
即使 maxclients 和 ulimit 都调够了，主从握手阶段仍可能因 TCP 连接队列溢出而失败，表现为从节点日志里 connect: Connection refused 或主节点 socket error，但 netstat -s | grep -i "listen overflows" 显示非零值。
实操建议：
- 在
redis.conf中显式设置tcp-backlog 511（Linux 默认值常为 128，不够高并发握手） - 同步调高内核参数：
echo 511 > /proc/sys/net/core/somaxconn，并写入/etc/sysctl.conf持久化 - 确认 Redis 启动日志里有
Server initialized且包含backlog=511字样，否则配置未生效 - 这个参数只影响 TCP 三次握手完成前的等待队列，和
maxclients无直接关系，但它是主从连接建立的第一道门
真正卡住主从复制的，往往不是配置项本身，而是 ulimit 和 maxclients 的隐式联动，以及 tcp-backlog 这种容易被忽略的底层缓冲区。调参之后不验证 /proc/*/limits 和 Redis 日志里的实际加载值，等于没调。
