maxclients作用于每个Redis实例（节点）而非整个集群，集群中6个节点需单独配置；其实际生效值取配置值与系统ulimit -n的较小值，且slave节点因承担复制和读请求双重压力更易触顶。
Redis集群里maxclients配置到底作用在哪儿？
它**不作用于整个集群**，而是作用在**每个 Redis 实例（节点）上**。集群中 6 个节点，每个都得单独配 maxclients，否则某个节点被单个客户端疯狂建连（比如连接池没回收、脚本死循环重连），照样会触发 ERR max number of clients reached。
常见误解是“配一次就管全集群”，结果只改了 master 节点，slave 节点爆满后主从复制失败，或客户端随机打到某个节点直接被拒。
-
maxclients是 per-process 限制，和是否集群模式无关 - 集群客户端（如 JedisCluster、redis-py-cluster）底层仍是多个独立连接，分别连不同节点
- 默认值通常是 10000，但 Linux 系统级限制（
ulimit -n）可能更低，实际生效的是二者较小值
为什么改了maxclients还是报连接数超限？
大概率是系统文件描述符没跟上。Redis 启动时会检查 ulimit -n，如果小于 maxclients + 32（预留系统用），就会自动把 maxclients 降到 ulimit -n - 32，且日志只写一句 WARNING: The TCP backlog setting of 511 cannot be enforced，完全不提连接数被砍的事。
- 先查当前限制：
ulimit -n（在 Redis 进程运行的用户下执行） - 临时调高：
ulimit -n 65536，再启动 Redis - 永久生效需改
/etc/security/limits.conf，加两行：redis soft nofile 65536redis hard nofile 65536 - systemd 启动还要额外配
LimitNOFILE=65536在 service 文件里
客户端连接暴增却找不到源头？用CLIENT LIST快速定位
别急着调大 maxclients，先确认是不是真有异常连接。在疑似过载的节点上执行：
CLIENT LIST TYPE normal
重点关注 addr（来源 IP）、age（存活秒数）、idle（空闲秒数）、cmd（最后命令）字段。常见问题：
- 大量连接
idle超过 300 秒，但cmd是NULL→ 客户端没设 timeout 或连接池泄漏 - 同一
addr短时间新建数百连接 → 某个服务重启没做连接复用，或健康检查探针配错 -
addr显示127.0.0.1:x且age很小 → 本地监控脚本每秒连一次，没用 pipeline 或 connection reuse
集群环境下更稳妥的连接控制策略
单靠 maxclients 是被动兜底，主动防控要分层：
- 应用层：所有客户端必须设连接超时（
connectTimeout、socketTimeout）、启用连接池（如 JedisPool 最大 idle 数 ≤maxclients * 0.3） - 代理层：如果用了 Twemproxy 或 redis-exporter + nginx，可在代理侧限流（如 nginx 的
limit_conn） - 运维层：用
redis-cli --cluster check定期扫节点连接数，告警阈值设为maxclients * 0.7 - 注意：Redis 本身不支持按 IP 或用户限连，ACL 只能控命令权限，不能控连接数
真正容易被忽略的是 slave 节点的 maxclients —— 它既要处理客户端读请求，又要接收 master 的 replication buffer，双重压力下比 master 更早触顶。
