Redis连接数老被限制，怎么突破那死板的重置极限呢？

“Redis连接数老被限制，怎么突破那死板的重置极限呢？”这个问题，说白了就是你家Redis的大门（端口）每次只能让固定数量的人（客户端连接）同时进来，现在人多了，门口挤爆了，后面的人死活进不来，报错就是“max number of clients reached”，这扇门的大小，是由Redis配置文件里一个叫maxclients的参数决定的，想突破这个“死板”的极限，不能光靠蛮力把门拆了，得讲究方法，不然房子（服务器）都可能塌掉。

最直接也是最应该先检查的一招,就是看看现在这个门到底被谁占着不干正事，根据Redis官方文档里的说明，maxclients的默认值是10000，但很多操作系统单进程能打开的文件描述符数（每个网络连接都算一个）可能比这个低，所以实际可能还不到10000，你得先连上Redis，用INFO clients命令看看connected_clients这个数是不是真的快到顶了，更狠的是用CLIENT LIST命令，把现在所有连接者的老底都翻出来，看看是不是有一大堆连接挂着但啥也不干（比如idle空闲时间特别长），或者是不是有某些客户端建立了连接忘了关，成了“僵尸连接”，把这些没用的连接清理掉（用CLIENT KILL命令），瞬间就能腾出不少空位，这就像是先把堵在门口聊天不进去的人劝走，立竿见影。

光清理治标不治本,你得想想，为啥连接数会不够用？是不是你的应用程序写得有问题？根据一些常见的开发规范，比如一些技术社区像Stack Overflow上经常讨论的，一个常见的坏毛病就是每次需要操作Redis时都新建一个连接，用完了也不关，或者关得不及时，这相当于每来一个客人就现凿一扇门，客人走了门也不封上，资源很快就耗光了，正确的做法是使用连接池，连接池就像是设立一个接待处，预先建好一批连接放着，应用程序需要用时，从池子里借一个，用完了马上还回去，而不是销毁，这样就能保证同时存在的连接数量是可控的，大大减轻Redis的压力，这是从根本上解决问题的最有效手段之一，比你单纯去调高极限值要聪明得多。

如果经过分析,你的业务场景确实非常特殊，就是需要同时处理海量连接，比如有成千上万的用户设备需要长连接通信，那确实需要考虑提高maxclients这个上限值本身，这个设置藏在Redis的配置文件redis.conf里，你找到maxclients 10000这一行，把数字改大就行了，比如改成maxclients 20000。这里有个巨大的坑：根据操作系统层面的知识，比如Linux的ulimit设置，Redis进程能打开的最大文件数（包括连接）受限于操作系统给它的限制，你要是光把maxclients改成50000，但系统限制单个进程最多只能打开10000个文件，那屁用都没有，你必须同时去提高操作系统的文件描述符限制，在Linux下，可以用ulimit -n查看当前限制，修改的话需要调整/etc/security/limits.conf文件，给运行Redis的用户增加限制，比如redis soft nofile 65535和redis hard nofile 65535，重启Redis和可能需要的系统登录后，新的限制才能生效，这一步操作有风险，设得太高可能会耗光系统资源，影响其他进程，所以需要谨慎。

除了上面这些,还有一些进阶的招数可以考虑，如果读操作远多于写操作，可以搭建一个主从复制（Replication） 架构，让一个Redis实例（主节点）负责写，然后挂多个Redis实例（从节点）负责读，这样，可以把读请求分散到不同的从节点上，每个从节点承受的连接数就降下来了，这就不是扩大一个门了，而是多开几个门分流，效果非常好，定期检查Redis的慢查询日志，优化那些执行时间太长的命令，因为一个慢命令会长时间占用一个连接，导致连接得不到释放，间接导致连接数紧张。

还有一个邪道,但有时候不得不用的方法：设置连接的空闲超时时间，在redis.conf里有个timeout参数（单位是秒），如果客户端连接空闲超过这个时间，Redis服务器就会主动把它踢掉，这能有效清理那些因为客户端异常退出等原因留下的“僵尸连接”，给新连接腾地方，但设置这个要小心，如果你的应用有长时间空闲的长连接需求，就不能设得太短。

突破Redis连接数限制,不能傻乎乎地只知道改大maxclients那个数字，正确的思路是：先排查清理无用连接治标，再优化应用使用连接池治本，最后根据实际需要和系统能力，考虑调整系统限制和Redis配置，必要时通过架构扩展（如主从）来根本性提升容量。 盲目提高上限而不解决连接泄露或低效使用的问题，就像试图用一个更大的桶去接一个漏水的管子，最终只会浪费更多资源，甚至拖垮整个系统。”