那次折腾 Redis 连接问题，真是摸着石头过河的排查经历

那次折腾Redis连接问题，真是摸着石头过河的排查经历

这事儿得从一天下午说起，我们那个平时跑得好好的应用，突然开始隔三差五地报错，错误信息大概就是“无法连接到Redis服务器”，一开始，大家都没太当回事，觉得可能就是网络偶尔抽风，或者Redis服务器负载高了，重启一下应用服务，好像就能好一阵子，但后来，这问题发作得越来越频繁，从几天一次变成了一天好几次，严重影响了用户的正常操作，我们才意识到，这回是碰上硬茬子了,得下功夫深挖了。

我们的第一反应，当然是“甩锅”给网络，运维的同事拍着胸脯说服务器网络肯定没问题，但我们还是不死心，自己动手，在应用服务器上反复用 telnet 命令测试到Redis服务器端口的连通性，（来源：实际排查操作）奇怪的是，每次测试都是通的，丢包、延迟也都正常，这就怪了，网络明明是通的，为什么应用就是说连不上呢？这条路看来走不通。

既然网络没问题，那怀疑对象就转向了Redis服务器本身，我们登录上Redis服务器，看了看监控指标，CPU、内存占用都不高，connected_clients（连接数）也在合理范围内，（来源：Redis info命令查看）没有发现明显的异常，又把Redis的日志翻了个底朝天，除了几条慢查询记录，也没看到有连接失败的报错,服务器这边似乎也风平浪静。

没办法，只能回到应用的视角，我们仔细分析了报错的堆栈信息，发现错误并不是发生在建立新连接的时候，而是在从连接池里获取一个空闲连接准备使用时，发现这个连接已经断开了。（来源：应用日志堆栈分析）这下方向明确了，问题很可能出在连接池的管理上，是连接泄漏了？还是连接因为不活跃被服务器主动关闭了？

我们检查了应用配置的连接池参数，（来源：应用配置文件）比如最大连接数、最小空闲连接数、连接最大空闲时间等等，对比了官方推荐值，感觉设置得还算合理，为了验证是不是连接泄漏，我们还在测试环境用了个“土办法”：在应用启动后，模拟一段时间的压力，然后故意停掉Redis服务器，观察应用的反应。（来源：测试环境模拟）果然，应用抛出了大量连接异常，但关键是，在Redis服务恢复后，有些连接并没有被正常回收，导致连接池里的可用连接越来越少,这暗示我们代码里可能存在没有正确释放连接的情况。

我们开始了一场漫长的代码审查，重点排查所有与Redis交互的地方，特别是那些复杂的业务逻辑分支，比如发生了异常、或者提前return的地方，有没有漏掉关闭连接的操作。（来源：代码审查过程）果然，在一个不太起眼的工具方法里，我们发现了一段“罪魁祸首”代码：在一个try块里获取了连接，业务逻辑执行完后，在finally块里也写了关闭连接的语句，这看起来没问题，但坑爹的是，中间调用了一个其他部门提供的方法，那个方法内部自己又获取了一个新的连接，但它执行失败抛出异常时，竟然没有关闭它自己创建的那个连接！（来源：有问题的代码段）这就导致了这个连接永远无法被归还到连接池，也就是所谓的连接泄漏，随着时间推移，泄漏的连接耗尽了连接池，新的请求获取不到有效连接,就爆出了连接超时的错误。

找到根因后，修复就简单了，我们规范了连接获取和释放的代码模式，确保在任何情况下，获取的连接最终都能被释放。（来源：修复方案）为了保险起见，我们也适当调低了Redis服务器端的timeout参数，（来源：Redis配置调整）让服务器能更快地清理掉那些不活跃的“僵尸”连接,算是加了一道保险。

经过这番折腾，问题总算解决了，现在回想起来，整个过程就像摸着石头过河，从最表象的错误信息开始，先怀疑网络，再怀疑中间件服务，最后才聚焦到自身的应用代码和配置上，一步步排除，一步步逼近真相，最大的教训就是，对于资源的使用，尤其是像数据库连接这种稀缺资源，一定要慎之又慎，确保“谁申请，谁释放”，尤其是在异常情况下，释放的逻辑必须得到保证，以后再遇到类似问题,心里总算有点底了。