Redis缓存同步1-策略介绍

缓存数据同步策略示意图

在大多数情况下，我们通过浏览器查询到的数据都是缓存数据，如果缓存数据与数据库的数据存在较大差异的话，可能会产生比较严重的后果的。所以，我们应该也必须保证数据库数据、缓存数据的一致性，这就是缓存与数据库的同步。

缓存数据同步策略

缓存数据同步，常见的有三种方式：

1：设置有效期

给缓存设置有效期，到期后自动删除。再次查询的时候，更新数据。

这种方式的优缺点及使用场景如下：

优点：简单、方便、好理解；

缺点：时效性差，缓存过期之前可能数据库中的数据和缓存中的数据就不一致了了。

使用场景：更新频率低，时效性要求低的业务。

2：同步双

同步双写策略就是在修改数据库的同时，也修改缓存。

同步双写的优缺点：

优点：时效性强，缓存与数据库强一致；

缺点：有代码侵入，耦合度高；只要操作数据库的插入、更新及删除相关业务操作，就要去同步更新缓存，这种耦合度太高了；

使用场景：对一致性、时效性要求较高的缓存数据。

3：异步通知

异步通知其实就是在修改了数据库的时候，发送时间通知，相关服务监听到通知之后异步的修改缓存数据。

这种方式的优缺点：

优点：低耦合，可以同时通知多个缓存服务。可以使用MQ，异步特性来更新缓存，这样更新数据库和更新缓存就解耦了，而且一次可以更新多个服务，同时，代码入侵也是很少的(只有发送MQ少量代码)甚至是零入侵就可以实现；

缺点：时效性一般，可能存在中间不一致的状态。因为是异步的，可能会存在时间差，导致数据在某一时刻，是不一致的。但是可以保证最终一致性

使用场景：时效性要求一般的，有多个服务需要同步更新缓存的。

事实上，大多数场景下，我们都可以通过异步通知这种策略来更新缓存。所以，我们就来深入的讲讲异步通知。

通常情况下，异步通知实现方案，可以基于MQ或者是基于Canal来实现。

异步通知的两种方案

我们先来看看基于MQ异步通知的流程

MQ异步通知更新缓存

我们以修改了商品后，更新对应的缓存为例来讲讲。业务流程大致如下描述：

1：在页面修改了商品信息后，商品信息入库，保存到MySQL数据库中；

2：入库成功后，发布一个MQ消息；

3：有个服务监听对应MQ消息，如果接收到消息后，就更新对应商品的缓存信息

流程图如下：

MQ异步通知更新缓存流程图

这种方案，依然有少量的代码入侵：在写完数据库后，发送MQ消息，这点代码入侵是没办法省略的。

第二种方案，就是Canal通知

基于Canal的通知

基于Canal通知的业务流程如下图：

基于Canal通知的业务流程图

流程解读：

1：商品服务完成商品修改后，商品信息入库后，相关业务直接结束。这里没有任何的代码入侵；

2：Canal监听MySQL变化，当发现变化后，立即通知缓存服务；

3：缓存服务接收到canal通知后，更新缓存

使用Canal的异步通知是代码零侵入的。所以，这里，咱们就选择基于Canal的通知。接下来，我们就来讲讲Canal