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