## 事故背景 公司最近安排了一波商品抢购活动，由于后台小哥操作失误最终导致活动效果差，被用户和代理商投诉了。经理让我带同事们一起复盘这次线上事故。 ## 什么原因造成的？ 抢购活动计划是零点准时开始， 22：00 运营人员通过后台将商品上线 23：00后台小哥已经将商品导入缓存中，提前预热 抢购开始的瞬间流量非常大，按计划是通过Redis承担大部分用户查询请求，避免请求全部落在数据库上。  如上图预期大部分请求会命中缓存，但是由于后台小哥预热缓存的时候将所有商品的缓存时间都设置为2小时过期，所有的商品在同一个时间点全部失效，瞬间所有的请求都落在数据库上，导致数据库扛不住压力崩溃，用户所有的请求都超时报错。 实际上所有的请求都直接落到数据库，如下图：  ## 什么时候发现的？ 凌晨01:02 SRE 收到系统告警，登录运维管理系统发现数据库节点 CPU和内存飙升超过阈值，迅速联系后台开发人员定位排查。 ## 为什么没有早点发现？ 由于缓存设置过期时间是2小时，凌晨1点前缓存可以命中大部分请求，数据库服务处于正常状态。 ## 发现时采取了什么措施？ 后台小哥通过日志定位排查发现问题后，进行了一系列操作： > 首先通过API Gateway（网关）限制大部分流量进来? > > 接着将宕机的数据库服务重启? > > 再重新预热缓存? > > 确认缓存和数据库服务正常后将网关流量正常放开，大约01：30 抢购活动恢复正常。 ## 如何避免下次出现？ 这次事故的原因其实就是出现了缓存雪崩，查询数据量巨大，请求直接落到数据库上，引起数据库压力过大宕机。 在业界解决缓存雪崩的方法其实比较成熟了，比如有： * **均匀过期** * **加互斥锁** * **缓存永不过期** **（1）均匀过期** 设置不同的过期时间，让缓存失效的时间点尽量均匀。通常可以为有效期增加随机值或者统一规划有效期。  **（2）加互斥锁** 跟缓存击穿解决思路一致，同一时间只让一个线程构建缓存，其他线程阻塞排队。  **（3）缓存永不过期** 跟缓存击穿解决思路一致，缓存在物理上永远不过期，用一个异步的线程更新缓存。  ## 结语 小编也是很有感触，如果一直都是在中小公司，没有接触过大型的互联网架构设计的话，只靠自己看书去提升可能一辈子都很难达到高级架构师的技术和认知高度。向厉害的人去学习是最有效减少时间摸索、精力浪费的方式。 我们选择的这个行业就一直要持续的学习，又很吃青春饭。 虽然大家可能经常见到说程序员年薪几十万，但这样的人毕竟不是大部份，要么是有名校光环，要么是在阿里华为这样的大企业。年龄一大，更有可能被裁。 小编整理的学习资料分享一波！ 送给每一位想学习Java小伙伴，用来提升自己。**[想要资料的可以点击这里免费获取](https://docs.qq.com/doc/DSmxTbFJ1cmN1R2dB)**  > 本文到这里就结束了，喜欢的朋友可以帮忙点赞和评论一下，感谢支持！