Redis exists命令bug分析(案例详解)

本文基于社区版redis 4.0.8

1、复现条件版本：

• 社区版redis 4.0.10以下版本
• 使用场景：开启读写分离的主从架构或者集群架构(master只负责写流量，slave负责读流量)

案例：

# 写入一条带过期时间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 #还能查到

2、源码分析

在分析该问题前，需要了解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一直存在。

3、问题解决

在社区版4.0.11以上版本已经修复了该bug：

lookupkeyread函数调用lookupkeyreadwithflags(db,key,lookup_none)lookupkeyreadwithflags函数逻辑如下：

最后，可以升级到4.0.12版本解决该问题。

到此这篇关于redis exists命令bug分析的文章就介绍到这了,更多相关redis exists命令内容请搜索以前的文章或继续浏览下面的相关文章希望大家以后多多支持！