如何保证缓存与数据库双写时的数据一致性？

1. 如何保证缓存与数据库双写时的数据一致性？

背景：使用到缓存，无论是本地内存做缓存还是使用 Redis 做缓存，那么就会存在数据同步的问题，因为配置信息缓存在内存中，而内存时无法感知到数据在数据库的修改。这样就会造成数据库中的数据与缓存中数据不一致的问题。

共有四种方案：

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

第一种和第二种方案，没有人使用的，因为第一种方案存在问题是：并发更新数据库场景下，会将脏数据刷到缓存。

第二种方案存在的问题是：如果先更新缓存成功，但是数据库更新失败，则肯定会造成数据不一致。

目前主要用第三和第四种方案。

2. 先删除缓存，后更新数据库

该方案也会出问题，此时来了两个请求，请求 A（更新操作） 和请求 B（查询操作）

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

上述情况就会导致不一致的情形出现。而且，如果不采用给缓存设置过期时间策略，该数据永远都是脏数据。

答案一：延时双删

最简单的解决办法延时双删

使用伪代码如下：

public void write(String key,Object data){
        Redis.delKey(key);
        db.updateData(data);
        Thread.sleep(1000);
        Redis.delKey(key);
    }

转化为中文描述就是 （1）先淘汰缓存 （2）再写数据库（这两步和原来一样） （3）休眠1秒，再次淘汰缓存，这么做，可以将1秒内所造成的缓存脏数据，再次删除。确保读请求结束，写请求可以删除读请求造成的缓存脏数据。自行评估自己的项目的读数据业务逻辑的耗时，写数据的休眠时间则在读数据业务逻辑的耗时基础上，加几百ms即可。

如果使用的是 Mysql 的读写分离的架构的话，那么其实主从同步之间也会有时间差。

 

 

此时来了两个请求，请求 A（更新操作） 和请求 B（查询操作）

1. 请求 A 更新操作，删除了 Redis
2. 请求主库进行更新操作，主库与从库进行同步数据的操作
3. 请 B 查询操作，发现 Redis 中没有数据
4. 去从库中拿去数据
5. 此时同步数据还未完成，拿到的数据是旧数据

此时的解决办法就是如果是对 Redis 进行填充数据的查询数据库操作，那么就强制将其指向主库进行查询。

 

　　 

 

答案二： 更新与读取操作进行异步串行化

采用更新与读取操作进行异步串行化

异步串行化

我在系统内部维护n个内存队列，更新数据的时候，根据数据的唯一标识，将该操作路由之后，发送到其中一个jvm内部的内存队列中（对同一数据的请求发送到同一个队列）。读取数据的时候，如果发现数据不在缓存中，并且此时队列里有更新库存的操作，那么将重新读取数据+更新缓存的操作，根据唯一标识路由之后，也将发送到同一个jvm内部的内存队列中。然后每个队列对应一个工作线程，每个工作线程串行地拿到对应的操作，然后一条一条的执行。

这样的话，一个数据变更的操作，先执行删除缓存，然后再去更新数据库，但是还没完成更新的时候，如果此时一个读请求过来，读到了空的缓存，那么可以先将缓存更新的请求发送到队列中，此时会在队列中积压，排在刚才更新库的操作之后，然后同步等待缓存更新完成，再读库。

读操作去重

多个读库更新缓存的请求串在同一个队列中是没意义的，因此可以做过滤，如果发现队列中已经有了该数据的更新缓存的请求了，那么就不用再放进去了，直接等待前面的更新操作请求完成即可，待那个队列对应的工作线程完成了上一个操作（数据库的修改）之后，才会去执行下一个操作（读库更新缓存），此时会从数据库中读取最新的值，然后写入缓存中。

如果请求还在等待时间范围内，不断轮询发现可以取到值了，那么就直接返回；如果请求等待的时间超过一定时长，那么这一次直接从数据库中读取当前的旧值。（返回旧值不是又导致缓存和数据库不一致了么？那至少可以减少这个情况发生，因为等待超时也不是每次都是，几率很小吧。这里我想的是，如果超时了就直接读旧值，这时候仅仅是读库后返回而不放缓存）

3. 先更新数据库，后删除缓存

这一种情况也会出现问题，比如更新数据库成功了，但是在删除缓存的阶段出错了没有删除成功，那么此时再读取缓存的时候每次都是错误的数据了。

 

 

此时解决方案就是利用消息队列进行删除的补偿。具体的业务逻辑用语言描述如下：

1. 请求 A 先对数据库进行更新操作
2. 在对 Redis 进行删除操作的时候发现报错，删除失败
3. 此时将Redis 的 key 作为消息体发送到消息队列中
4. 系统接收到消息队列发送的消息后再次对 Redis 进行删除操作

但是这个方案会有一个缺点就是会对业务代码造成大量的侵入，深深的耦合在一起，所以这时会有一个优化的方案，我们知道对 Mysql 数据库更新操作后再 binlog 日志中我们都能够找到相应的操作，那么我们可以订阅 Mysql 数据库的 binlog 日志对缓存进行操作。

 

 

 

 

以上转载至 https://zhuanlan.zhihu.com/p/405258604

 

 

上面的说明中, 答案二,  感觉太复杂了,  搞这么复杂, 中小厂的码农估计是一辈子都理解不了的把..   订阅 Mysql 数据库的 binlog 日志 ____ 这个更加是麻烦了, 还需要引入一个类似canal 的中间件吧

 

"异步串行化" 我理解,  这样不是不可用, 但是这样做的必要性是?  这样做, 会不会造成内存消耗太大, 启动线程过多了吧?  而且你让一个读操作进行等待, 等待多久合适, 超时了怎么办? 

另外, "删除缓存的阶段出错了" 不好理解, 为什么删除缓存的阶段会出错? 难道是刚好这个时间redis缓存系统崩溃了?  重启redis之后重新加载缓存应该是数据库为准吧, 那就不会有问题..

 

说明, 缓存-数据库 的数据双写一致性问题产生的根源是?  双写到底怎么理解?

什么是写请求, 具体是 更新, 新增 还是删除??  我觉得是应该是更新, 

如果新增, 那么很简单,  新增之前缓存中是没有数据的, 不存在一致不一致, 请求访问缓存, 找不到, 加载到缓存, 然后就 数据 自然的一致了

删除也是,  但是会稍微复杂一点, 如果先删除数据库再删除缓存, 那么没问题;  如果先删除缓存再删除数据库,  假设缓存已经删除, 正准备删除数据库的数据, 但是这个时候请求过来了, 发现缓存中没有数据, 于是从数据库中查询, 因为来没有来得及删除, 数据还在, 于是数据又被加载到了缓存之中,  然后执行数据库删除,  然后就不一致了:  数据库不存在, 缓存中存在, 

数据更新的问题呢?  更复杂一些,  其实主要是数据的不同.