redis 4 更新 redis更新机制

转载

风之谷启航 2023-05-25 16:02:21

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

redis 4 更新 redis更新机制_更新数据

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

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

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

更新缓存有两种方式:

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

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

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

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

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

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

redis 4 更新 redis更新机制_缓存_02

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

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

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

redis 4 更新 redis更新机制_更新数据_03

也可能因为两个写线程竞争导致并发错误:

redis 4 更新 redis更新机制_redis_04

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

可能发生的并发错误:

redis 4 更新 redis更新机制_redis_05

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

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

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

可能发生的并发错误:

redis 4 更新 redis更新机制_数据库_06

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

解决方案

使用 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 也被称为乐观锁。那么悲观锁能否解决我们的问题呢？

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