Redis 缓存更新一致性

在使用 Redis 作为数据库缓存的场景中对数据的读取流程通常是先读取缓存如果命中则返回，未命中则从数据库读取并把数据写到缓存中。

当更新数据时则数据库和缓存都要进行更新，此时我们要考虑两个问题：删除缓存还是更新缓存？先更新缓存还是先更新数据库？

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

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

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

两两组合共有四种更新策略：

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

先说结论：

在没有 CAS、分布式锁等机制的保护的情况下，四种更新方式都会在并发执行时出现不一致状态。

并发问题通常由于后开始的线程却先完成操作导致，我们把这种现象称为“抢跑”。 抢跑现象的实质是由于线程调度、网络抖动等原因导致多个线程以错误的时序运行引发的异常。它与并发量无直接关系，在较低的并发量下依然可能有抢跑现象存在。

下面我们逐一分析四种策略中“抢跑”带来的错误。

四种更新方式的具体问题

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

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

可能存在读写线程竞争导致的并发错误:

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

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

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

该策略同样存在读写线程竞争导致数据不一致的问题:

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

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

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

因为数据库中存在的键约束导致数据库写入失败的可能性较高，所以发生上述错误的概率会进一步升高。

该策略同样存在读写线程竞争导致的错误:

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

两个写线程竞争也会导致数据不一致:

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

解决方案

使用 CAS

CAS (Check-And-Set 或 Compare-And-Swap)是一种常见的保证并发安全的手段。CAS 当且仅当客户端最后一次取值后该 key 没有被其他客户端修改的情况下，才允许当前客户端将新值写入。

func CAS(oldVal, newVal) {
    if cache.get() == oldVal {
        cache.set(newVal)
    }
}

我们以上文提到的「先更新数据库，再更新缓存」方案中两个写线程竞争为例，尝试使用 CAS 来解决这个并发问题：

时间	线程A	线程B	数据库	缓存
0			v0	v0
1	更新数据库为 v1		v1	v0
2		更新数据库为 v2	v2	v0
3		执行 CAS 操作：当且仅当缓存中为 v0 时将 v2 写入缓存	v2	v2
4	执行 CAS 操作：当且仅当缓存中为 v0 时将v1写入缓存。当前缓存为 v2 故放弃写缓存		v2	v2

由上图可见，CAS 可以有效的避免并发错误的发生。

目前一些兼容 Redis 协议的中间件已经提供了 CAS 命令的支持，比如阿里的 Tair 以及腾讯的 Tendis。

Redis 官方提供了 Watch + 事务的方法来支持 CAS, 或者使用 redis 中 lua 脚本原子性执行的特点来实现 CAS。 不过由于代码较为复杂，这两种方案都不常见。

使用分布式锁

CAS 假设发生并发问题的概率不大, 所以 CAS 也被称为乐观锁。那么悲观锁能否解决我们的问题呢？

还是以「先更新数据库，再更新缓存」方案中两个写线程竞争为例， 我们要求任何线程在写入或读取数据库前都需要获取排它锁。

时间	线程A	线程B	数据库	缓存
0			v0	v0
1	获取排它锁		v0	v0
2	更新数据库为 v1		v1	v0
3	更新缓存为 v1		v1	v1
4		等待排它锁	v1	v1
5	释放排它锁		v1	v1
6		获得排它锁	v1	v1
7		更新数据库为 v2	v2	v1
8		更新缓存为 v2	v2	v2
9		释放排它锁	v2	v2

分布式锁同样可以解决并发问题，只是成本可能略高。

一些流行的解决方案

监听 binlog 进行异步更新

阿里开源了 MySQL 数据库binlog的增量订阅和消费组件 - canal。 canal 模拟从库获得主库的 binlog 更新，然后将更新数据写入 MQ 或直接进行消费。

我们可以让API服务器只负责写入数据库，另一个线程订阅数据库 binlog 增量进行缓存更新。

因为 binlog 是有序的，因此可以避免两个写线程竞争。但我们仍然需要解决读写线程竞争的问题:

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

这里同样可以 CAS 解千愁：

时间	读线程	写线程	异步线程	数据库	缓存
1	缓存失效			v1	null
2	从数据库读取v1			v1	null
3		更新数据库为v2		v2	null
4			更新缓存	v2	v2
5	CAS 若缓存为 null 则写入 v1。放弃更新			v2	v2

延时双删

使用删除缓存策略时读线程先开始却后写缓存会导致不一致，那么我们在读线程结束后再次清除缓存是不是就可以解除错误状态了？

时间	线程A	线程B	数据库	缓存
1	缓存失效		v1	null
2	从数据库读取v1		v1	null
3		更新数据库	v2	null
4		删除缓存	v2	null
5	写入缓存		v2	v1
6		延时一段时间后，再次删除缓存	v2	null

延时双删就是写线程等待一段时间“确保”读线程都结束后再次删除缓存，以此清除可能的错误缓存数据。

理论上我们无法给出一个时间来“确保”读线程都结束，所以仍有存在并发问题的可能。但是延时双删实现成本很低而且极大的减少了并发问题出现的概率，不失为一种简单实用的手段。