Redis 双写一致性问题分析

Redis 双写一致性问题分析

1、更新数据库,不动缓存 只设置过期时间(兜底)。

        如果说业务不要求强一致性,这样就可以了,像12306抢票的时候,票数就不是准的,只要去下单买票的的时候,判断db的库存就行了。

2、删除缓存   更新数据库

    读写并发问题:

     (1)线程A删除缓存

    (2)线程B查询数据,发现缓存数据不存在

    (3)线程B查询数据库,得到旧值,写入缓存

    (4)线程A将新值更新到数据库

    这样一来,缓存中的数据仍然是旧值 ,这种情况下属于更新数据事务原子性问题,需要用分布式锁来解决。

3、  更新数据库  删除缓存 

      同样面临上面高并发读写导致缓存不一致问题。

4、延时双删,内存队列

           延时双删这个方案,能解决一定问题,但是延时的时长不好把控,这直接与性能挂钩,但是时间短了,又会有并发问题。个人不建议。

           内存队列这个方案,感觉实现复杂,耦合度变高,个人不建议。

5、异步删除

     拿数据库记录,通过消息队列,消费删除或更新缓存,

     1、这里就是说不保证强一致性,消费的越快,一致性越强  

           如过消费的超快,是不是还是有旧值写到缓存?

     2、与业务完全解耦

 

6、 个人想法: 不管是先删除缓存还是先更新数据库 ,都是说读到了旧值,待更新删除完后,把旧值又写到缓存了。

         那么能不能,当我读请求后,如果有写,我就不写缓存行不行?

 

      这里缓存读模式有更改,需要重写缓存管理接口并兼容以前的模式,另外需要内存空间存flag的key,性能应该比锁强一点。

 

总结: 

        1、完全不考虑,能简单就简单,首选1方案

        2、并发小,允许高并发下一些key不一致,2,3方案都可以,必须强一致,2,3方案考虑加锁

        3、并发高,考虑5方案

        4、至于个人方案,能不能通过损失ap和内存空间,来达到强一致,暂时只是个想法。

 

 


版权声明:本文为sss1366255原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。