Redis连接老超时？这些参数调优技巧你得试试，别再卡壳了

Redis连接老超时确实是个烦人的问题，但别急着头疼，很多时候调整几个关键参数就能大大缓解，下面这些经过验证的调优技巧,你可以逐一试试。

别忽视最基础的：timeout参数。 根据Redis官方文档，这个参数控制客户端空闲多少秒后服务器主动关闭连接，默认是0，意味着永不关闭，但如果你设置了某个数值，比如300秒，那么空闲连接超过这个时间就会被断开，如果你的应用有长时间空闲的连接，突然发请求就会遇到“Connection reset by peer”之类的错误。（来源：Redis配置文档） 你可以检查你的业务场景：如果存在长时间空闲，要么将这个值设大，要么确保你的客户端有重连机制，相反，如果服务器连接数太多,适当调小它可以帮助回收资源。

检查一下TCP的“心跳”：tcp-keepalive。 这个参数很多人会忽略，Redis官方文档说明，这是为了检测死连接（比如客户端突然崩溃、网络链路中间断开），默认是300秒，这个间隔其实有点长，在一些不稳定的网络环境（比如云服务器跨可用区、跨地域），中间的网络设备可能会因为连接空闲而清理掉TCP会话。（来源：Redis配置文档） 你可以尝试将它调小，比如设置为60或120，让Redis更频繁地发送TCP保活包来维持连接，这样能更快发现并清理死连接,也让网络设备知道连接是活跃的。

第三个关键点是maxclients，也就是最大连接数。 如果这个值设置得过小，而你的应用并发量上来，新连接就无法建立，会直接收到超时或拒绝错误。（来源：Redis配置文档） 你可以通过INFO stats命令查看rejected_connections计数器，如果它在增长，就说明有连接因为超过最大限制被拒绝了，适当调高这个值（要确保你服务器文件描述符限制也足够）,能直接解决连接被拒的问题。

眼光要从Redis服务器移到你的客户端。 客户端的连接池配置不当是超时的最常见原因之一，你需要关注这几个点：（来源：Jedis、Lettuce等客户端文档及最佳实践）

1. 连接池最大/最小空闲连接数：别设得太小，如果业务并发线程是100，你池子里只保持5个连接，那大部分线程就要等待创建新连接，创建过程（包括TCP三次握手、Redis认证）一旦慢,就容易超时。
2. 获取连接的最大等待时间：这是关键！当连接池耗尽时，新的请求获取连接会等待这个时间，如果设置太短（比如1秒），池子稍微一忙就报超时，可以适当调长,但也要和你的业务接口超时时间协调。
3. 连接的健康检查：确保连接池能自动剔除已经坏掉的连接，配置一个“test-on-borrow”或定期测试的机制，避免把已经断开的连接（由于服务器timeout或网络闪断）发给业务使用,这种连接一用就超时。

还有一些外围的“坑”需要排查。 服务器操作系统的TCP backlog队列（对应Redis的tcp-backlog参数）如果满了，新连接也会被拒绝。系统内存不足时，操作系统可能会杀掉Redis进程，连接自然全断。慢查询也会导致连接被阻塞，看起来像超时，你可以用SLOWLOG GET命令看看有没有特别耗时的命令。

解决Redis连接超时，需要从服务器配置（timeout, tcp-keepalive, maxclients）和客户端连接池配置两头入手，再结合系统资源和慢查询进行综合判断，调整参数后，一定要在测试环境充分压测，观察效果，希望这些具体的点能帮你解决问题,不再卡壳。