一、业务背景

    公司的业务场景主要是利用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的数据量最小；
        最终在开发的紧急处理下，出了修复包，第二天正常到现在未出现问题；