redis缓存数据一致性问题解决方案总结！

1) 双写模式

当数据更新时，更新数据库时同时更新缓存

 

存在问题

由于卡顿等原因，导致写缓存2在最前，写缓存1在后面就出现了不一致

 

这是暂时性的脏数据问题，但是在数据稳定，缓存过期以后，又能得到最新的正确数据

2) 失效模式

数据库更新时将缓存删除

 

存在问题

当两个请求同时修改数据库，一个请求已经更新成功并删除缓存时又有读数据的请求进来，这时候发现缓存中无数据就去数据库中查询并放入缓存，在放入缓存前第二个更新数据库的请求成功，这时候留在缓存中的数据依然是第一次数据更新的数据

解决方法

1、缓存的所有数据都有过期时间，数据过期下一次查询触发主动更新

2、读写数据的时候(并且写的不频繁)，加上分布式的读写锁。

3) 解决方案

无论是双写模式还是失效模式，都会导致缓存的不一致问题。即多个实例同时更新会出事。怎么办？

• 如果是用户纬度数据（订单数据、用户数据），这种并发几率非常小，不用考虑这个问题，缓存数据加上过期时间，每隔一段时间触发读的主动更新即可

• 如果是菜单，商品介绍等基础数据，也可以去使用canal订阅binlog的方式。

 

• 缓存数据+过期时间也足够解决大部分业务对于缓存的要求。

• 通过加锁保证并发读写，写写的时候按顺序排好队。读读无所谓。所以适合使用读写锁。（业务不关心脏数据，允许临时脏数据可忽略）；

总结：

• 我们能放入缓存的数据本就不应该是实时性、一致性要求超高的。所以缓存数据的时候加上过期时间，保证每天拿到当前最新数据即可。

• 我们不应该过度设计，增加系统的复杂性

• 遇到实时性、一致性要求高的数据，就应该查数据库，即使慢点。