笔记

# Redis与数据库一致性

Redis与数据库一致性的总结，参考了很多博客和文章，如有不正确的地方请指出，感谢😋

先做一个说明，从理论上来说，给缓存设置过期时间，是可以保证最终一致性的解决方案，这种方案下，我们可以对存入缓存的数据设置过期时间，所有的写操作以数据库为准，对缓存操作只是尽最大努力即可，也就是说如果数据库写成功，缓存更新失败，那么只要到达过期时间，则后面的读请求自然会从数据库中读取新值然后回填缓存，所以接下来的方案是保障缓存与数据库数据能尽可能的更快一致

根据缓存是删除还是更新，以及操作顺序大概是可以分为下面四种情况

  1. 先更新数据库，再更新缓存
  2. 先更新缓存，再更新数据库
  3. 先删除缓存，再更新数据库
  4. 先更新数据库，再删除缓存

正常来说为了保证原子性，出现异常只可能出现第一步执行成功，第二步执行失败继续执行重试机制的情况，如果第一步就失败了该请求应该就直接结束

# 更新缓存 VS 删除缓存

这里我们简单对比一下，更新缓存 VS 删除缓存

  • 什么是更新缓存: 数据不但写入数据库，还会写入缓存
  • 什么是删除缓存: 数据只会写入数据库，不会写入缓存，只会删除缓存

优点对比

  • 更新缓存的优点: 缓存不会增加一次Miss，命中率高
  • 删除缓存的优点: 操作简单，能防止更新出现的线程安全问题

那到底是选择更新缓存还是删除缓存呢，主要取决于更新缓存的复杂度

  • 更新缓存的代价很小，此时我们应该更倾向于更新缓存，以保证更高的缓存命中率
  • 更新缓存的代价很大，此时我们应该更倾向于删除缓存

例如

  1. 只是简单的更新一下用户余额，只操作一个字段，那就可以采用更新缓存
  2. 还有类似秒杀下商品库存数量这种并发下查询频繁的数据，也可以使用更新缓存

不过这种更新数值，要注意线程安全的问题，防止产生脏数据

主要还是要以业务场景为主进行选择

不过大部分场景下删除缓存操作简单，并且带来的副作用只是增加了一次Cache Miss，建议作为通用的处理方式

# 先更新数据库，再更新缓存

这种方式就适合更新缓存的代价很小的数据，例如上面说的余额，库存数量这类数据，不过要注意线程安全的问题

线程安全角度

同时有请求A和请求B进行更新操作，那么会出现

  1. 线程A更新了数据库
  2. 线程B更新了数据库
  3. 线程B更新了缓存
  4. 线程A更新了缓存

这就出现请求A更新缓存应该比请求B更新缓存早才对，但是因为网络等原因，B却比A更早更新了缓存，这就导致了脏数据

业务场景角度

  • 有如下两种不适合场景
  1. 如果你是一个写数据库场景比较多，而读数据场景比较少的业务需求，采用这种方案就会导致，数据压根还没读到，缓存就被频繁的更新，浪费性能
  2. 如果你写入数据库的值，并不是直接写入缓存的，而是要经过一系列复杂的计算再写入缓存。那么，每次写入数据库后，都再次计算写入缓存的值，无疑是也浪费性能的

# 先更新缓存，再更新数据库

本来这种情况应该是和第一种情况一样会存在线程安全问题的，但是这种情况是有人使用过的，根据书籍《淘宝技术这十年》里，多隆把商品详情页放入缓存，采取的正是先更新缓存，再将缓存中的数据异步更新到数据库这种方式，有兴趣了解的可以查看这篇博客: https://www.cnblogs.com/rjzheng/p/9240611.html (opens new window)

还有现在互联网常见的点赞功能，也可以采用这种方式，有兴趣了解的可以查看这篇文章: https://juejin.im/post/5bdc257e6fb9a049ba410098 (opens new window)

# 先删除缓存，再更新数据库

简单的想一下，好像这种方式不错，就算是第一步删除缓存成功，第二步写数据库失败，则只会引发一次Cache Miss，对数据没有影响，其实仔细一想并发下也很容易导致了脏数据，例如

  1. 请求A进行写操作，删除缓存
  2. 请求B查询发现缓存不存在
  3. 请求B去数据库查询得到旧值
  4. 请求B将旧值写入缓存
  5. 请求A将新值写入数据库

