更新缓存，由缓存自己同步更新数据库

先删除缓存，再更新数据库

这种方法在并发读写的情况下容易出现缓存不一致的问题

如上图所示，其可能的执行流程顺序为：

• 客户端 1 触发更新数据 A 的逻辑

• 客户端 2 触发查询数据 A 的逻辑

• 客户端 1 删除缓存中数据 A

• 客户端 2 查询缓存中数据 A，未命中

• 客户端 2 从数据库查询数据 A，并更新到缓存中

• 客户端 1 更新数据库中数据 A

可见，最后缓存中的数据 A 跟数据库中的数据 A 是不一致的，缓存中的数据 A 是旧的脏数据。

因此一般不建议使用这种方式。

先更新数据库，再让缓存失效

这种方法在并发读写的情况下，也可能会出现短暂缓存不一致的问题

如上图所示，其可能执行的流程顺序为：

• 客户端 1 触发更新数据 A 的逻辑

• 客户端 2 触发查询数据 A 的逻辑

• 客户端 3 触发查询数据 A 的逻辑

• 客户端 1 更新数据库中数据 A

• 客户端 2 查询缓存中数据 A，命中返回（旧数据）

• 客户端 1 让缓存中数据 A 失效

• 客户端 3 查询缓存中数据 A，未命中

• 客户端 3 查询数据库中数据 A，并更新到缓存中

可见，最后缓存中的数据 A 和数据库中的数据 A 是一致的，理论上可能会出现一小段时间数据不一致，不过这种概率也比较低，大部分的业务也不会有太大的问题。

只更新缓存，由缓存自己同步更新数据库（Read/Write Through Pattern）

这种方法相当于是业务只更新缓存，再由缓存去同步更新数据库。 一个 Write Through 的 例子如下：

如上图所示，其可能执行的流程顺序为：

• 客户端 1 触发更新数据 A 的逻辑

• 客户端 2 触发查询数据 A 的逻辑

• 客户端 1 更新缓存中数据 A，缓存同步更新数据库中数据 A，再返回结果

• 客户端 2 查询缓存中数据 A，命中返回

Read Through 和 WriteThrough 的流程类似，只是在客户端查询数据 A 时，如果缓存中数据 A 失效了（过期或被驱逐淘汰），则缓存会同步去数据库中查询数据 A，并缓存起来，再返回给客户端

这种方式缓存不一致的概率极低，只不过需要对缓存进行专门的改造。

只更新缓存，由缓存自己异步更新数据库（Write Behind Cache Pattern）