目录
1 真实案例1.1 背景1.2 问题处理2 缓存雪崩2.1 概念2.2 解决方案分析2.2.1 缓存集群+数据库集群2.2.2 适当的限流、降级2.2.3 随机过期时间2.2.4 缓存预热3 缓存穿透3.1 概念3.2 解决方案分析3.2.1 缓存空值3.2.2 BloomFilter3.2.3 两种方案的选择判断4 缓存击穿4.1 概念4.2 解决方案4.2.1 锁的方式4.2.2 空初始值1 真实案例
云办公系统用户实时信息查询功能优化发布之后，系统发生宕机事件（系统挂起，页面无法加载）。
1.1 背景
我们IM原有的一个功能，当鼠标移动到用户头像的时候，会显示出用户的基本信息。信息比较简单，只包含简单的用户名、昵称、性别、邮箱、电话等基本数据，
这是一个典型的数据查询，大概过程如下左侧，访问用户基本信息的时候会先去Redis中查一下，如果不存在，就把大约2W左右的用户数据一次性取出来，保存在Redis中，因为用户基本信息在同一张表上期key。
这种现象是多个线程同时去查询数据库的这条数据，那么我们可以在第一个查询数据的请求上使用一个 互斥锁来锁住它。
其他的线程走到这一步拿不到锁就等着，等第一个线程查询到了数据，然后做缓存。后面的线程进来发现已经有缓存了，就直接走缓存。
锁不好的地方就是在其他线程在拿不到锁的时候就等待，这个会造成系统整体吞吐量降低，用户体验度也不好。
4.2.2 空初始值
这是一种短暂降级的方式：
如果一个缓存失效的时候，有无数个请求狂奔而来，而第一个请求从进入缓存池，判空，再到数据库检索，再查询出结果并返回设置缓存的这个过程里，缓存是不存在的。
这个就很危险，超高并发下这个短暂的过程足已让千千万万请求投向数据库。更别提这可能是个慢查询，整个过程可能长达2s以上，那对数据库是一种非常大的伤害。
业内有一种做法叫做空初始值，短暂的局部降级来保证整个数据库系统不被击穿。大概流程如下：
可以看出，整个过程中我们牺牲了A、B、C、D的请求，他们拿回了一个空值或者默认值，但是这局部的降级却保证整个数据库系统不被拥堵的请求击穿。
这也是我面试中最喜欢问候选人的缓存类问题。
以上就是架构思维之缓存雪崩的灾难复盘的详细内容，更多关于缓存雪崩灾难的资料请关注我们其它相关文章！
