3.【多级缓存架构】数据库和缓存不一致的情况分析和解决方案

3.【多级缓存架构】数据库和缓存不一致的情况分析和解决方案

数据库和缓存双写不一致的问题时一个很常见的问题,解决该问题也是缓存架构中必不可少的一部分

1. 最初级的缓存不一致的问题以及解决方案

1.1 问题:先修改数据库,在删除缓存,如果删除缓存失败了,就会导致数据库中的是新数据,缓存中的是旧数据,数据出现不一致。

2020-05-22-07-16-57.png

1.2 解决思路:

  1. 先删除缓存,再修改数据库,如果删除缓存成功了,修改数据库失败了,那么数据库中的是旧数据,缓存中是空的,那么数据就会不一致

  2. 下次读请求过来的时候,发现缓存没有,则从数据库读取旧数据,然后更新到缓存中。虽然最后的结果是,数据库和缓存虽然都是旧数据,但是没有数据不一致的情况。

2020-05-22-07-21-23.png

2. 复杂的数据不一致的问题分析(多线程并发读写同一个数据)

2.1 问题

  1. 数据发生了变更,先删除了缓存,然后要去修改数据库;此时还没有修改,另外一个请求过来了,去读缓存,发现缓存空了,去查询数据库,查到了修改前的旧数据,放到了缓存中数据变更的程序完成了数据库的修改,发现 缓存中的是 旧数据,数据库中的是 新数据,出现数据不一致的问题

2020-05-22-22-08-03.png

2.2 出现原因:

  1. 只有在对一个数据并发的进行读写的时候,才可能会出现上述问题;

  2. 其实如果说你的并发量很低的话,特别是读并发很低,每天访问量1万次,就很少会出现上述情况。但是,如果每天是上亿的流量,每秒并发读是几万,每秒只要有更新的请求,就很大的几率出现数据库+缓存不一致的情况

2.3 解决方案:数据库和缓存更新与读取操作异步串行化

  1. 更新数据的时候,根据数据的唯一标识,将操作路由之后,发送到一个jvm内部队列中。

  2. 读取数据的时候,如果发现数据不再缓存中,那么将重新读取数据 + 更新缓存的操作串行化;读取数据的时候,也根据唯一标示路由之后,发送到同一个jvm内部队列中。

  3. 一个队列对应一个工作线程,每个工作线程串行拿到对应的操作,然后一条一条的执行

    扫描二维码关注公众号,回复: 13757040 查看本文章

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

这里还有一个优化点,一个队列中,其实多个更新缓存请求串行化在一起是没有意义的,因此可以做过滤,如果发现有一个更新缓存的请求,那么就不用再放个更新请求操作进去了,直接等待前面的更长操作请求完成即可。

待 那个队列 对应的工作线程 完成了上一个操作的数据库修改之后,才会去执行下一个操作,也就是缓存更新操作,此时会从数据库中读取最新的值,然后写入到缓存中。

如果请求还在等待时间访问内,不断轮询发现可以取到值了,那么就直接返回;然后请求等待的时间超过一定的时长,那么这一次就就直接从数据库读取当前的旧值。

2.3 高并发场景下,该解决方案要注意的问题

2.3.1 读请求长时间阻塞

  1. 读请求长时间阻塞, 由于进行了非常轻度的异步化,所以一定要注意读超时的问题每个读请求都必须在超时时间内返回

  2. 该解决方案,最大的风险点在于说,可能数据更新和频繁,导致队列积压了大量的更新操作在里面,然后读请求会发生大量的超时,导致大量的数据直接走数据库。

  3. 另外一点,因为一个队列中,可能会基于针对多个数据项的更新操作,因此需要根据自己的业务进行测试,可能需要部署多个服务,每个服务分摊一些数据的更新操作。

  4. 如果一个内存队列里居然会积压100个商品的库存修改操作,每个库存修改操作10ms去完成,那么最后一个商品的读请求,可能就要等待10 * 100 = 1000ms = 1s,才能得到数据,这个时候就会导致读请求长时间阻塞。

  • 一定要根据实际业务系统的运行情况,去进行一些压力测试

目的:和模拟线上环境,去看看最繁忙的时候,内存队列中可能会积压多少更新操作,可能导致最后一个更新操作对应读请求,会hang多少秒,如果读请求在200ms返回,如果你计算过后,哪怕是最繁忙的时候,积压10个更新操作,最多等待200ms,那还是可以的。

  • 如果内存队列积压的的操作过多

解决方案:部署更多的机器,让每个机器部署的服务实例处理更少的数据,那么每个队列更新的操作就会减少。

2.3.2 读请求并发量过高

解决方案:多服务部署的请求路由,保证说,执行数据更新操作,以及执行缓存更新操作,都通过nginx服务器路由到相同的服务实例上

2.3.3 热点商品的路由问题,导致请求的倾斜

万一某个商品的读写请求特别高,全部达到相同的机器的相同队列中,可能造成某台机器压力过大。也就是说,因为只有在商品数据更新的时候才会请求缓存,然后才会有读写并发,所以更新频率不是太高的话,这个问题的影响并不是特别大,但的确坑你某些机器的负载会高一些。

参考石衫老师亿级流量笔记

如果对你有用,点个赞再走呗!!!

猜你喜欢

转载自juejin.im/post/7082660358346768392