Redis 经典业务问题剖析和解决方案（缓存穿透，雪崩，击穿，无底洞，数据不一致，并发竞争）

系列文章目录

【深入理解使用Redis（初识）】

【深入理解使用Redis (Redis API的理解和使用）】

【Redis 持久化 看这一篇文章就够了 （精简版）】

---

---

前言

Redis在业务场景中常见的一些异常场景如：缓存穿透，雪崩，击穿，数据不一致，并发竞争，这个也是面试的时候常见的问题。了解和实际应用场景避免还是很有必要的。

---

一、缓存穿透

1，场景描述

缓存穿透是指当请求的数据既不在数据库中也不在缓存中的时候，请求会直接穿透缓存层，到达数据库层。这通常是由于恶意攻击或者程序错误造成的，比如攻击者故意请求不存在的大量数据，导致缓存不命中，所有的请求就会落在数据库上，从而可能对数据库造成巨大的压力，影响其性能甚至导致系统崩溃。整个过程如下：

1. 缓存层不命中。
2. 存储层不命中，不将空结果写回缓存。
3. 返回空结果

2，解决方案

1. 布隆过滤器（Bloom Filter）：本质是一种数据结构，可以用来检测一个元素是否在一个集合中。在请求达到缓存前，先通过布隆过滤器（保存着存在的key）进行检查，如果判断数据不存在，直接返回错误响应，避免对数据库的访问。
   实现原理：是使用一个位数组和一系列哈希函数，当向布隆过滤器中添加一个元素时，这个元素的哈希值会用来设置位数组中对应位置的位为1。当需要检查一个元素是否在集合中时，如果它的哈希值对应的位数组中的位是0，那么这个元素肯定不在集合中；如果是1，那么它可能不在集合中，因为哈希冲突可能导致其他元素被错误地哈希到相同的位置。
   注意事项：布隆过滤器有一定的误报率，即它可能会错误地认为某个数据存在。此外，布隆过滤器不支持从集合中删除元素而不影响其他元素的检测结果，这意味着在处理动态数据时可能需要额外的策略来维护布隆过滤器的准确性。
2. 缓存空结果:当查询数据库之后发现数据不存在的时候，可以把这个空结果也缓存起来，并设置一个较短的过期时间。
   注意事项:可能会导致缓存中包含大量空结果，必须合理设置过期时间
3. 限制请求：对于异常频繁的行为，可以采取限流，封IP等手段限制
4. 接口鉴权：再接口层做好身份验证和数据验证
5. 数据库建立合理索引：通过索引来提高查询效率
6. 二级缓存：本地缓存作为一级缓存
7. 前端控制：避免无效请求

二、缓存雪崩

1.场景描述

缓存雪崩是指在缓存系统中，由于大量缓存数据在同一时间过期，或者缓存服务宕机，导致所有的请求直接落在数据库上，造成数据库瞬间承受巨大的访问压力，从而变得不稳定或者崩溃。这类似于雪崩一样，一旦发生就会导致连锁反应，导致系统性能急剧下降。

2.解决方案

1. 缓存数据的过期时间随机化：避免大量缓存数据在同一时间点过期，可以在缓存的过期时间加上一个随机值。
2. 使用持久化：如果缓存服务支持持久化，要确保开启并且合理配置，避免缓存服务重启时，也能从持久化的数据中恢复，减少缓存雪崩的风险
3. 设置热点数据永不过期： 对于热点数据，可以设置永不过期，也可以采用手动更新缓存的策略
4. 使用多级缓存策略：本地环境，分布式缓存结合，减少对数据库的压力
5. 提升缓存服务的高可用性
6. 限流和熔断机制
7. 异步队列

三、缓存击穿

1.场景描述

缓存击穿是指缓存中没有单数据库中有的数据（一般是热点数据）在缓存失效的瞬间，同时有大量并发请求这些数据，这些请求会直接穿透缓存，压力给到数据库上。这个与缓存穿透不同，缓存穿透是查询不存在的数据，缓存击穿是查询存在但刚好失效的数据

2.解决方案

1. 使用互斥锁：对于同一个数据点，在缓存失效的时候，通过加锁或者同步机制，只允许一个请求去数据库查询数据，并更新缓存，常见的做法是用分布式锁
2. 设置热点数据永不过期： 对于热点数据，可以设置永不过期，也可以采用手动更新/后台维护线程负责更新缓存的策略，或者根据业务场景设置合理的过期时间。
3. 使用多级缓存策略：本地环境，分布式缓存结合，减少对数据库的压力
4. 提升缓存服务的高可用性
5. 提前更新缓存：可以用定时任务提前更新缓存数据
6. 读写分离和负载均衡

四、数据不一致

1.场景描述

缓存和数据库数据不一致：缓存层与数据层之间的数据同步策略不当导致的。发生这种情况的场景一般为：

1. 写操作没有同时更新缓存与数据库
2. 缓存过期或者被删除，而数据库中的数据在此期间被修改
3. 分布式系统中由于网络延迟或其他问题导致的数据同步延迟
4. 数据库事务回滚，但缓存更新已经发生

2.解决方案

1. 缓存延迟双删：更新数据库数据后，先删除缓存，然后延迟一小段时间再删除缓存，以确保请求在这段时间若读了旧数据，也会再次删除缓存，从而读到最新的数据
2. write/read through cache：利用缓存提供的读写通道策略，让缓存管理器负责数据的读写
3. write behind caching ：更新操作首先在缓存中执行，再异步更新到数据库。不过有数据丢失和数据一致性的风险
4. 数据库触发器：使用数据库触发器，在数据发生变化时自动更新缓存。
5. 事务消息，要么都成功要么都失败
6. 最终一致性：通过后台异步进程定期校队并同步数据
7. 版本号/时间戳
8. 强制缓存过期：设置较短的过去时间，确保数据定期从数据库更新

五、数据并发竞争

1.场景描述

通常时指有多个客户端或者线程同时对同一数据进行读写操作时，由于没有妥善处理并发控制导致数据不一致或丢失的情况。发生这种情况的场景一般为：

1. 计数器更新
2. 库存扣减：多个用户同时购买相同产品，可能会导致超卖
3. session共享：分布式web应用

2.解决方案

1. 事务消息：Redis可以通过MULTI和EXEC命令来确保一系列命令的原子性执行。
2. 使用Lua脚本
3. 使用分布式锁
4. 乐观锁/Optimistic Locking:使用watch命令监视一个或者多个键
5. 悲观锁/Pessimistic Locking
6. 限流措施

六、缓存无底洞

1.场景描述

为了满足业务要求（数据量金额访问量的增长），添加了大量的新的Memcache节点做水平扩容.，键值数据库通常是采用哈希函数将key映射到各个节点的，这样key的分布跟业务无关，这样键值就分布到更多的节点上，当批量操作的时候，通常是从不同的节点上获取，多涉及到多次网络操作。这样性能不但没有好转，反而下降了。对于这种现象称为缓存的 “无底洞” 现象。

2.解决方案

1. 命令本身的优化
2. 减少网络通信次数
3. 降低接入成本，客户端使用长连/连接池、NIO等
4. 批量操作的时候，可通过串行命令、串行IO、并行IO、hash_tag（多个key分配到一个节点）来处理。

总结

以上就是今天要讲的内容，本文介绍了Redis 经典业务问题剖析和解决方案（缓存穿透，雪崩，击穿，数据不一致，并发竞争，无底洞）