10年 Java程序员,硬核人生!勇往直前,永不退缩!

欢迎围观我的git:https://github.com/R1310328554/spring_security_learn 寻找志同道合的有志于研究技术的朋友,关注本人微信公众号: 觉醒的码农,或Q群 165874185

  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

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之后重新加载缓存应该是数据库为准吧, 那就不会有问题..

 

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

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

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

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

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

 

 

posted on 2022-03-06 19:41  CanntBelieve  阅读(291)  评论(0编辑  收藏  举报