场景：随着线上redis所存储的key值原来越多，偶尔会遇到某个查询耗时很长的问题，刚开始并没有重视，随着业务量的增加和某些人对redis操作不规范，导致线上查询慢的发生概率越来越高，所以领导就找我和运维的人一起查找此类问题和解决办法，也顺便记录一下排查过程。
排查如下：
1，慢查询。因为发生频率很高，跟着运维一起分析了慢查询日志，发现没有要查的那条耗时很长的记录，配置的慢查询为0.1毫秒，根据慢查询的原理，说明redis单线程处理此条记录时在内存执行时耗时没有超过0.1毫秒。
2，排队等待时间，查询耗时的总时间=排队等待时间+执行时间+返回耗时，返回时间可以忽略不计，那有可能是排队等待时间耗时过长造成的，根据redis监控，当时连接数还没有达到配置的最大连接数，还是不能说明问题，这时又一个慢查询报出来，快速查看redis排队等待的连接数，还是很少，慢查询也没有，那说明等待时间也可以排除啦
陷入沉思.......
突然想到redis的RDB备份时，当数据量比较大时，会导致服务器停止几百毫秒或者1秒.........
3，让运维人员看了一下，现在线上redis的备份方式，果然是RDB，而且还是默认的
还只能是猜测，商量了一个解决办法，线上redis采用的是哨兵，1主2从，RDB发生在1主上，修改RDB发生的机器或者RDB修改为AOF，修改过后，暂时没发现有查询耗时很长的操作。