在互联网行业，使用缓存来提升应用的性能已经是一件非常常见的手段，但是我们在实际使用到redis时总会遇到缓存与数据库数据不一致的情况
正常我们使用时：
- 写：删除缓存，将数据写入库中，完成后将数据写入缓存
- 读：先从缓存中读取，缓存中存在则直接返回，缓存中不存在则查询数据库，将结果写入缓存，然后返回
上面这种写法在并发不高的情况下，在有并发的情况下就会出现数据不一致的情况，如：
- 线程1写入数据先删除缓存
- 在线程1删除缓存但是还没有写入数据库时，线程2来读取数据，发现缓存中不存在
- 线程2去数据库查询，并将结果写入缓存。
- 此时线程1才更新数据库，这是就会出现缓存与数据库不一致的情况
第一种解决方式：
在并发不高的情况下，我们可以采用双删策略来解决上述问题，但这种解决方式只是弱一致性的保证：
更新数据时先删除缓存数据，然后将数据写入数据库，写入完成后再次删除缓存，再写入缓存并设置缓存过期时间
这种方式虽然一定程度上保证了数据的一致性，但是面对上述问题，同样会存在极短时间内数据不一致，也就是写入数据库，删除缓存，再写入缓存的这段时间。
第二种解决方式：
如果要求数据的强一致性，那么我们就需要牺牲一点性能了，采用加分布式锁的方式了：
写：
- 先清除缓存
- 对key加分布式锁
- 更新数据库
- 更新缓存，释放锁
读：
- 查询缓存，查询到结果则直接返回
- 没有查询到结果则加分布式锁，读取数据库，再写入缓存释放锁
- 如果没有获取到锁，则等一点时间重试，获取到锁后，先去缓存查询，如果查询到直接返回，没查询到则读取数据库，写入缓存，释放锁。
这种解决方式，因为引入了分布式锁解决了并发的问题，也解决了因为删除缓存可能导致的缓存穿透等问题，当然这种方式也牺牲了一部分性能。
第三种解决方式：
第三种也不能说是解决方式，可以说是一点建议，对于并发特别高的数据，那么这种实时与数据库交互同样不太好，我们可以采取最终一致性的方案。
比如：秒杀时，我们库存在秒杀开始时放入缓存，后续的秒杀都只操作缓存，不去同步数据库，等到秒杀结束时再去同步数据库，保证了数据的最终的数据一致性。因为秒杀的并发量可能特别高，而且响应速度要求比较高，我们可以采用这种方式。
以上三种方案，都可以解决问题，但是在使用时要根据自己的实际业务需求来选择适合业务的方案，别并发并不高的情况下却选择了加锁的方式。
还有一些其他的方式，如使用阿里的同步工具canal，但是我自己不怎么了解，所以就不在献丑了，大家可以自行了解。
上述只是自己的一点小总结，可能有不对的地方，大家可以矫正。
