应先检查是否连接泄露，再调整maxclients：通过redis-cli client list确认连接是否持续增长，修复Jedis未close问题；若确需扩容，须同步调高系统ulimit -n并重启Redis。
Redis 报 ERR max number of clients reached 怎么办
直接原因是 Redis 实例当前活跃连接数已达到 maxclients 上限，新连接被硬拒绝。这不是“慢”，而是彻底拒收——哪怕只超 1 个连接，JedisConnectionException: Could not get a resource from the pool 就会立刻抛出。
先改配置：增大 maxclients 但别乱设
盲目调高 maxclients 可能掩盖真实问题，甚至压垮系统。必须结合实际资源评估：
-
maxclients默认值通常是 10000，但实际可用数受系统级限制（如ulimit -n）制约，需同步检查：运行redis-cli info server | grep process_id得到 PID，再执行cat /proc/<pid>/limits | grep "Max open files"</pid> - Linux 系统默认
ulimit -n常为 1024，远低于 Redis 配置值，此时 Redis 启动时日志会警告WARNING: The TCP backlog setting of 511 cannot be enforced，且实际生效的连接上限就是 ulimit 值 - 修改方式：在
/etc/redis/redis.conf中取消注释并设值，例如maxclients 20000；同时用sudo systemctl edit redis添加LimitNOFILE=65536，再sudo systemctl daemon-reload && sudo systemctl restart redis
Jedis 连接池没关干净，比 maxclients 不够更常见
绝大多数生产环境的 max number of clients reached 并非因为并发真高，而是客户端连接泄露——Jedis 资源没归还，连接一直卡在 ESTABLISHED 状态，redis-cli client list | wc -l 会持续上涨。
Redis Skill - 高性能缓存管理
下载
Redis 缓存和数据结构管理技能。通过自然语言操作 Redis，支持 String、Hash、List、Set、ZSet、Stream 等数据结构操作。当用户提到 Redis、缓存、消息队列、会话存储时使用此技能。
- 典型错误写法：
Jedis jedis = pool.getResource(); jedis.set("k","v"); // 忘了 close()—— 即使加了try-finally，若jedis.close()放在 finally 外或被吞异常，照样泄露 - 正确姿势：必须确保
jedis.close()在 finally 中执行，且 JedisPool 配置要启用校验：config.setTestOnBorrow(true)和config.setTestOnReturn(true)，避免把失效连接塞回池子 - 快速验证：用
redis-cli client list查看 client addr 和 age 字段，如果大量连接 age 持续增长、addr 固定不变，基本锁定是某台应用机器的连接池未释放
云数据库 Tair（兼容 Redis）要额外注意白名单和 Sentinel 兼容
阿里云 Tair 实例不是改完 maxclients 就行——它有两层访问控制，漏掉任一都会表现为“连接被拒绝”而非“连接数超限”，但日志里可能混着报错。
- 如果错误信息含
ERR illegal address：说明客户端 IP 不在实例白名单中，去控制台「网络与安全」→「白名单设置」补上 ECS 或本地出口 IP - 如果错误含
ERR sentinel compatibility mode is disabled：Tair 默认关闭 Sentinel 兼容，而某些老版 Jedis 客户端（如 2.x）初始化时会发SENTINEL GET-MASTER-ADDR-BY-NAME，必须进控制台「参数设置」开启sentinel_compatibility_mode - 这两项不解决，即使
maxclients设成 10 万，连接也根本建不起来，排查时容易误判为服务端瓶颈
真正难的不是调数字，而是区分清楚：是连接真多，还是连接没走？是服务端卡死，还是客户端在假死？查 client list 和 netstat -an | grep :6379 对比两端状态，比翻配置文件快得多。
