Redis连接老是慢，拿连接像打怪一样折腾半天才行

这事儿说起来真是让人火大,我们项目里用Redis，本来指望着它像闪电一样快，结果呢？现在每次去拿个连接，都跟玩一个特别垃圾的网络游戏似的，打个小怪（也就是拿个连接）都得折腾半天，血瓶（耐心）都快喝光了，BOSS（业务高峰期）的面儿还没见着，这感觉，就像你急着上厕所，跑到门口发现每个坑位都有人，而且里面的人还在不紧不慢地玩手机，你说急不急人？

我记得特别清楚,最开始根本没这毛病，那时候，代码里随便一写，连接“嗖”一下就拿到了，数据存取也是眨眼的事儿，那叫一个顺畅，可不知道从什么时候开始，这连接就变得越来越“金贵”了，尤其是每天上午十点多，下午三点多，系统访问量一上来，日志里就开始噼里啪啦地报错，满屏的“Timeout waiting for connection from pool”，翻译成人话就是：“连接池里没闲着的连接了，您老等着吧！”

等？业务可等不起啊，用户在前端点个按钮，转了半天圈圈，最后给你来个“系统繁忙，请稍后再试”，这用户体验，简直了，我们团队一开始也懵，以为是Redis服务器本身挂了，赶紧登录服务器去看，结果Redis自个儿优哉游哉的，内存也没满，CPU也挺闲，就好像在说：“我这儿宽敞着呢，是你们自己不过来啊。”

那问题肯定就出在连接池这边了,这个连接池，你可以想象成是Redis服务器门口的一个“自行车租赁点”，程序需要跟Redis打交道的时候，就来这个租赁点借一辆自行车（连接），用完了再还回来，理想情况下，车源充足，随借随还，但我们遇到的情况是：高峰期想借车的人太多了，车一下子就被借光了，后面来的人只能干等着，等到有人还车为止，有时候等得太久，租车点管理员（连接池的超时设置）一看，这人等了超过30秒了，干脆不等了，直接告诉他“没车了，你走吧”（抛出超时异常）。

这还不算最坑的,你明明看到有辆车停在车棚里（连接池显示有空闲连接），但你过去一推，发现这车链子掉了（这个连接其实已经失效了），因为你没办法保证每次还回来的车都是完好无损的，可能服务器那边因为网络波动或者自己重启了一下，这个连接其实已经断开了，但还车的人不知道，还是把它还回了车棚，下一个倒霉蛋兴冲冲地借到这辆“坏车”，一骑上去肯定摔跟头（操作失败），这就像我们遇到的另一种情况：偶尔能拿到连接，但一执行SET或GET命令就报错，说连接已经关闭，这种问题更隐蔽，更让人头疼。

后来我们被逼得没办法,开始像侦探一样排查，首先怀疑的是不是连接池设置得太小了啊？比如默认可能是8个最大连接，平时够用，高峰期肯定捉襟见肘，我们就试着把这个数字调大，调到50，甚至100，嘿，你别说，刚开始好像有点用，报错少了点，但没过多久，老毛病又犯了，而且Redis服务器那边开始喊压力大了，因为同时连接的客户端太多了，它也有点吃不消，看来光靠增加连接数，就像是靠增加自行车数量来解决交通拥堵，不是根本办法，反而可能把停车场（服务器资源）挤爆。

然后又怀疑,是不是有人借了车不还啊？也就是代码里有地方拿到了数据库连接，用完了忘记关闭了，这就好比有人借了辆自行车，骑到家门口就往那一扔，再也不管了，这辆车就永远回不到租赁点，可用的车就少了一辆，这种“连接泄漏”是最可怕的，时间一长，再大的连接池也会被耗光，我们只好一行行代码地去检查，特别是那些复杂的业务逻辑和异常处理分支，确保在任何情况下，借出去的连接最终都能被归还，这事儿特别繁琐，跟大海捞针似的。

还有那些“坏车”（失效连接）的问题，我们得让租赁点有个自动检修机制，就是连接池在把车借出去之前，先偷偷试骑一下，看看这车还好不好使（执行一个简单的PING命令测试连接是否有效），如果坏了，就赶紧扔掉，换一辆好的给用户，这个机制一开，那种拿到连接却操作失败的诡异问题果然少了很多。

一番折腾下来,总算是勉强把这个“打怪”的难度从地狱模式降到了困难模式，但这个过程真的太磨人了，完全违背了使用Redis就是为了“快”的初衷，我现在算是明白了，Redis本身快是真的快，但通往Redis的这条“路”——也就是连接管理——要是不通畅，你再好的跑车（Redis）也跑不起来，这玩意儿就是个细致活，连接池大小、空闲时间、超时时间、验证查询等等，一大堆参数都得根据实际情况慢慢调，没有一个放之四海而皆准的万能配置，而且还得时刻盯着监控，指不定业务量一增长，或者哪个程序员小哥一不小心又写了个泄漏连接的BUG，这“打怪”的戏码就又得重新上演一遍，唉，说多了都是泪。