关于Redis主从节点数据过期一致性的思考，它真的足够一致了吗？

最新推荐文章于 2023-12-25 14:02:30 发布

置顶 hhgfy

最新推荐文章于 2023-12-25 14:02:30 发布

阅读量1k

点赞数 4

分类专栏： Redis 文章标签： redis 分布式

本文链接：https://blog.csdn.net/m0_38086372/article/details/108308992

版权

Redis 专栏收录该内容

8 篇文章 1 订阅

订阅专栏

本文内容基于 Redis 6.0.6 版本

最近重新读了《Redis设计与实现》，注意到了一些原来没在意的小细节。比如 9.7 AOF、RDB和复制功能对过期键的处理 这节中说到的从节点可能读到过期数据的问题。

单机过期实现方式

在了解从节点读到过期数据这个问题之前，不得不先了解在单机情况下Redis如何实现数据过期功能的。

首先，要明白一点，虽然看起来过期时间一到，过期的键就立即不可见了。但Redis实际上并没有做到实时的过期删除，而是采取了后台定期删除与惰性删除相结合的方式。

定期删除

Redis内部存在一个定时任务（默认每秒运行10次），每次执行时抽查一部分key判断是否过期，碰到过期的键则进行删除。

如果抽样中过期键的比例较高，则继续执行抽查删除，这样可以实现过期键越多，删的速度越快的效果。

当然，在过期键比例非常高时，也不能无止境的陷在抽样删除的循环里，Redis还设置了一次执行的最大时长限制，避免一直阻塞主线程，影响服务

以下是定期抽样删除功能的终止条件部分代码：（仅更改了注释，下文同）

// src/expire.c/activeExpireCycle()
do {
//执行抽样和删除（略）

// 过期键太多时不能永远阻塞下去，需要在指定时间内结束
if ((iteration & 0xf) == 0) { /* check once every 16 iterations. */
    elapsed = ustime()-start; //当前时间 - 开始时间 = 已用时长
    if (elapsed > timelimit) { //达到最大时长限制，break退出 do...while 循环
        timelimit_exit = 1;
        server.stat_expired_time_cap_reached_count++;
        break;
    }
}
//如果抽样中过期键的比例低于 config_cycle_acceptable_stale ，结束循环
//若过期键比例较高，则继续删
} while (sampled == 0 ||
        (expired*100/sampled) > config_cycle_acceptable_stale);

惰性删除

仅凭定期删除会存在删除不及时的问题，但客户端访问可不会等过期键删除完。

所以当访问任意key时，都会先判断它是否处于已经过期但还没来得及删除的状态，如果已经过期则立刻删除，并向上层返回该key不存在。

主从之间的过期

说完了单机情况下键过期的实现方式，再回到最开始的问题：从节点可能读到过期数据。

书里写的原因是：

从节点不会主动删除访问到的过期数据，而是要等主节点数据过期后生成DEL命令发过来。由于定期删除机制不够及时，在到达过期时间点与实际收到DEL命令这段时间内，读取从节点将会获取到本应过期的数据，而不执行惰性删除。

这怎么看都是一个bug吧？网上搜了一圈，都说在Redis 3.2版本修复了该问题，但没有找到具体用什么方式修的。

在官方文档的 Replication 一节中，有部分关于主从之间过期键处理的说明。

大意如下：

实现复制功能不能依靠主从节点的墙上时钟，Redis使用了以下三个方式来处理：

副本不会主动删除过期键，而是等主节点过期时生成 DEL 命令同步至从节点进行删除。
但主节点过期删除不及时，可能会使从节点上存在逻辑上已经过期的键。为了处理该问题，副本采用它自己的 逻辑时钟 来判断读取时键是否应当过期，过期则返回不存在（即使数据仍然在内存中，等着主节点的 DEL 命令）

In order to deal with that the replica uses its logical clock in order to report that a key does not exist only for read operations that don't violate the consistency of the data set (as new commands from the master will arrive).

在Lua脚本运行时，服务器中的时间是冻结的，防止键在脚本运行的过程中过期。这是为了保持副本上执行的脚本能具有相同的效果。（注：不同机器，性能不一样，脚本执行时长也不同）

文档中只给出了一个模糊的 “根据 逻辑时钟 判断” 的描述，没有具体说明实现方式。我只能先来猜一下实现方式，然后去代码里试试能不能找到。

我猜的实现方式

先补充一下背景知识：分布式系统中，网络和本地系统时钟都是 不可靠 的。

既然文档中描述了逻辑时钟，那么我猜测的方式如下：

开始执行 slaveof 的时候，主从节点校对时钟，每个从节点维护一个与主节点的时间差，实现逻辑时钟。

