人在公司做，祸从天上来。监控报出来很多慢接口...
监控出现了很多慢接口，使用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性能问题？
- 在Grafana看板上：查询
Command Calls / sec指标。 - 在Grafana看板上查看服务的
流量数据。
发现其峰刺出现的时间点并不吻合，不是高流量引发的Redis竞争问题。
2. 问题定位
通过以上排查，看不出自己项目代码有任何问题？那么是不是腾讯云redis出现故障了？
腾讯云redis架构.png
云服务器是我们系统，Redis分片节点是真正的存储中心。中间的Proxy出现问题，也可以导致Redis出现慢查询呀！
3. 水落石出
在腾讯云redis控制台：
腾讯云proxy慢查询.png
腾讯云redis慢查询.png
由此可知：我们系统本身是没有问题的，而是腾讯云自己出现的故障。
将问题交给腾讯云客服，给出的答案是cache节点抖动导致，然后进行了数据迁移。最后问题解决了
4. 经验教训
- redis出现故障的排查思路。
- 因为购买的是腾讯云Redis服务，所以开始的排查方向是自己项目某些代码所致。在排查陷入困境的时候，可以考虑Redis本身是不是出现问题。
