- [6. 分布式缓存问题](#6-分布式缓存问题)

- [6.1. 缓存雪崩](#61-缓存雪崩)

- [6.2. 缓存穿透](#62-缓存穿透)

- [6.3. 缓存预热](#63-缓存预热)

- [6.4. 缓存更新](#64-缓存更新)

- [6.5. 缓存降级](#65-缓存降级)

- [7. 参考资料](#7-参考资料)

本地消息表与业务数据表处于同一个数据库中，这样就能利用本地事务来保证在对这两个表的操作满足事务特性。

1. 在分布式事务操作的一方完成写业务数据的操作之后向本地消息表发送一个消息，本地事务能保证这个消息一定会被写入本地消息表中。

2. 之后将本地消息表中的消息转发到 Kafka 等消息队列（MQ）中，如果转发成功则将消息从本地消息表中删除，否则继续重新转发。

3. 在分布式事务操作的另一方从消息队列中读取一个消息，并执行消息中的操作。

这种方案遵循 BASE 理论，采用的是最终一致性。

本地消息表利用了本地事务来实现分布式事务，并且使用了消息队列来保证最终一致性。

缓存雪崩是指：在高并发场景下，由于原有缓存失效，新缓存未到期间(例如：我们设置缓存时采用了相同的过期时间，在同一时刻出现大面积的缓存过期)，所有原本应该访问缓存的请求都去查询数据库了，而对数据库 CPU 和内存造成巨大压力，严重的会造成数据库宕机。从而形成一系列连锁反应，造成整个系统崩溃。

解决方案：

- 用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。

- 还有一个简单的方案，就是将缓存失效时间分散开，不要所有缓存时间长度都设置成 5 分钟或者 10 分钟；比如我们可以在原有的失效时间基础上增加一个随机值，比如 1-5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

缓存失效时产生的雪崩效应，将所有请求全部放在数据库上，这样很容易就达到数据库的瓶颈，导致服务无法正常提供。尽量避免这种场景的发生。

缓存穿透是指：用户查询的数据，在数据库没有，自然在缓存中也不会有。这样就导致用户查询的时候，在缓存中找不到，每次都要去数据库再查询一遍，然后返回空（相当于进行了两次无用的查询）。这样请求就绕过缓存直接查数据库，这也是经常提的缓存命中率问题。

当在流量较大时，出现这样的情况，一直请求 DB，很容易导致服务挂掉。

解决方案：

1. 在封装的缓存 SET 和 GET 部分增加个步骤，如果查询一个 KEY 不存在，就以这个 KEY 为前缀设定一个标识 KEY；以后再查询该 KEY 的时候，先查询标识 KEY，如果标识 KEY 存在，就返回一个协定好的非 false 或者 NULL 值，然后 APP 做相应的处理，这样缓存层就不会被穿透。当然这个验证 KEY 的失效时间不能太长。

2. 如果一个查询返回的数据为空（不管是数据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，一般只有几分钟。

3. 采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的 bitmap 中，一个一定不存在的数据会被这个 bitmap 拦截掉，从而避免了对底层存储系统的查询压力。

缓存预热这个应该是一个比较常见的概念，相信很多小伙伴都应该可以很容易的理解，缓存预热就是系统上线后，将相关的缓存数据直接加载到缓存系统。这样就可以避免在用户请求的时候，先查询数据库，然后再将数据缓存的问题！用户直接查询事先被预热的缓存数据！

解决方案：

1. 直接写个缓存刷新页面，上线时手工操作下；

2. 数据量不大，可以在项目启动的时候自动进行加载；

3. 定时刷新缓存；

除了缓存服务器自带的缓存失效策略之外（Redis 默认的有 6 中策略可供选择），我们还可以根据具体的业务需求进行自定义的缓存淘汰，常见的策略有两种：

1. 定时去清理过期的缓存；

2. 当有用户请求过来时，再判断这个请求所用到的缓存是否过期，过期的话就去底层系统得到新数据并更新缓存。

两者各有优劣，第一种的缺点是维护大量缓存的 key 是比较麻烦的，第二种的缺点就是每次用户请求过来都要判断缓存失效，逻辑相对比较复杂！具体用哪种方案，大家可以根据自己的应用场景来权衡。

当访问量剧增、服务出现问题（如响应时间慢或不响应）或非核心服务影响到核心流程的性能时，仍然需要保证服务还是可用的，即使是有损服务。系统可以根据一些关键数据进行自动降级，也可以配置开关实现人工降级。

降级的最终目的是保证核心服务可用，即使是有损的。而且有些服务是无法降级的（如加入购物车、结算）。