Redis连接时间老是长？聊聊那些优化小技巧和设置方法

Redis连接时间老是长？这个问题确实挺让人头疼的，尤其是在用户量一上来或者操作频繁的时候，感觉明明用了缓存，速度却没快多少，今天咱们就不聊那些深奥的原理，直接上干货，说说哪些地方可能出了问题,以及咱们自己能动手调整的一些小技巧和设置方法。

最该检查的就是网络。 这是最常见也是最容易被忽略的“隐形杀手”，你的应用程序和Redis服务器是不是离得太远了？应用服务器在北京，Redis服务器在上海，这光在路上跑一趟就得几十毫秒，如果网络本身再有点拥堵或者不稳定，连接超时就太正常了。首要的优化就是把应用和Redis尽量部署在同一个机房、同一个内网里，让它们“面对面”说话，速度自然就快了，如果用的是云服务,更要留意是不是选择了同一个可用区。

得看看你的连接池配置。 很多人以为连接池越大越好，其实不是那么回事，想象一下，一个游泳池就那么大，你一下扔进去几百号人，别说游泳了，转身都难，管理起来也更乱，数据库连接池也是这个道理，如果连接池设置得太大，Redis服务器需要花费大量的精力来维护这些连接，反而会增加负担，但如果设置得太小，当有很多请求同时过来时，新的请求就得排队等着有连接被释放，这也会导致连接等待时间变长。（参考自阿里云开发者社区的常见问题分析） 这个值没有绝对标准，你得根据自己的业务压力来测试调整，可以先从一个适中的值（比如50）开始，然后观察监控，如果经常出现等待连接的请求，就适当调大一点；如果发现Redis服务器CPU或内存占用很高,可能就需要调小一点。

Redis自身的配置文件中也有几个关键参数值得关注。 这些配置通常在 redis.conf 文件里。

• timeout 参数： 这个参数指的是，一个客户端连接空闲多少秒后，Redis会主动把它关闭，默认值可能是300秒（5分钟），设置这个的目的是为了释放闲置的资源，但如果你的应用场景是连接建立后，可能隔比较长一段时间才会有下一次请求，那么可能还没等到下次请求，连接就被服务器断开了，应用下次再用这个连接时，就会发现已经失效，只能重新建立连接，这个重建的过程就会带来延迟，你可以根据业务情况，适当调大这个值,或者确保你的客户端有自动重连机制。
• tcp-keepalive 参数： 这个参数是用来检测TCP连接是否还“活着”的，如果网络中间有个路由器宕机了，可能导致TCP连接实际上已经断了，但双方还不知道，这就是“死连接”，当应用试图用这个死连接去操作时，会等到一个超时错误，体验上就是卡住了，设置 tcp-keepalive（比如设为60秒），Redis会定期向空闲连接发送探测包，及时发现并清理死连接，让应用能更快地失败并重连，而不是傻等。（思路参考了Redis官方文档对持久连接的建议）
• maxclients 参数： 这是Redis同时允许的最大客户端连接数，如果你的应用并发量很高，而默认的10000个连接数不够用了，新的连接就会被拒绝，表现也是连接失败，你需要确保这个值设置得足够大,能够应对你的业务高峰。

再从客户端的角度看看。 尽量避免在循环体内部频繁地创建和关闭连接，这是最伤性能的做法之一，正确的做法是使用连接池，从池中获取连接，用完及时归还，如果业务允许，优先使用管道（Pipeline）或者批量操作命令（比如MSET, HMGET），比如你要插入100条数据，如果用循环执行100次SET命令，会产生100次网络往返时间（RTT），而如果用Pipeline，只需要一次网络往返，把100个命令打包发过去，再一次性接收结果,效率提升非常明显。

监控和慢查询日志是你的好帮手。 Redis提供了 SLOWLOG 命令来记录执行时间超过设定阈值的命令，你可以通过查看慢查询日志，找出是哪些“慢操作”拖累了整体性能，是不是用了 KEYS * 这种全表扫描的命令？是不是某个复杂查询的复杂度太高？找到这些元凶，进行优化（比如用SCAN替代KEYS，给热点数据加缓存等）,也能从根本上减少连接被长时间占用的可能。

优化Redis连接时间长的问题，就像一个老中医看病，得“望闻问切”，先从最简单的网络和连接池配置入手，这是见效最快的，然后再去调整Redis服务端的关键参数，让它更适应你的业务节奏，养成良好的客户端编码习惯，并借助监控工具持续观察，多管齐下,相信你的Redis连接速度会有不小的提升。