深入解析缓存模式下的数据一致性问题

今天，我们来聊聊常见的缓存模式和数据一致性问题。

常见的缓存模式有：Cache Aside、Read Through、Write Through、Write Back、Refresh Ahead、Singleflight。

缓存模式

Cache Aside

在 Cache Aside 模式中，是把缓存当做一个独立的数据源，在读取和写入数据时，由业务方来控制顺序。

在【写策略】中，有一个更新顺序，是先更新数据库，还是先更新缓存呢？

一般来说，我们要先更新数据库，因为在大多数业务场景下，数据是以数据库为准的，如果写入数据库成功了，即使写入缓存失败，缓存本身会有过期时间，在过期之后重新加载，数据就会恢复一致了。

不管【先写数据库，还是先写缓存】都不能解决数据一直性问题。

删除缓存

其实，实际最常用的并不是去更新缓存，而是去删除缓存。也就是在更新数据的时候先更新数据库，然后将缓存删除。

【先更新数据库、再删除缓存】下，依旧存在数据一致性问题，但是它的一致性问题不是源自两个线程同时更新数据，而是源自一个线程更新数据，一个线程缓存未命中回查数据库。

实际上这个情况出现的概率非常低，因为这个条件需要发生在读缓存时缓存失效，而且并发着有一个写操作。而实际上数据库的写操作会比读操作慢得多，而且还要锁表，而读操作必需在写操作前进入数据库操作，而又要晚于写操作更新缓存，所有的这些条件都具备的概率基本并不大。

Read Through（读穿透）

在该模式下，当缓存里面没有数据的时候，缓存会代替我们去数据库里面把数据加载出来，并且缓存起来。

当缓存失效时，Cache Aside 是由业务方负责把数据加载入缓存，而 Read Through 则是缓存服务自己来加载，从而对应用方是透明的。

可以看到，Read Through 的写模式和Cache Aside是一样的，所以也会存在数据一致性问题。

Write Through（写穿透）

当有数据更新的时候，如果没有命中缓存，直接更新数据库，然后返回。如果命中了缓存，则更新缓存，然后再由Cache自己更新数据库。

显然，Write Through 也没有解决数据一致性的问题，可以参考 Cache Aside 中的分析。

Write Back

此模式下，当写入数据时，只是写到了缓存，当缓存过期的时候，才会被刷新到数据库。

这里有一个问题，如果数据还在缓存中的时候，缓存突然崩溃了，那数据就直接丢了，所以在使用中我们要能保证缓存的高可用。

那么，Write Back 能否解决数据一致性问题呢？

先看【写操作】，在更新数据时，由于业务代码只更新 redis 缓存中的数据，所以对于业务方来说，数据必然是一致的。

这里需要注意下，虽然缓存和数据库中的数据不一致，但是业务方只读写缓存，所以对于业务方来说，数据是一致的。

比如下面的例子，只有 a 过期时，数据库中的 a 才等于 2

再看【读操作】

当业务方读数据时，如果缓存没有数据，就要去数据库里面加载。这个时候，就有可能产生不一致的问题。

比如说，数据库中 a=3，读出来之后还没写到缓存里面。这个时候来了一个写请求，在缓存中写入了 a = 4。如果这时候读请求回写缓存，就会用数据库里的老数据覆盖缓存中的新数据。

那么这个问题怎么解决呢？

当读请求回写的时候，使用 SETNX 命令。也就是说，只有当缓存中没有数据的时候，才会回写数据。而如果回写失败了，那么读请求会再从缓存中读取到数据。

所以，如果能保证缓存的高可用，那么 Write Back 在缓存一致性的表现上，比其他模式要好。

Refresh Ahead

Refresh Ahead 是指利用 CDC（Capture Data Change）接口异步刷新缓存的模式。

比如说利用 Canal 来监听数据库的 binlog，然后 Canal 刷新 Redis。

这种模式也存在数据一致性的问题，也是出现在缓存未命中的读请求和写请求上。

解决方案跟 Write Back 模式是一样的，也是利用 SETNX 命令。

Singleflight

Singleflight 主要是为了控制住加载数据的并发量，它是指当缓存未命中的时候，访问同一个 key 的线程中只有一个会去真的加载数据，其他都在原地等待。

这个模式最大的优点就是可以减轻访问数据库的并发量。

比如说如果同一时刻有 100 个线程要访问 key1，那么最终也只会有 1 个线程去数据库中加载数据。

这个模式的缺点是如果并发量不高，那么基本没有效果。所以热点之类的数据就很适合用这个模式。

如何保证缓存一致性

在 深入解析缓存与数据库数据不一致问题 的文章中，我们已经深入讨论过，数据不一致的来源有两个

• 源自操作部分失败；
• 源自并发操作。

并且对【源自操作部分失败】的场景，给出了解决方案-【重试机制】。

所以，我们今天只讨论【源自并发操作】的场景。

要想解决并发操作带来的问题，可以使用缓存模式、分布式锁、消息队列、版本号。

版本号

版本号解决并发更新的问题的基本思路就是每一次更新版本号都要加一，然后低版本数据不能覆盖高版本的数据。

比如在 Cache Aside 模式里面，加上版本号之后，就不会出现不一致的问题了。

这个方案的难点在于怎么去维护版本号？

可以在数据库里面增加一个版本号字段，然后在更新 redis 缓存的时候，就得使用 lua 脚本，先检测并比对缓存的版本号，再执行更新。

假如， redis 中有两个 key，name_1118：ybbyqq 和 name_1118_v：4，分别代表用户姓名和版本号值。

在更新 redis 的时候，我们需要有一个 lua 脚本来校验缓存的版本号。

-- Lua 脚本用于更新缓存，确保版本号的一致性
-- KEYS[1] 是缓存中的key
-- KEYS[2] 是缓存中的key的版本号
-- ARGV[1] 是新的版本号
-- ARGV[2] 是新的值-- 获取缓存中的版本号
local cacheVersion = redis.call('GET', KEYS[2])-- 检查传入的新版本号是否小于缓存中的版本号
if cacheVersion and tonumber(cacheVersion) >= tonumber(ARGV[1]) then-- 如果新版本号小于或等于缓存中的版本号，则不更新缓存return 0
end-- 更新缓存中的值
local result = redis.call('SET', KEYS[1], ARGV[2])
-- 更新缓存中的版本号
result = redis.call('SET', KEYS[2], ARGV[1])return result

然后将该脚本加载到服务中

redis-cli -a 111111 script load "$(cat version.lua)"

会返回一段 sha 码 057995d53a5f06cabc5e16a6c3ffdee666752f9

执行EVALSHA 命令

 EVALSHA 057995d53a5f06cabc5e16a6c3ffdee666752f95 2 name_1118 name_1118_v 5 ybb

消息队列

让更新请求都跑到消息队列上排个队，保证同一时刻只有一个线程在更新数据。

可以参考缓存模式中的 Refresh Ahead，且在回写缓存时，使用 SETNX 命令。