Redis - 缓存的双写一致性

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

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

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

  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中的修改记录更新缓存