数据同步策略解读

前言

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

缓存由于其高并发和高性能的特性，已经在项目中被广泛使用，在缓存的使用中，通常会面临一个更新的问题，当数据源产生变化，如何去更新到数据库与缓存之中，并且尽量保证安全与性能。 

缓存主动更新策略

    方案一：由缓存的调用者在更新数据库的时候同时更新缓存

    方案二：将缓存和数据库整合为一个服务，由该服务来维护一致性。对外提供接口，调用者调用该服务提供的接口，无需关心缓存一致性问题

    方案三：调用者只操作缓存，由其他线程异步将缓存数据持久化到数据库，保证最终一致性。

数据同步策略

设置有效期

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

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

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

假设一个缓存的有效期为10min，但是这个缓存产生以后的5min就被修改了，在后面的5min内进行的查询，读到的都是缓存的数据，不是最新的数据。 

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

 同步双写

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

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

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

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

异步通知

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

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

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

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

而异步实现又可以基于MQ或者Canal来实现：

1）基于MQ的异步通知：

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

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

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

解读：

• 商品服务完成对数据的修改后，只需要发送一条消息到MQ中。

• 缓存服务监听MQ消息，然后完成对缓存的更新

依然有少量的代码侵入。

2）基于Canal的通知

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

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

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

解读：

• 商品服务完成商品修改后，业务直接结束，没有任何代码侵入

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

• 缓存服务接收到canal通知，更新缓存

代码零侵入

Canal [kə'næl]，译意为水道/管道/沟渠，canal是阿里巴巴旗下的一款开源项目，基于Java开发。基于数据库增量日志解析，提供增量数据订阅&消费。GitHub的地址：GitHub - alibaba/canal: 阿里巴巴 MySQL binlog 增量订阅&消费组件

Canal是基于mysql的主从同步来实现的，Canal就是把自己伪装成MySQL的一个slave节点，从而监听master的binary log变化。再把得到的变化信息通知给Canal的客户端，进而完成对其它数据库的同步。

 

• 1）MySQL master 将数据变更写入二进制日志( binary log），其中记录的数据叫做binary log events

• 2）MySQL slave 将 master 的 binary log events拷贝到它的中继日志(relay log)

• 3）MySQL slave 重放 relay log 中事件，将数据变更反映它自己的数据