缓存一致性如何保障- 延迟双删

缓存机制

缓存一致性如何保障- 延迟双删_第1张图片

缓存的一致性

缓存如果发生改变的话,那么,不建议直接做redis缓存中的更新操作
缓存一致性如何保障- 延迟双删_第2张图片
一般来说是通过Cache Aside Pattern的处理模式,简单来说就是"先写库,再删除缓存"。如果要保持缓存数据绝对的一致性,只能用锁或者分布式锁,但是通常来说,加锁就打打的降低了性能,得不偿失的。

通常来说,如果T1执行了如下操作

  1. T1. 更新库->x1
  2. T2. 删除缓存

但是如果T2执行了如下操作,

  1. T0. 读取库->x0
  2. T3. 发现缓存不存在,更新->x0

在某种极端情况下是会发生这样情形的,这个时候就需要延迟双删策略了

延迟双删

对于T1来说,为了避免更新操作有效,他需要在第一次删除的操作后,在接下来的某个时间段,再次删除缓存,为了避免T2的极端情形,我们可以使用延时MQ来再次删除缓存,保证我们的更新有效。

如果说,上面的极端情形下,一直存在,那么这个场景就说明了API处理的时间太长了,建议优化流程或者加锁。

感觉这种思想有点类似DC(Double Check ),需要再做一次check或者删除来保证我们的数据的一致性。

你可能感兴趣的:(分布式,缓存)