事故背景

公司最近安排了一波商品抢购活动，由于后台小哥操作失误最终导致活动效果差，被用户和代理商投诉了。经理让我带同事们一起复盘这次线上事故。

什么原因造成的？

抢购活动计划是零点准时开始，

22：00 运营人员通过后台将商品上线

23：00 后台小哥已经将商品导入缓存中，提前预热

抢购开始的瞬间流量非常大，按计划是通过 Redis 承担大部分用户查询请求，避免请求全部落在数据库上。

如上图预期大部分请求会命中缓存，但是由于后台小哥预热缓存的时候将所有商品的缓存时间都设置为 2 小时过期，所有的商品在同一个时间点全部失效，瞬间所有的请求都落在数据库上，导致数据库扛不住压力崩溃，用户所有的请求都超时报错。

实际上所有的请求都直接落到数据库，如下图：

什么时候发现的？

凌晨 01:02 SRE 收到系统告警，登录运维管理系统发现数据库节点 CPU 和内存飙升超过阈值，迅速联系后台开发人员定位排查。

为什么没有早点发现？

由于缓存设置过期时间是 2 小时，凌晨 1 点前缓存可以命中大部分请求，数据库服务处于正常状态。

发现时采取了什么措施？

后台小哥通过日志定位排查发现问题后，进行了一系列操作：

首先通过 API Gateway（网关）限制大部分流量进来?

接着将宕机的数据库服务重启?

再重新预热缓存?

确认缓存和数据库服务正常后将网关流量正常放开，大约 01：30 抢购活动恢复正常。

如何避免下次出现？

这次事故的原因其实就是出现了缓存雪崩，查询数据量巨大，请求直接落到数据库上，引起数据库压力过大宕机。

在业界解决缓存雪崩的方法其实比较成熟了，比如有：

• 均匀过期

• 加互斥锁

• 缓存永不过期

（1）均匀过期

设置不同的过期时间，让缓存失效的时间点尽量均匀。通常可以为有效期增加随机值或者统一规划有效期。

（2）加互斥锁

跟缓存击穿解决思路一致，同一时间只让一个线程构建缓存，其他线程阻塞排队。

（3）缓存永不过期

跟缓存击穿解决思路一致，缓存在物理上永远不过期，用一个异步的线程更新缓存。

2021 年 Java 中高级面试必备知识点总结

在这个部分总结了 2019 年到目前为止 Java 常见面试问题，取其面试核心编写成这份文档笔记，从中分析面试官的心理，摸清面试官的“套路”，可以说搞定 90%以上的 Java 中高级面试没一点难度。

本节总结的内容涵盖了：消息队列、Redis 缓存、分库分表、读写分离、设计高并发系统、分布式系统、高可用系统、SpringCloud 微服务架构等一系列互联网主流高级技术的知识点。

目录：

（上述只是一个整体目录大纲，每个点里面都有如下所示的详细内容，从面试问题——分析面试官心理——剖析面试题——完美解答的一个过程）

部分内容：

对于每一个做技术的来说，学习是不能停止的，小编把 2019 年到目前为止 Java 的核心知识提炼出来了，无论你现在是处于什么阶段，如你所见，这份文档的内容无论是对于你找面试工作还是提升技术广度深度都是完美的。

不想被后浪淘汰的话，赶紧搞起来吧，高清完整版一共是 888 页，需要的话可以点赞+关注

本文已被CODING开源项目：【一线大厂Java面试题解析+核心总结学习笔记+最新讲解视频+实战项目源码】收录