主节点上执行的与过期相关的命令 set k v ex time、expire、expireat、pexpire、pexpireat 等在传播到从节点时通通根据主节点的时钟转成 pexpireat，使用基于主节点的绝对时间。

从节点接到命令时，对这些过期命令加减时间差，实现主从一致的过期。（也就是说一切时间以主节点为准）

实际的实现方式

然而事实证明我完全想多了，Redis代码中关于过期判断的部分完全没有计算时间差的影子。

这里是其中一处过期判断的代码：

// src/db.c
int keyIsExpired(redisDb *db, robj *key) {
    mstime_t when = getExpire(db,key); //从过期字典获取过期时间，没有返回-1
    mstime_t now;
    
    if (when < 0) return 0;// when=-1 永不过期
    if (server.loading) return 0;

    if (server.lua_caller) { //lua脚本中的命令总是使用脚本开始时间
        now = server.lua_time_start;
    } else if (server.fixed_time_expire > 0) { //如 RPOPLPUSH 这种操作多个key的命令也使用命令开始时间，fixed_time_expire 在调用call()时刷新
        now = server.mstime;
    } else {
        now = mstime();
    }
    return now > when;
}

这里没找到解决方式，没办法只能直接去找3.2版本那次修复的提交记录，看看他是怎么改的。

于是我从issues里找到了 Improve expire consistency on slaves 这个关于提高主从过期时间一致性的问题，并在其中发现了对应的提交记录。

结果令人大跌眼镜，总共只有寥寥几行，在过期判断后增加了从节点和只读命令的判断条件，然后返回null。

这下更令人疑惑了，这么说来，主从节点的过期没做区分，都用了本地系统的墙上时钟吗？

只能再换个方向去找了，Redis 还有什么地方可能让主从之间的命令产生区别？没错，在主节点到从节点的命令传播那里说不定能有新发现！

// src/server.c
// 命令传播
void propagate(struct redisCommand *cmd, int dbid, robj **argv, int argc,
               int flags)
{
    if (server.aof_state != AOF_OFF && flags & PROPAGATE_AOF)
        feedAppendOnlyFile(cmd,dbid,argv,argc); // 传给AOF
    if (flags & PROPAGATE_REPL)
        replicationFeedSlaves(server.slaves,dbid,argv,argc); //传给从节点
}

先看了下传播到AOF文件的函数 feedAppendOnlyFile()，在内部它通过catAppendOnlyExpireAtCommand将expire、expireat等过期相关命令全转成了PEXPIREAT，看起来有门哈。

再看向从节点传播命令的 replicationFeedSlaves()，很遗憾找了一圈下来没发现有对过期命令的特殊处理。

没做特殊处理也就意味着 expire、expireat 它们在主从节点上都是按原样执行的。但是，由于判断过期使用了各自的本地系统时钟，会不会导致主从节点之间产生不一致的行为？

使用本地时钟导致的问题

下面分析当主从节点所在机器的系统时间不一致时，将导致什么样的问题。

expire

对于 expire命令，键存活一段指定的时间后过期。即使主从时间不一致，但时长是一样的。

表现出的结果是，客户端同一时刻访问主从节点能得到相同的TTL，要过期也是一起过期，没有问题。

expireat

而 expireat 命令则不同了，由于它指定了一个确定的过期时间点，对单个节点自身来说，确实是实现了到达指定时间点过期的效果，符合命令语义。

但是，站在客户端视角来看，景象就不这么美好了。

在客户端看来，由于主从系统时间存在的偏差，令主从之间一样的时间戳并非实际上的 “同时”。表现出的结果将是，客户端在同一时刻访问主从节点的同一个键，将得到不同的TTL，乃至于一个过期另一个没过期。

虽然仅从语义上看这不能算是错，错的是系统时间。但由此产生的主从表现不一致现象也是需要考虑考虑的。

实际验证

上面只是根据代码推测的结果，接下来实际验证一下是否如此。

准备：需要准备两台机器，时间调成不一样的，并搭建Redis主从复制
- 这里我将本地时间用date -s 调快了1小时，然后执行slaveof复制了另一台机器的上的Redis
验证 expire

# 主节点
set a 1
expire a 1800  #半小时过期

# 主从分别执行TTL， 时间一样（忽略操作时间）

验证 expireat

> expireat a 两小时后
# 主节点
> ttl a
3595

# 从节点
> ttl a
1789

# 两边都没过期，但TTL不一致

#---------------------

> expireat a 半小时后
# 主节点
> ttl a
1797

# 从节点 不存在该键
> ttl a
-2

# 从节点系统时间调快了一小时，键已经被判断为过期不存在了