先说结论
大量缓存在同一时期失效，此时大量的流量会全部冲击到数据库上面,数据库有可能会因为承受不住而宕机
故障现象
问题影响现象：系统卡顿
故障处理过程
9:12监控群收到响应时间异常告警
9:18 通过ARMS查到的结果显示接口都比较快。
9:30 通过ARMS查到的接口只是显示health接口慢，还没有看到哪些服务慢，但是线上实际情况就是慢。
9:39 研发看到慢的接口（链路追踪）
9:44 测试从ARMS看到慢的接口
9:46 研发决定重启dyna服务
9:53 发现ARMS监控到的只有grpc接口，而目前调的都是ice接口，所以不能用ARMS看链路。
9:59 dyna重启好了
10:02 研发发现ARMS和Tracing的实时数据差距很大
10:19 通过查日志，发现确实很慢，而ARMS没有监控到，是因为ice接口没有被监控的缘故
11:29 查到日志里显示，是redis很慢
12:01 查到数据库的执行记录，发现表单加载次数多，2分钟内加载2000多次。
12:02 测试确认前天晚上发版时清除了表单的缓存。
确定原因，缓存清除后，早上客户使用时都从数据库加载，然后往redis写，所以会比较慢，同时redis响应也可以证明有大量数据在写。
故障原因
发版之后清除了dyna的redis缓存，导致使用时从数据库读取，而拖慢整体性能。
反思与改进方案
修复方案:
重启dyna服务（可能不用重启也可以慢慢变快）。
存在的问题：
1.不知道ARMS没有监控ice服务，所以一开始找错方向。
改进方案：
1.缓存清除可以指定key，而不是批量一次性清除。
- 缓存清除后，可以自动加载
- 改成gRPC服务
