不可忘的一个值班日

1、描述事故

表现形式：
1）起初，收到告警通知，大概内容就是近1分钟内，某个pod的所有请求的RT都大于了2s。这时候觉得有点不对劲了，但没特别在意。内心想着2s还能接受吧。
2）然后，不间断的告警。这时发现某几个接口的95线都达到了8s。到这里就开始慌了。
3）再接着，系统的其它接口（一些逻辑比较简单的接口）响应都提示了“系统异常，请稍后再试”。这时可以理解为，部分系统挂了！

原因所在：
快速提取一些接口的调用链，分析了下，其中用到了redis scan命令。每次scan的count为1w，耗时80ms左右。这个时间还算正常，毕竟redis的key太多了，但意外的发现普通的get命令也耗时30ms左右。这个就有点离谱了，毕竟日常在几ms。
急忙联系dba协助，最终确定就是因为多次使用了scan，这个慢查询，导致redis所在系统的cpu过高，将其它的redis命令都阻塞住了。
其实单个接口耗时慢还不是很紧急，关键是其它接口只要用到了redis的，都会被阻塞住，毕竟redis是单线程的，毕竟当时redis的配置不是很高，属于单片，也就是所谓的1主1从。
由于我们的RPC框架使用的是Dubbo，默认是有超时重试的（默认重试：2次）！而且当时的超时时间竟然被设置成了10s。。。
知道意味着啥么？来举个栗子，若一次dubbo调用因为多次执行redis命令导致超时（不到10s不释放连接[狗头]，除非已经拿到响应数据），就说明此次调用失败，那好，dubbo会换一台机器再次发起调用，然后又被redis给拖到超时。唉，有没有一种雪上加霜的痛？

2、临时解决

首先代码层面肯定是要优化的，一些B端或C端的接口，禁用keys、不用scan。
但为了避免让事故持续，让dba快速升级redis架构，从单片升为3片。
最后cpu的100% 降到了 50%

3、汲取教训

• 认清慢查询对系统的危害性，真的可以拖垮整个系统
• 对于线上告警一定一定不要掉以轻心
• 遇到问题，不要追究谁的责任，优先把眼前的问题解决掉才是王道
• 善用redis，思考下为什么这么多key？能否将多个key整合到一起，使用hash、set等代替呢? redis key的存活时间是不是设置太长了呢？
• Dubbo的超时时间该如何取最佳值？