祸从天上来系列（1）线上Redis突然崩了？

人在公司做，祸从天上来。监控报出来很多慢接口...

监控出现了很多慢接口，使用skywalking的链路追踪，发现是问题出现在调用Redis。查询Redis的某些key时间500ms。

环境：使用的是腾讯云Redis集群

1. 排查思路

1. 由于Redis服务端是单线程的IO复用模型，考虑是不是该key查询出大对象导致redis被阻塞？

然后翻看业务代码，组装出Redis的key。在控制台调用发现，该key查询出来的对象并不是一个大对象。

2. 是一个key有问题，还是一些key有问题？

查询skywalking上的慢接口，发现是一些key存在问题，查询性能低。但是这些key并没有共通点。

判断下是否是热点key导致节点的访问量偏移。是不是节点性能问题造成的集群性能瓶颈。

3. 是不是有key*等耗时的操作？

查询Redis的调用日志（腾讯云提供）并没有发现key*等危险的命令。

4. 是不是高流量产生大量命令，导致Redis性能问题？

1. 在Grafana看板上：查询Command Calls / sec指标。
2. 在Grafana看板上查看服务的流量数据。

发现其峰刺出现的时间点并不吻合，不是高流量引发的Redis竞争问题。

2. 问题定位

通过以上排查，看不出自己项目代码有任何问题？那么是不是腾讯云redis出现故障了？

腾讯云redis架构.png

云服务器是我们系统，Redis分片节点是真正的存储中心。中间的Proxy出现问题，也可以导致Redis出现慢查询呀！

3. 水落石出

在腾讯云redis控制台：

腾讯云proxy慢查询.png

腾讯云redis慢查询.png

由此可知：我们系统本身是没有问题的，而是腾讯云自己出现的故障。

将问题交给腾讯云客服，给出的答案是cache节点抖动导致，然后进行了数据迁移。最后问题解决了

4. 经验教训

1. redis出现故障的排查思路。
2. 因为购买的是腾讯云Redis服务，所以开始的排查方向是自己项目某些代码所致。在排查陷入困境的时候，可以考虑Redis本身是不是出现问题。