概念： 当修改了数据库的数据也要同时更新缓存的数据，缓存和数据库的数据要保持一致
那为什么会有不一致的情况呢？
如果不追求一致性，正常有两种做法
- 先修改数据库 后删除旧的缓存
- 先删除旧的缓存 再修改数据库
我们以先删除旧的缓存，再修改数据库为例：
- 当 线程1 要对数据库做更新操作的时候，先将Redis中旧的缓存删掉
- 不巧此时线程之间发生切换，线程2读取缓存，因为被线程1删掉了，所以缓存未命中
- 线程2就直接查询数据库，并重建缓存（将此时的数据库数据写回Redis）
- 接着又切换回线程1，线程1将数据库中的数据修改为新的值
此时就出现了数据库和缓存中的数据不一致的问题
因此我们不能只进行一次缓存删除操作，要使用双删的方法
- 比如先删除旧的缓存，修改完数据库后，再删除一次缓存
但是单纯双删不能解决问题，比如
- 当 线程1 要对数据库做更新操作的时候，先将Redis中旧的缓存删掉
- 不巧此时线程之间发生切换，线程2读取缓存，因为被线程1删掉了，所以缓存未命中
- 线程2就直接查询数据库，获取当前数据库的值，但未重建缓存
- 接着又切换回线程1，线程1将数据库中的数据修改为新的值，并再次删除缓存
- 此时又切换为线程2，线程2将当时读取到的值写回Redis，又造成了数据不一致
因此我们可以采取 延迟双删策略
还是上面那个例子：
- 当 线程1 要对数据库做更新操作的时候，先将Redis中旧的缓存删掉
- 不巧此时线程之间发生切换，线程2读取缓存，因为被线程1删掉了，所以缓存未命中
- 线程2就直接查询数据库，获取当前数据库的值，但未重建缓存
- 接着又切换回线程1，线程1将数据库中的数据修改为新的值，但不马上删除缓存，而是等待一段时间
- 切换为线程2，线程2将当时读取到的值写回Redis
- 最后切换回线程1，线程1再将Redis中的数据删除
可以看到 延迟双删策略 确实能解决数据一致性的问题，但延迟的时间很难确定，短了怕上面的例子中，第6步先于第5步执行，长了怕在第5步和第6步之间的数据不一致状态持续时间太长
因此我们需要另外的解决方案
针对双写一致性有两种场景： 一致性要求高 和 允许短暂不一致
这两种场景的解决方案不同
一致性要求高
可以使用如下的分布式锁方案
但是我们可以看到该方案让并发变为了串行，极大降低了性能
因此我们可以使用读写锁
读锁 readLock： 加了读锁之后，其他线程还能继续加读锁和读数据，但是不能写，也不能加写锁
写锁 writeLock：写锁是排他锁，加锁之后，其他线程阻塞，不能进行读写操作
Redission 以及实现了读写锁
代码实例
读锁
写锁
其中 redissonClient.getReadWriteLock()中传入的值必须是一样的
允许短暂不一致
实际上的开发过程中，这种场景才是主流
这种场景的解决方法很多，比较常用的方法是 异步通知保持数据的最终一致性
流程图如下：
修改数据库时，需要发送修改记录给MQ，缓存服务需要监听MQ，根据MQ中的修改记录更新缓存
