必须在每个节点单独配置maxclients，因为它是per-process限制，集群中各节点为独立进程，slave节点还需承担读请求和主从复制双重连接压力，若仅配master会导致slave触顶、主从断连。
必须在每个节点单独配 maxclients，集群不共享连接限制，只配 master 会出问题。
为什么 maxclients 要逐个节点配置
Redis 集群里每个节点（包括 master 和 slave）都是独立进程，maxclients 是 per-process 限制，不是集群维度的全局开关。客户端通过 JedisCluster 或 redis-py-cluster 连接时，底层仍是分别建立多个 TCP 连接到不同节点；某个 slave 节点被大量读请求打满，maxclients 触顶后可能直接拒绝复制连接，导致主从断连、数据不一致。
常见错误操作：只改了 3 个 master 的 maxclients，6 个 slave 没动，默认值 10000 在高读场景下很快耗尽，但监控只显示 “主节点正常”，问题定位困难。
maxclients 实际生效值经常被系统限制砍一刀
即使你在 redis.conf 里写了 maxclients 65536，Redis 启动时会检查当前用户的 ulimit -n，取二者较小值作为真实上限，并悄悄降级——日志里只报一句 WARNING: The TCP backlog setting of 511 cannot be enforced，完全不提连接数被砍的事。
Redis 8.2.3 是一款安全优先的高性能键值存储系统。该版本紧急修复了可能引发远程代码执行（RCE）的高危漏洞（CVE-2025-62507），并解决了 HyperLogLog 及 Cuckoo Filter 等数据结构在特定场景下的崩溃问题。建议所有用户立即升级，以保障生产环境的系统稳定与数据安全。
- 查当前限制：
ulimit -n（务必在 Redis 运行用户下执行，比如sudo -u redis ulimit -n） - 临时生效：
ulimit -n 65536，然后重启 Redis - 永久生效：在
/etc/security/limits.conf加两行：redis soft nofile 65536和redis hard nofile 65536 - 如果用 systemd 启动，还要在
.service文件里加LimitNOFILE=65536
怎么快速确认是不是真有连接泄漏或异常重连
别一上来就调大 maxclients，先用 CLIENT LIST TYPE normal 看连接明细：
-
addr字段集中在一个 IP + 端口（如10.20.30.40:56789），且age很小（idle 接近 0 → 很可能是健康检查脚本每秒新建连接，没复用 - 同一
addr出现几百个连接，cmd全是NULL，idle> 300 → 客户端没设 socket timeout，连接池没回收，或应用重启没 close pool -
addr是127.0.0.1:x，age波动剧烈 → 本地监控 agent（如 Prometheus exporter）直连没走连接池
光靠 maxclients 是兜底，不是防控
它只在连接已建立后拒新连，对短连接风暴或连接池爆炸毫无防御力。真正稳的做法是分层控制：
- 应用层：所有客户端必须设
connectTimeout和socketTimeout（比如 Jedis 默认是 2000ms，别留 0） - 连接池：最大 idle 数建议 ≤
maxclients * 0.3，避免某节点瞬间涌进 1000 个空闲连接 - 系统层：用
iptables限单 IP 并发（--connlimit-above 50），防扫描或 misconfig 服务狂连 - 运维层：把
INFO | grep connected_clients加进告警，触发阈值（比如 > 85%maxclients）立刻查CLIENT LIST
最易被忽略的一点：slave 节点的 maxclients 值通常要比 master 更高一点，因为它既要处理读请求，又要维持主从复制连接（replica client），而这个 replica client 也会计入 connected_clients 统计。
