热点流量引发的雪崩

 

计数服务访问情况

Redis计数服务一直运行的比较稳定，国庆期间总体QPS量比较稳定，没有突破历史新高，不过连续两天发生大规模的超时，并导致服务产生雪崩效应，通过紧急降级才免于彻底瘫痪。

 

Mget接口的请求QPS

 

 

场景一

• 服务多个接口耗时加长，导致下游用户超时严重，产生雪崩效应，导致很多接口不出结果
• 故障持续了2-3个小时
• 排查服务运行指标，当时没有看出特别的状况

Redis实例CPU飚高

 

 

部分节点创建新连接数量激增[通常每秒2-3个]

 

redis节点处理请求数量

 

 

场景二

• 情况与场景一类似
• 影响时间1小时
• 细致排查了N多指标，发现个别redis节点上创建新连接数量增多

Redis实例CPU打满

 

部分节点创建新连接数量激增[通常每秒2-3个]

 

请求Redis p99的RT爆涨

 

 

redis节点处理请求数量

 

 

问题归纳

• Redis缓存用来解决99%的缓存需求，剩余1%的缓存需求还是要有其他方案来解决
• Redis是单线程模型，请求要顺序来处理，高频访问会导致请求进入等待队列，这会产生大量超时请求
• 大并发的热点请求超时，没有多级缓存、降级、合并同源的等策略的处理，会把影响范围放大。
• 同一个Redis实例上CPU使用率飚高，一定是少量Key刷量导致。

 

初步解决方案

• 增加连接池的minIdle & minIdle & maxTotal减少创建连接开销【临时方案，杯水车薪】
• 使用类似guava这样的LRU缓存在调用端建立二级缓存用来挡掉高频请求，超时设置3-5秒。