Redis连接数超限怎么解决？增大maxclients并排查泄露

Redis连接数超限（ERR max number of clients reached）看似是服务端配置问题，实则多由客户端连接泄露（如Jedis未正确close）引发，而非真实并发过高；解决时须先用redis-cli client list精准定位持续增长的“僵尸连接”，修复代码逻辑与连接池配置，再审慎扩容maxclients——必须同步调高系统ulimit -n并重启Redis，否则配置无效；云环境如阿里云Tair还需额外排查白名单和Sentinel兼容性，避免误判为性能瓶颈。真正关键在于厘清“连接真多”还是“连接没释放”，靠client list与netstat交叉验证比盲目调参高效得多。

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//limits | grep "Max open files"
• 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 会持续上涨。

• 典型错误写法：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 对比两端状态，比翻配置文件快得多。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《Redis连接数超限怎么解决？增大maxclients并排查泄露》文章吧，也可关注golang学习网公众号了解相关技术文章。