那怎么解决呢，不着急，先看第四种情况，后面再统一说第三种和第四种的解决方案

# 先更新数据库，再删除缓存

先说一下，老外提出了一个缓存更新套路，名为Cache-Aside Pattern (opens new window)

图片

  • 更新操作就是先更新数据库，再删除缓存
  • 读取操作先从缓存取数据，没有，则从数据库中取数据，成功后，放到缓存中

这是标准的设计方案，包括Facebook的论文Scaling Memcache at Facebook (opens new window)也使用了这个策略

为什么他们都用这种方式呢，这种情况不存在并发问题么?

答案是也存在，但是出现概率比第三种低，例如

  1. 请求缓存刚好失效
  2. 请求A查询数据库，得一个旧值
  3. 请求B将新值写入数据库
  4. 请求B删除缓存
  5. 请求A将查到的旧值写入缓存

这样就出现脏数据了，然而，实际上出现的概率可能非常低，因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必需在写操作前进入数据库操作，而又要晚于写操作删除缓存，所有的这些条件都具备的概率基本并不大，但是还是会有出现的概率

并且假如第一步写数据库成功，第二步删除缓存失败，这样也导致脏数据，请看解决方案

# 解决方案

那怎么解决呢，可以采用延时双删策略(缓存双淘汰法)，可以将前面所造成的缓存脏数据，再次删除

  1. 先删除(淘汰)缓存
  2. 再写数据库（这两步和原来一样）
  3. 休眠1秒，再次删除(淘汰)缓存

或者是

  1. 先写数据库
  2. 再删除(淘汰)缓存（这两步和原来一样）
  3. 休眠1秒，再次删除(淘汰)缓存

这个1秒应该看你的业务场景，应该自行评估自己的项目的读数据业务逻辑的耗时，然后写数据的休眠时间则在读数据业务逻辑的耗时基础上，加几百ms即可，这么做确保读请求结束，写请求可以删除读请求造成的缓存脏数据

如果你用了MySql的读写分离架构怎么办？，例如

  1. 请求A进行写操作，删除缓存
  2. 请求A将数据写入数据库了，(或者是先更新数据库，后删除缓存)
  3. 请求B查询缓存发现，缓存没有值
  4. 请求B去从库查询，这时，还没有完成主从同步，因此查询到的是旧值
  5. 请求B将旧值写入缓存
  6. 数据库完成主从同步，从库变为新值

这种情景，就是数据不一致的原因，还是采用延时双删策略(缓存双淘汰法)，只是，休眠时间修改为在主从同步的延时时间基础上，加几百ms

并且为了性能更快，可以把第二次删除缓存可以做成异步的，这样不会阻塞请求了，如果再严谨点，防止第二次删除缓存失败，这个异步删除缓存可以加上重试机制，失败一直重试，直到成功

这里给出两种重试机制参考

方案一

  1. 更新数据库数据
  2. 缓存因为种种问题删除失败
  3. 将需要删除的key发送至消息队列
  4. 自己消费消息，获得需要删除的key
  5. 继续重试删除操作，直到成功

图片

然而，该方案有一个缺点，对业务线代码造成大量的侵入，于是有了方案二，启动一个订阅程序去订阅数据库的Binlog，获得需要操作的数据。在应用程序中，另起一段程序，获得这个订阅程序传来的信息，进行删除缓存操作

方案二

  1. 更新数据库数据
  2. 数据库会将操作信息写入binlog日志当中
  3. 订阅程序提取出所需要的数据以及key
  4. 另起一段非业务代码，获得该信息
  5. 尝试删除缓存操作，发现删除失败
  6. 将这些信息发送至消息队列
  7. 重新从消息队列中获得该数据，重试操作

图片

上述的订阅Binlog程序在MySql中有现成的中间件叫Canal，可以完成订阅Binlog日志的功能，另外，重试机制，这里采用的是消息队列的方式。如果对一致性要求不是很高，直接在程序中另起一个线程，每隔一段时间去重试即可，这些大家可以灵活自由发挥，只是提供一个思路

# 最后的总结

大部分应该使用的都是第三种或第四种方式，如果都是采用延时双删策略(缓存双淘汰法)，可能区别不会很大，不过第四种方式出现脏数据概率是更小点，更多的话还是要结合自身业务场景使用，自己灵活变通

参考

上次更新时间: 2023-12-15 03:14:55

← Redis与数据库一致性补充 →