计数服务访问情况
Redis计数服务一直运行的比较稳定，国庆期间总体QPS量比较稳定，没有突破历史新高，不过连续两天发生大规模的超时，并导致服务产生雪崩效应，通过紧急降级才免于彻底瘫痪。
Mget接口的请求QPS
场景一
- 服务多个接口耗时加长，导致下游用户超时严重，产生雪崩效应，导致很多接口不出结果
- 故障持续了2-3个小时
- 排查服务运行指标，当时没有看出特别的状况
Redis实例CPU飚高
部分节点创建新连接数量激增[通常每秒2-3个]
redis节点处理请求数量
场景二
- 情况与场景一类似
- 影响时间1小时
- 细致排查了N多指标，发现个别redis节点上创建新连接数量增多
Redis实例CPU打满
部分节点创建新连接数量激增[通常每秒2-3个]
请求Redis p99的RT爆涨
问题归纳
- Redis缓存用来解决99%的缓存需求，剩余1%的缓存需求还是要有其他方案来解决
- Redis是单线程模型，请求要顺序来处理，高频访问会导致请求进入等待队列，这会产生大量超时请求
- 大并发的热点请求超时，没有多级缓存、降级、合并同源的等策略的处理，会把影响范围放大。
- 同一个Redis实例上CPU使用率飚高，一定是少量Key刷量导致。
初步解决方案
- 增加连接池的minIdle & minIdle & maxTotal减少创建连接开销【临时方案，杯水车薪】
- 使用类似guava这样的LRU缓存在调用端建立二级缓存用来挡掉高频请求，超时设置3-5秒。