redis 缓存更新一致性

当执行写操作后，需要保证从缓存读取到的数据与数据库中持久化的数据是一致的，因此需要对缓存进行更新。

因为涉及到数据库和缓存两步操作，难以保证更新的原子性。

在设计更新策略时，我们需要考虑多个方面的问题:

• 对系统吞吐量的影响：比如更新缓存策略产生的数据库负载小于删除缓存策略的负载
• 并发安全性：并发读写时某些异常操作顺序可能造成数据不一致，如缓存中长期保存过时数据
• 更新失败的影响：若某个操作失败，如何对业务影响降到最小
• 检测和修复故障的难度: 操作失败导致的错误会在日志留下详细的记录容易检测和修复。并发问题导致的数据错误没有明显的痕迹难以发现，且在流量高峰期更容易产生并发错误产生的业务风险较大。

更新缓存有两种方式:

• 删除失效缓存: 读取时会因为未命中缓存而从数据库中读取新的数据并更新到缓存中
• 更新缓存: 直接将新的数据写入缓存覆盖过期数据

更新缓存和更新数据库有两种顺序：

• 先数据库后缓存
• 先缓存后数据库

两两组合共有四种更新策略，现在我们逐一进行分析。

并发问题通常由于后开始的线程却先完成操作导致，我们把这种现象称为“抢跑”。下面我们逐一分析四种策略中“抢跑”带来的错误。

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

若数据库更新成功，删除缓存操作失败，则此后读到的都是缓存中过期的数据，造成不一致问题。

可能发生的并发错误:

时间	线程A	线程B	数据库	缓存
1	缓存失效		v1	null
2	从数据库读取v1		v1	null
3		更新数据库	v2	null
4		删除缓存	v2	null
5	写入缓存		v2	v1

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

同删除缓存策略一样，若数据库更新成功缓存更新失败则会造成数据不一致问题。

可能发生的并发错误:

时间	线程A	线程B	数据库	缓存
0			v0	v0
1	更新数据库为v1		v1	v0
2		更新数据库为v2	v2	v0
3		更新缓存为v2	v2	v2
4	更新缓存为v1		v2	v1

当两个写线程发生冲突时，可以通过比较数据版本方式避免线程A写入旧的数据。

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

可能发生的并发错误:

时间	线程A	线程B	数据库	缓存
1	删除缓存		v1	null
2		缓存失效	v1	null
3		从数据库读取v1	v1	null
4	更新数据库为v2		v2	null
5		将v1写入缓存	v2	v1

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

若缓存更新成功数据库更新失败， 则此后读到的都是未持久化的数据。因为缓存中的数据是易失的，这种状态非常危险。

因为数据库因为键约束导致写入失败的可能性较高，所以这种策略风险较大。

可能发生的并发错误:

时间	线程A	线程B	数据库	缓存
0			v0	v0
1	更新缓存为v1		v0	v1
2		更新缓存为v2	v0	v2
3		更新数据库为v2	v2	v2
4	更新数据库为v1		v1	v2

异步更新

双写更新的逻辑复杂，一致性问题较多。现在我们可以采用订阅数据库更新的方式来更新缓存。

阿里巴巴开源了mysql数据库binlog的增量订阅和消费组件 - canal。

我们可以采用API服务器只写入数据库，而另一个线程订阅数据库 binlog 增量进行缓存更新的策略。

这种策略存在和先更新数据库后删除缓存类似的并发问题:

时间	读线程	写线程	异步线程	数据库	缓存
1	缓存失败			v1	null
2	从数据库读取v1			v1	null
3		更新数据库为v2		v2	null
4			删除缓存/更新缓存	v2	null
5	写入缓存			v2	v1

这个问题同样可以采用异步线程更新缓存，且写入缓存时比较数据版本的方法来解决。