缓存数据库一致性问题

news2024/11/19 19:24:31

为什么使用缓存？

业务处于起步阶段，流量非常小，那无论是读请求还是写请求，直接操作数据库
随着业务指数级增长，请求量剧增，直接访问数据库，导致性能急剧下降，需要引入缓存提高读性能。

引入缓存导致的一些问题？

1、如何将数据库的数据加载到缓存中？

系统启动或者业务执行前，统一将数据刷入缓存
写操作时变更数据库，不操作缓存
启动定时任务，定时将数据库数据更新到缓存中

在这里插入图片描述

优点
- 所有的缓存都可以直接命中，不需要查数据库，性能特别高
缺点：
- 缓存利用率低：写多读少的场景特别明显，不经常访问数据也在缓存中
- 数据不一致：定时刷新缓存，数据不一致的程度完全取决于定时任务的执行频率
适用场景
- 业务体量小，数据库一致性要求不高的业务场景。

读操作时写缓存

写操作时，写数据库
读操作时，先读缓存，缓存不存在时读库写缓存（缓存只保留访问的热数据）
写入缓存的同时写入失效时间
先更新缓存，再更新数据库
- 两个步骤不同步导致的问题
- 并发问题
先更新数据库，再更新缓存
- 两个步骤不一致导致的问题
- 并发问题

无论先更新缓存，还是先更新数据库，这种更新操作都会存在数据不一致和并发问题，不仅缓存利用率不高，还会造成机器性能的浪费，所以，可以采用删除缓存的策略

先删除缓存，再更新数据库
- 删除更新步骤不一致的问题

虽然不存在缓存不一致的情况，但是有缓存击穿的风险，可以加锁将读取数据库，写缓存的两个逻辑合并为原子操作。

- 并发问题

在这里插入图片描述

先删除缓存再更新数据库，读写并发时，存在数据库缓存不一致的问题。

先更新数据库，再删除缓存
- 删除更新步骤不一致的问题

更新完数据库，删除缓存失败之后，导致数据缓存不一致问题

并发问题

看似理论上会发生的事情，其实概率极低，先更新数据库后删除缓存的方案是可以保证数据一致性的。

如何解决操作缓存，操作数据库两步不一致问题？

两步操作，不管哪个先哪个后，后面的失败了都会存在问题
- 常用解决方案就是，重试补偿。
- 重试的缺点
  - 依然有失败的几率
  - 重试次数过多，占用线程资源，无法服务其他客户端请求。
- 可以使用异步重试
  - 使用消息队列异步重试删除缓存
    - 消息队列保证可靠性投递
    - 消息队列保证消息成功投递
    - 项目中一般经常使用消息队列，维护成本没有增加
    - 写缓存和写消息队列失败的概率也很小
    - 引入消息队列解决两步不同步的问题，比较合适

在这里插入图片描述
- 订阅数据库binlog操作缓存
- 业务代码中不用操作缓存
- 数据库变更的时候，产生一条binlog，订阅这条binlog去删除对应的缓存
- 不用考虑消息队列写失败的问题（变更成功，一定有binlog）
- 自动投递下有的队列（canel）
- 推荐方案：先更新数据库再删除缓存，然后使用消息队列或者canel订阅binlog，塞到下游队列的方案。

缓存双删策略

先删除缓存，再更新数据库（存在缓存回填旧值）
主从架构
以上两种情况都导致读线程，回填了旧值到缓存中，到缓存失效，或者删除之前，读线程读的都是旧的脏数据。
解决方案
- 写线程A 休眠或者生成一个延时消息，再删除一次缓存。
  - 复杂的生产场景延时时间不太好确定
  - 一般针对主从的问题，就是延时时间大于主从复制（或者读线程，读数据库+写入缓存的时间）的时间多个几百毫秒.
  - 只能尽可能降低不一致的概率。
- 实际场景中推荐先更新数据库，再删除缓存方案，然后尽量保证主从复制的时间不要太延迟，降低问题的概率