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

}
//如果抽样中过期键的比例低于 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

从节点

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且会持续更新！

如果你觉得这些内容对你有帮助，可以扫码获取！！（备注Java获取）

最后

既已说到spring cloud alibaba，那对于整个微服务架构，如果想要进一步地向上提升自己，到底应该掌握哪些核心技能呢？

就个人而言，对于整个微服务架构，像RPC、Dubbo、Spring Boot、Spring Cloud Alibaba、Docker、kubernetes、Spring Cloud Netflix、Service Mesh等这些都是最最核心的知识，架构师必经之路！下图，是自绘的微服务架构路线体系大纲，如果有还不知道自己该掌握些啥技术的朋友，可根据小编手绘的大纲进行一个参考。

如果觉得图片不够清晰，也可来找小编分享原件的xmind文档！

且除此份微服务体系大纲外，我也有整理与其每个专题核心知识点对应的最强学习笔记：

• 出神入化——SpringCloudAlibaba.pdf

• SpringCloud微服务架构笔记（一）.pdf

• SpringCloud微服务架构笔记（二）.pdf

• SpringCloud微服务架构笔记（三）.pdf

• SpringCloud微服务架构笔记（四）.pdf

• Dubbo框架RPC实现原理.pdf

• Dubbo最新全面深度解读.pdf

• Spring Boot学习教程.pdf

• SpringBoo核心宝典.pdf

• 第一本Docker书-完整版.pdf

• 使用SpringCloud和Docker实战微服务.pdf

• K8S(kubernetes)学习指南.pdf

另外，如果不知道从何下手开始学习呢，小编这边也有对每个微服务的核心知识点手绘了其对应的知识架构体系大纲，不过全是导出的xmind文件，全部的源文件也都在此！

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！
手绘了其对应的知识架构体系大纲，不过全是导出的xmind文件，全部的源文件也都在此！

[外链图片转存中…(img-7oaB3Xs1-1713531286116)]

《互联网大厂面试真题解析、进阶开发核心学习笔记、全套讲解视频、实战项目源码讲义》点击传送门即可获取！