Redis缓存同步1-策略介绍
- Redis
- 时间：2023-07-09 08:23
- 3199人已阅读
🔔🔔🔔好消息!好消息!🔔🔔🔔
有需要的朋友👉:联系凯哥
缓存数据同步策略示意图 在大多数情况下，我们通过浏览器查询到的数据都是缓存数据，如果缓存数据与数据库的数据存在较大差异的话，可能会产生比较严重的后果的。所以，我们应该也必须保证数据库数据、缓存数据的一致性，这就是缓存与数据库的同步。 大家好，我是凯哥Java(kaigejava)，全网同名。欢迎大家搜索凯哥Java 缓存数据同步，常见的有三种方式： 这种方式的优缺点及使用场景如下： 优点：简单、方便、好理解； 缺点：时效性差，缓存过期之前可能数据库中的数据和缓存中的数据就不一致了了。 使用场景：更新频率低，时效性要求低的业务。 同步双写的优缺点： 优点：时效性强，缓存与数据库强一致； 缺点：有代码侵入，耦合度高；只要操作数据库的插入、更新及删除相关业务操作，就要去同步更新缓存，这种耦合度太高了； 使用场景：对一致性、时效性要求较高的缓存数据。 这种方式的优缺点： 优点：低耦合，可以同时通知多个缓存服务。可以使用MQ，异步特性来更新缓存，这样更新数据库和更新缓存就解耦了，而且一次可以更新多个服务，同时，代码入侵也是很少的(只有发送MQ少量代码)甚至是零入侵就可以实现； 缺点：时效性一般，可能存在中间不一致的状态。因为是异步的，可能会存在时间差，导致数据在某一时刻，是不一致的。但是可以保证最终一致性 使用场景：时效性要求一般的，有多个服务需要同步更新缓存的。 事实上，大多数场景下，我们都可以通过异步通知这种策略来更新缓存。所以，我们就来深入的讲讲异步通知。 通常情况下，异步通知实现方案，可以基于MQ或者是基于Canal来实现。 我们先来看看基于MQ异步通知的流程 1：在页面修改了商品信息后，商品信息入库，保存到MySQL数据库中； 2：入库成功后，发布一个MQ消息； 3：有个服务监听对应MQ消息，如果接收到消息后，就更新对应商品的缓存信息 流程图如下： MQ异步通知更新缓存流程图 这种方案，依然有少量的代码入侵：在写完数据库后，发送MQ消息，这点代码入侵是没办法省略的。第二种方案，就是Canal通知基于Canal的通知 基于Canal通知的业务流程如下图： 基于Canal通知的业务流程图 流程解读： 1：商品服务完成商品修改后，商品信息入库后，相关业务直接结束。这里没有任何的代码入侵； 2：Canal监听MySQL变化，当发现变化后，立即通知缓存服务； 3：缓存服务接收到canal通知后，更新缓存 使用Canal的异步通知是代码零侵入的。所以，这里，咱们就选择基于Canal的通知。接下来，我们就来讲讲Canal
缓存数据同步策略
异步通知的两种方案
