一、业务背景

????公司的业务场景主要是利用Redis来做集群节点间session共享；

二、报错原因

????Timeout wait for idle object意即Redis连接池里面没有空闲连接，没有空闲连接那说明池里面的连接泄漏或者连接始终保留active状态被占用（即Redis是阻塞状态，所有命令阻塞，保持active连接）； ???? 由于代码上线很久，同时最近没有改动过，所以连接泄漏的情况是可以忽略的； ????那么我们直接排查Redis阻塞的问题；

三、排查过程 1. 确认问题的时间点

????????由于我们排查的是历史原因，只能提供查询slowlog、redis.log 、info命令来获取一些信息；所以非常有必要确认问题的发生时间点，由上述截图可知，报错时间点是在17点38分38秒；

2. 查询redis.log

????redis.log日志我们主要查询一些日志报错、RDB信息输出、集群信息等； ????如图，在相关时间附近进行了大量的copy-on-write操作，即出现了大量的Redis内存数据修改操作；

3.查询redis.conf

????????这时我们再查redis.conf 里面查询到的maxmemory是6G，相当于短时间内修改了1/3数据；此处截图未提供；

4. 查询info信息

????????确认上一次rbd的fork耗时及时间，耗时不大，最多10几ms，可以忽略这方面的影响；此处截图未提供；

5. 查询slowlog

????????查询历史的慢查询，存在以下zrem命令并发执行，且处理的的数据量大 ????????个别的del删除对象操作； ????由于我们排查的时间点是18点以后， 客户环境大部分人员已经下班，所以业务请求并不高，几乎没什么人访问； ????在这种状态下，我们都可以查到arem的删除对象，且存在历史的并发删除的情况；所以zrem在业务并发高的情况下导致问题的可能性极大；

6. 查询当前时间的monitor命令

????????基本没有什么业务并发；无 实际参考价值；

四、结论及解决方案

????主要结论由来： ????处理方案： ????????告知相关业务开发，如何导致问题，比如此处是存在并发rem删除大对象，处理上需要： ????????1. 规避zrem使用 ????????2. 减少频率 ????????3. 减少zrem的对象大小，同时减少频率；

????处理结果： ????????由于这个是和session相关的，客户环境当天下午出现了多次，直到服务苦苦支撑到下班时间点；如果问题不及时排查，那么第二天二次出现问题的概率是及其大的； ????????当时也给提供的了以下的临时方案： ??????????? 停redis，删除清理RDB文件，或者flushall redis,使redis的数据量最小； ????????最终在开发的紧急处理下，出了修复包，第二天正常到现在未出现问题；

---

1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，会注明原创字样,如未注明都非原创，如有侵权请联系删除！；3.作者投稿可能会经我们编辑修改或补充；4.本站不提供任何储存功能只提供收集或者投稿人的网盘链接。