当前位置：首页 > news >正文

【Redis实战篇】缓存-穿透/雪崩/击穿问题的解决方案

news 2026/5/28 1:16:02

温馨提示：建议在PC端浏览~

以商户查询缓存为例

什么是缓存
- 缓存就是数据交换的缓冲区（称作Cache），是存贮数据的临时地方，一般读写性能较高。
- 缓存的作用
  - 降低后端负载
  - 提高读写效率，降低响应时间
- 缓存的成本
  - 数据一致性成本
  - 代码维护成本
  - 运维成本
添加Redis缓存
- 缓存作用模型及添加Redis缓存后的流程图
缓存更新策略
- 业务场景
  - 低一致性需求：使用内存淘汰机制。例如店铺类型的查询缓存。（店铺类型很少发生改动）
  - 高一致性需求：主动更新，并以超时剔除作为兜底方案。例如店铺详情查询的缓存。
- 主动更新策略
  - 1、Cache Aside Pattern：由缓存的调用者，在更新数据库的同时更新缓存。（实际开发中一般使用这个策略，可控性高）
  - 2、Read/Write Through Pattern：缓存与数据库整合为一个服务，由服务来维护一致性。调用者调用该服务，无需关心缓存一致性问题。
  - 3、Write Behind Caching Pattern：调用者只操作缓存，由其它线程异步的将缓存数据持久化到数据库，保证最终一致。
- 操作缓存和数据库时需要考虑的三个问题
  - 问题一：删除缓存还是更新缓存？
    - 更新缓存：每次更新数据库都更新缓存，无效写操作较多。
    - 删除缓存：更新数据库时让缓存失效，查询时再更新缓存。（推荐）
  - 问题二：如何保证缓存与数据库的操作的同时成功或失败？
    - 单体系统，将缓存与数据库操作放在一个事务。
    - 分布式系统，利用TCC等分布式事务方案。
  - 问题三：先操作缓存还是先操作数据库？
    - 1、先删除缓存，再操作数据库
      - 可能存在的问题如图：
    - 2、先操作数据库，再删除缓存
      - 可能存在的问题如图：
    - 小结：由于操作缓存比操作数据库的速度快很多，所以第二种情况可能出现的问题发生的概率很小，所以实际开发优先选择“先操作数据库，再删除缓存”的策略，并结合过期时间来维护数据库与缓存数据的一致性。
- 缓存更新策略的最佳实践方案
  - 低一致性需求：使用Redis自带的内存淘汰机制
  - 高一致性需求：主动更新，并以超时剔除作为兜底方案
    - 读操作
      - 缓存命中则直接返回
      - 缓存未命中则查询数据库，并写入缓存，设定超时时间
    - 写操作
      - 先写数据库，然后再删除缓存
      - 要确保数据库与缓存操作的原子性
缓存穿透
- 缓存穿透是指客户端请求的数据在缓存中和数据库中都不存在，这样缓存永远不会生效，这些请求都会打到数据库（如果有人恶意持续请求不存在的数据，会给数据库造成很大压力）。常见的解决方案有两种（当然不止这两种，这两种都是属于被动式的解决方案）：
  - 方案一：缓存空对象（实战中暂时选择了这个方案）
    - 优点：实现简单，维护方便
    - 缺点：
      - 额外的内存消耗
      - 可能造成短期的不一致（如果有人恶意请求不存在的数据，假设id为2，查询数据库后未发现该条数据，所以会在Redis缓存中存储对应key的值为null，并设置过期时间，但如果这之后刚好插入了一条id为2的新数据，用户访问时之前缓存的记录若还没有过期，用户就查询不到新插入的数据，从而造成短期的数据不一致的问题）
    - 过程演示
  - 方案二：布隆过滤（原理之后会讲）
    - 优点：内存占用较少，没有多余key
    - 缺点：
      - 实现复杂
      - 存在误判可能
    - 过程演示
- 实战解决缓存穿透问题（采用方案一：缓存空对象）
  - 流程图
- 小结
  - 缓存穿透产生的原因是什么？
    - 用户请求的数据在缓存中和数据库中都不存在，不断发起这样的请求，给数据库带来巨大压力。
  - 缓存穿透的解决方案有哪些？
    - 被动式的解决方案（被攻击了如何应对）
      - 缓存null值
      - 布隆过滤
    - 主动式的解决方案（主动采取一些措施，防止被恶意攻击）
      - 增强id的复杂度，避免被猜测id规律
      - 做好数据的基础格式校验
      - 加强用户权限校验
      - 做好热点参数的限流（在微服务课程有讲如何限流）
缓存雪崩
- 缓存雪崩是指在同一时段大量的缓存key同时失效或者Redis服务宕机，导致大量请求到达数据库，带来巨大压力。
- 解决方案
  - 给不同的Key的TTL添加随机值
  - 利用Redis集群提高服务的可用性（高级篇讲解）
  - 给缓存业务添加降级限流策略（微服务课程讲解）
  - 给业务添加多级缓存（高级篇讲解）
缓存击穿
- 缓存击穿问题也叫热点Key问题，就是一个被高并发访问并且缓存重建业务较复杂的key突然失效了，无数的请求访问会在瞬间给数据库带来巨大的冲击。
- 常见的解决方案有两种：
  - 互斥锁
  - 逻辑过期
- 互斥锁与逻辑过期策略的时序图对比
- 互斥锁与逻辑过期策略的优缺点对比
- 选择策略：互斥锁选择牺牲可用性从而保证一致性，而逻辑过期选择牺牲一致性从而保证可用性（CAP定理）。实际开发中，到底采取哪种策略，取决于当前业务更偏向于高一致性还是偏向于高可用性。
  - CAP定理
    - CAP定理（CAP theorem）又被称作布鲁尔定理（Brewer’s theorem），是加州大学伯克利分校的计算机科学家埃里克·布鲁尔（Eric Brewer）在2000年的ACM PODC上提出的一个猜想。
    - 在一个分布式系统中，当涉及读写操作时，只能保证一致性（Consistence）、可用性（Availability）、分区容错性（Partition Tolerance）三者中的两个，另外一个必须被牺牲。
      - C一致性（Consistency）：对某个指定的客户端来说，读操作保证能够返回最新的写操作结果。
      - A可用性（Availability）：非故障的节点在合理的时间内返回合理的响应（不是错误和超时的响应）。
      - P分区容忍性（Partition Tolerance）：当出现网络分区后，系统能够继续“履行职责”。
        说明：网络分区指在分布式系统中，多台服务器之间的信息交换出现了问题。例如丢包、两台服务器之间的连接中断了、网络拥堵等，都叫做发生了网络分区现象。