Redis缓存和数据库双写一致性

桃扇骨 2024-03-31 08:01 215阅读 0赞

参考博客：https://www.cnblogs.com/12lisu/p/16090034.html
两种一致性：
1、最终一致性 2、强一致性：不能放缓存

常见方案

缓存的主要目的是为了提升查询的性能
在这里插入图片描述

**1. 用户请求过来之后，先查缓存有没有数据，如果有则直接返回。

  1. 如果缓存没数据，再继续查数据库。
  2. 如果数据库有数据，则将查询出来的数据，放入缓存中，然后返回该数据。

  3. 如果数据库也没数据，则直接返回空。**
    目前有以下4种方案：

  4. 先写缓存，再写数据库

  5. 先写数据库，再写缓存
  6. 先删缓存，再写数据库
  7. 先写数据库，再删缓存（推荐）

先写数据库，再删缓存（推荐方案）

在这里插入图片描述

如果删除缓存失败，需要加重试机制
在接口中如果更新了数据库成功了，但更新缓存失败了，可以立刻重试3次。如果其中有任何一次成功，则直接返回成功。如果3次都失败了，则写入数据库，准备后续再处理。
1、同步重试，该接口并发量比较高的时候，可能有点影响接口性能。
2、异步重试，mq重试
在这里插入图片描述

当用户操作写完数据库，但删除缓存失败了，产生一条mq消息，发送给mq服务器。
mq消费者读取mq消息，重试5次删除缓存。如果其中有任意一次成功了，则返回成功。如果重试了5次，还是失败，则写入死信队列中。
推荐mq使用rocketmq，重试机制和死信队列默认是支持的。使用起来非常方便，而且还支持顺序消息，延迟消息和事务消息等多种业务场景。
当然在该方案中，删除缓存可以完全走异步。即用户的写操作，在写完数据库之后，不用立刻删除一次缓存。而直接发送mq消息到mq服务器，然后有mq消费者全权负责删除缓存的任务。

发表评论

表情：
评论列表 （有 0 条评论，215人围观）

还没有评论，来说两句吧...

相关阅读