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操作快
