概念： 当修改了数据库的数据也要同时更新缓存的数据，缓存和数据库的数据要保持一致

那为什么会有不一致的情况呢？

如果不追求一致性，正常有两种做法

1. 先修改数据库 后删除旧的缓存
2. 先删除旧的缓存 再修改数据库

我们以先删除旧的缓存，再修改数据库为例：

1. 当 线程1 要对数据库做更新操作的时候，先将Redis中旧的缓存删掉
2. 不巧此时线程之间发生切换，线程2读取缓存，因为被线程1删掉了，所以缓存未命中
3. 线程2就直接查询数据库，并重建缓存（将此时的数据库数据写回Redis）
4. 接着又切换回线程1，线程1将数据库中的数据修改为新的值

此时就出现了数据库和缓存中的数据不一致的问题

因此我们不能只进行一次缓存删除操作，要使用双删的方法

1. 比如先删除旧的缓存，修改完数据库后，再删除一次缓存

但是单纯双删不能解决问题，比如

1. 当 线程1 要对数据库做更新操作的时候，先将Redis中旧的缓存删掉
2. 不巧此时线程之间发生切换，线程2读取缓存，因为被线程1删掉了，所以缓存未命中
3. 线程2就直接查询数据库，获取当前数据库的值，但未重建缓存
4. 接着又切换回线程1，线程1将数据库中的数据修改为新的值，并再次删除缓存
5. 此时又切换为线程2，线程2将当时读取到的值写回Redis，又造成了数据不一致

因此我们可以采取 延迟双删策略

还是上面那个例子：

1. 当 线程1 要对数据库做更新操作的时候，先将Redis中旧的缓存删掉
2. 不巧此时线程之间发生切换，线程2读取缓存，因为被线程1删掉了，所以缓存未命中
3. 线程2就直接查询数据库，获取当前数据库的值，但未重建缓存
4. 接着又切换回线程1，线程1将数据库中的数据修改为新的值，但不马上删除缓存，而是等待一段时间
5. 切换为线程2，线程2将当时读取到的值写回Redis
6. 最后切换回线程1，线程1再将Redis中的数据删除

可以看到 延迟双删策略 确实能解决数据一致性的问题，但延迟的时间很难确定，短了怕上面的例子中，第6步先于第5步执行，长了怕在第5步和第6步之间的数据不一致状态持续时间太长

因此我们需要另外的解决方案

针对双写一致性有两种场景： 一致性要求高 和 允许短暂不一致

这两种场景的解决方案不同

一致性要求高

可以使用如下的分布式锁方案

但是我们可以看到该方案让并发变为了串行，极大降低了性能

因此我们可以使用读写锁

读锁 readLock： 加了读锁之后，其他线程还能继续加读锁和读数据，但是不能写，也不能加写锁

写锁 writeLock：写锁是排他锁，加锁之后，其他线程阻塞，不能进行读写操作

Redission 以及实现了读写锁

代码实例

读锁

写锁

其中 redissonClient.getReadWriteLock()中传入的值必须是一样的

允许短暂不一致

实际上的开发过程中，这种场景才是主流

这种场景的解决方法很多，比较常用的方法是 异步通知保持数据的最终一致性

流程图如下：

修改数据库时，需要发送修改记录给MQ，缓存服务需要监听MQ，根据MQ中的修改记录更新缓存