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和内存空间，来达到强一致，暂时只是个想法。