db和cache数据一致性方案

A dbB dbA del cacheB del cache

A'

Cache-Aside Pattern（旁路缓存）

A

B

step1: a 更新 dbstep2: a 更新 cachestep3: b 更新 dbstep4: b 更新 cache

解决大部分情景了

一种非常特殊的并发场景是：微服务Provider实例A进行数据的写入操作，先写DB（操作1），再删Cache（操作2），如果由于某种原因出现了卡顿，没有及时把数据放入Cache，或者说放入Cache的操作，简单的说，操作2发生了滞后。服务Provider实例 B进行一个数据的读取操作，读取的次序仍然是先读Cache，再读DB，很容易发生DB和Cache的不一致性。

cache加锁，不是一个好办法，应该从思路逻辑上解决这个问题。

不一致

step1: a 删除 cachestep2: b 请求 cache此时由于cache没有值，所以重新读了db的值，刷到cache中此时虽然db和cache还是一致的，但是逻辑上已经出现错误了，cache上应该被删除的值，没删除成功step3: a 更新 db

原因，a b 使用不同的值更新了cache

step1: a 更新 dbstep2: b 更新 dbstep3: b 更新 cachestep4: a 更新 cache

思路2.2：先更新db，然后删除cache

改进

变更新cache为删除cache

极其可能出现的问题，都是cache操作，控制粒度很低。

保险起见，删除两次cache，一开始删一次，更新db后，延迟一段时间，再删一次

写DB（操作1）删Cache（操作2），期间发生并发读，并发读到的是cache中的旧数据，如果操作2后续可以正常执行完成，那么一致性便会恢复正常。

极其可能出现的问题

思路1：先更新db，然后更新cache

ProviderB

对于同一个值的更新，的理想情况：

（1）写DB（操作1）和删Cache（操作2）之间，存在短时间的数据不一致；

问题

思路2.1：先删除cache，然后更新db

结果都是db修改了，cache清空了

朴素解决思路

在大量请求的业务场景下，为了解决db请求的瓶颈，我们会使用应用级的缓存对db中数据进行缓存。通过请求高速缓存，来降低大量请求涌入db的压力。而此时，需要对db和cache的一致性进行规划和设计。

A dbA del cacheB dbB del cache

（2）如果删Cache失败，存在较长时间的数据不一致，这个时间会一直持续到Cache过期

下面从最朴素的思路出发，进行设计，并且一步步研究存在的问题，提出下一个思路。

ProviderA

前提：缓存的操作远远比db操作快