Redis总结（七）redis与数据库缓存一致性问题

在互联网行业，使用缓存来提升应用的性能已经是一件非常常见的手段，但是我们在实际使用到redis时总会遇到缓存与数据库数据不一致的情况

正常我们使用时：

• 写：删除缓存，将数据写入库中，完成后将数据写入缓存
• 读：先从缓存中读取，缓存中存在则直接返回，缓存中不存在则查询数据库，将结果写入缓存，然后返回

上面这种写法在并发不高的情况下，在有并发的情况下就会出现数据不一致的情况，如：

• 线程1写入数据先删除缓存
• 在线程1删除缓存但是还没有写入数据库时，线程2来读取数据，发现缓存中不存在
• 线程2去数据库查询，并将结果写入缓存。
• 此时线程1才更新数据库，这是就会出现缓存与数据库不一致的情况

第一种解决方式：

在并发不高的情况下，我们可以采用双删策略来解决上述问题，但这种解决方式只是弱一致性的保证：

更新数据时先删除缓存数据，然后将数据写入数据库，写入完成后再次删除缓存，再写入缓存并设置缓存过期时间

这种方式虽然一定程度上保证了数据的一致性，但是面对上述问题，同样会存在极短时间内数据不一致，也就是写入数据库，删除缓存，再写入缓存的这段时间。

第二种解决方式：

如果要求数据的强一致性，那么我们就需要牺牲一点性能了，采用加分布式锁的方式了：

写：

• 先清除缓存
• 对key加分布式锁
• 更新数据库
• 更新缓存，释放锁

读：

• 查询缓存，查询到结果则直接返回
• 没有查询到结果则加分布式锁，读取数据库，再写入缓存释放锁
• 如果没有获取到锁，则等一点时间重试，获取到锁后，先去缓存查询，如果查询到直接返回，没查询到则读取数据库，写入缓存，释放锁。

这种解决方式，因为引入了分布式锁解决了并发的问题，也解决了因为删除缓存可能导致的缓存穿透等问题，当然这种方式也牺牲了一部分性能。

第三种解决方式：

第三种也不能说是解决方式，可以说是一点建议，对于并发特别高的数据，那么这种实时与数据库交互同样不太好，我们可以采取最终一致性的方案。

比如：秒杀时，我们库存在秒杀开始时放入缓存，后续的秒杀都只操作缓存，不去同步数据库，等到秒杀结束时再去同步数据库，保证了数据的最终的数据一致性。因为秒杀的并发量可能特别高，而且响应速度要求比较高，我们可以采用这种方式。

以上三种方案，都可以解决问题，但是在使用时要根据自己的实际业务需求来选择适合业务的方案，别并发并不高的情况下却选择了加锁的方式。

还有一些其他的方式，如使用阿里的同步工具canal，但是我自己不怎么了解，所以就不在献丑了，大家可以自行了解。

上述只是自己的一点小总结，可能有不对的地方，大家可以矫正。