Redis里那些缩短超时配置的小技巧，实操起来其实没那么复杂

说到Redis的性能调优，很多人会觉得头大，感觉要调整一大堆复杂参数，得像个专家一样才行，但其实，有一些特别实用的小技巧，专门针对那些“超时时间”的设置，操作起来非常简单，往往改个数字就能看到效果，特别适合咱们平时自己维护项目或者解决线上小毛病的时候用，这些技巧的核心思想就一个：别让Redis在那儿傻等,或者被一些不必要的连接拖垮。

咱们得知道Redis里最常见的两个超时配置是啥，一个叫 timeout，另一个叫 tcp-keepalive，这俩名字听起来有点技术,但理解起来很简单。

第一个小技巧：给闲置连接上个“闹钟”，别占着茅坑不拉屎。

这个就是调整 timeout 参数，这个参数是干嘛的呢？它决定了当一个客户端连接上Redis之后，如果过了多少秒这个客户端啥命令也没发，Redis就会主动把这个连接给关掉，默认值是多少呢？是0，0的意思就是“永远不关闭”。（来源：Redis官方文档关于timeout配置的说明）

你可能会想，不关不是挺好吗？连接留着下次用还快呢，话是这么说，但坏处也很明显，如果你的应用服务器有很多，或者有时候代码写得不好，连接开了忘了关，这些“僵尸连接”就会一直留在Redis服务器上，Redis能同时支持的连接数是有限的，如果这些名额都被闲置连接占满了，新的、真正要干活的客户端就连接不进来了，就会报“max number of clients reached”这种错误,服务就不可用了。

那该怎么办呢？特别简单，去Redis的配置文件redis.conf里，找到timeout这一行，把那个0改成一个合理的数字，这个数字设多少合适呢？这得看你的业务，如果你的应用是用户实时操作的那种Web服务，可能设置个300秒（5分钟）就足够了，想象一下，一个用户操作完网页，5分钟都没动静，这个连接基本可以认为是废弃了，如果你设成60秒，那就更严格一些，原则是设一个比你的应用连接池闲置超时时间稍长一点的值就行，避免你的应用刚准备用这个连接，结果被Redis提前掐断了，改完之后重启Redis或者用CONFIG SET命令在线生效,立马就能防止连接数被慢慢耗光的问题。

第二个小技巧：定期“摸摸”客户端，看看它是不是还“活着”。

这个技巧跟 tcp-keepalive 参数有关，它跟上面的timeout不是一回事。timeout是应用层的超时，而tcp-keepalive是TCP协议层面的一个机制，它的作用是：即使线路上没有数据传送，Redis服务器也会定期向客户端发送一个很小的探测包（ACK包），目的是检查这个TCP连接是不是真的还通着。（来源：Redis官方文档关于tcp-keepalive配置的说明）

为什么需要这个呢？因为网络世界很复杂，客户端可能因为网络故障、机器突然宕机等原因，没有来得及正常地断开连接，从Redis服务器这边看，这个连接还在，但它实际上已经是个“死连接”了，如果没有探测机制，这个死连接会一直存在,同样会占用连接名额。

Redis默认的tcp-keepalive值是300秒（5分钟），也就是说，每隔5分钟会探测一次，这个值对于大多数情况已经不错了，但如果你所处的网络环境特别不稳定，或者你对服务的及时性要求非常高，希望尽快释放死连接，你可以把这个值调小一点，比如调到60秒，这样，最多一分钟就能发现一个死连接并清理掉，调这个参数也是在redis.conf文件里修改tcp-keepalive那一项，这个技巧能帮你更及时地清理网络故障导致的“幽灵连接”。

第三个技巧：给慢查询设个“门槛”，别让一颗老鼠屎坏了一锅粥。

这个涉及的不是网络连接超时，而是命令执行超时，配置项叫 slowlog-log-slower-than，Redis可以记录下那些执行时间特别长的命令，也就是“慢查询”，这个配置项的单位是微秒，默认值是10000微秒，也就是10毫秒。（来源：Redis官方文档关于slowlog-log-slower-than配置的说明）

听起来10毫秒挺短的？但对于内存操作的Redis来说，一个命令执行超过10毫秒，已经算很慢了，很可能是个隐患，比如不小心用了KEYS *命令，或者对一个大的集合进行了复杂的操作，通过查看慢查询日志（用SLOWLOG GET命令）,你能快速定位到是哪些命令拖慢了Redis。

那这个小技巧是什么呢？就是根据你的业务容忍度，灵活调整这个门槛，如果你的业务对延迟非常敏感，希望把所有潜在慢操作都抓出来，你可以把它设得更小，比如5000微秒（5毫秒），反之，如果你的Redis负载很重，只想关注那些真正特别慢的“元凶”，可以把它设大一点，比如20000微秒（20毫秒），这能让你更有针对性地优化代码，避免某些坏查询影响整体性能，设置方法同样是在配置文件修改，或者在线CONFIG SET。

第四个技巧：在客户端这边也要“守时”，别光指望服务器。

上面说的都是在Redis服务器端的配置，但一个巴掌拍不响，超时问题很多时候也需要客户端配合，在你的应用程序代码里，使用Redis客户端库时,一定要设置合理的连接超时和读写超时参数。

连接超时（connection timeout）设成1-2秒，如果连不上就快速失败，别无限重试，读写超时（socket timeout）要根据你通常操作的命令耗时来定，比如设成3-5秒，这样，万一网络出现波动，或者Redis服务器真的因为某些原因变慢了，你的应用程序不会无休止地等待下去，而是能快速超时，抛出异常，然后你可以根据逻辑进行降级处理（比如从数据库读旧数据），保证主流程不卡死,这比服务完全僵死要好得多。

这几个小技巧——设置timeout清理闲置连接、调整tcp-keepalive探测死连接、利用slowlog抓出慢查询、在客户端也配置超时——都是动一动配置数字就能做的事，不需要高深的理论，但对付日常开发中遇到的连接数爆满、响应变慢、服务挂起这类问题，效果却是立竿见影的，下次再遇到Redis闹脾气，不妨先从这几个地方看看,说不定简单调一调就药到病除了。