本文基于社区版Redis 4.0.8
案例：
# 写入一条带过期时间10s的key
10.90.73.147:12345> set luxiu1 1 ex 10
OK
10.90.73.147:12345> get luxiu1
"1"
10.90.73.147:12345> exists luxiu1
(integer) 1
......
#等待10s，待key过期
......
10.90.73.147:12345> ttl luxiu1
(integer) -2 #确定key已经过期了
10.90.73.147:12345> get luxiu1
(nil) #没有问题，该key不存在了
10.90.73.147:12345> exists luxiu1
(integer) 1 #还能查到
10.90.73.147:12345> exists luxiu1
(integer) 1 #还能查到在分析该问题前，需要了解Redis在读写分离模式下读到过期数据的问题：
Redis过期key的删除策略采用惰性删除和定时删除：
惰性删除:主节点每次处理读取命令时，都会检查键是否超时，如果超时则执行del命令删除键对象，之后del命令也会异步发送给从节点。需要注意的是为了保证复制的一致性，从节点自身永远不会主动删除超时数据；
定时删除:Redis主节点在内部定时任务会循环采样一定数量的键，当发现采样的键过期时执行del命令，之后再同步给从节点；
如果此时数据大量过期，主节点采样速度跟不上过期速度且主节点没有读取过期键的操作，那么从节点将无法收到del命令。这时在从节点上可以读取到已经超时的数据。Redis在3.2版本解决了这个问题，在从节点上读取数据之前也会检查键的过期时间来决定是否返回数据。但是，4.0.10版本以下的exists命令实现方式有问题，导致该命令还是查询到过期数据问题。
下面是4.0.10以下版本exists命令实现源码：
问题就在于expireIfNeeded这个函数，它的功能就是惰性删除，判断如果key过期了就进行del，我们是读写分离架构，slave不进行del，如下代码：
直接返回1，并不进行到del操作。
所以exists查询到过期key一直存在。
在社区版4.0.11以上版本已经修复了该bug：
lookupKeyRead函数调用lookupKeyReadWithFlags(db,key,LOOKUP_NONE)
lookupKeyReadWithFlags函数逻辑如下：
最后，可以升级到4.0.12版本解决该问题。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。