spring可能带来的一个深坑，从理论到实践！

Posted 2021-05-16 Java德克士

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了spring可能带来的一个深坑，从理论到实践！相关的知识，希望对你有一定的参考价值。

前言

最近有很多朋友向我求教经验，因为我自己工作相对于稳定，在这里给大家分享一个粉丝朋友的经历，他作为一个曾经的菜鸡面试者，在不断的失败中成长，最终斩获了多份offer，因此特别想在此分享一下他的面试成长之路。
文章内容篇幅较长，希望大家都能认真的看完，相信对你的帮助绝对不止一点半点！

首先和大家分享一下他这个面试季所斩获的所有offer：腾讯，美团，字节跳动，拼多多，华为，金山云，共6家公司，其中好几家给到可sp offer。最终入职了：字节跳动的「互动娱乐」部门成为了一名研发同学。

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

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

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

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

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

缓存命中

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

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

缓存雪崩

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

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

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

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

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

再重新预热缓存

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

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

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

（1）均匀过期

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

缓存key过期时间均匀分布

（2）加互斥锁

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

互斥访问

（3）缓存永不过期

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

异步更新缓存

即使是面试跳槽，那也是一个学习的过程。只有全面的复习，才能让我们更好的充实自己，武装自己，为自己的面试之路不再坎坷！今天就给大家分享一个Github上全面的Java面试题大全，就是这份面试大全助我拿下大厂Offer，月薪提至30K！

我也是第一时间分享出来给大家，希望可以帮助大家都能去往自己心仪的大厂！为金三银四做准备！
一共有20个知识点专题，分别是：