Chinaunix首页 | 论坛 | 认证专区 | 博客 登录 | 注册
  • 博客访问: 4177944
  • 博文数量: 1631
  • 博客积分: 18684
  • 博客等级: 上将
  • 技术积分: 14343
  • 用 户 组: 普通用户
  • 注册时间: 2010-06-02 10:28
  • 认证徽章:
文章分类

全部博文(1631)

文章存档

2017年(49)

2016年(47)

2015年(15)

2014年(21)

2013年(45)

2012年(152)

2011年(241)

2010年(276)

2009年(420)

2008年(294)

2007年(30)

2006年(38)

2005年(2)

2004年(1)

微信关注

IT168企业级官微



微信号:IT168qiye



系统架构师大会



微信号:SACC2013

订阅
热词专题

分类: LINUX

原文地址:一次Redis TTL 为0的问题排查 作者:yufulou


转自:http://weibo.com/p/1001603826167751818570

如果redis为主从结构,判断一个key是否失效,不能只判断get的结果,还需要结合ttl的结果

事情是这样的,今天中午业务突然RTX上找我,说一个新建的Twemproxy集群数据查询的时候出了问题,RedisTTL返回为0,让我帮忙看一看:


 当时听完就觉得问题很诡异,按照之前的经验来说,RedisTTL怎么也不可能为0啊,见:http://redis.io/commands/ttl

 Rediskey,通过TTL命令返回key的过期时间,一般来说有3中:

1.   当前key没有设置过期时间,所以会返回-1.

2.   当前key有设置过期时间,而且key已经过期,所以会返回-2.

3.   当前key有设置过期时间,且key还没有过期,故会返回key的正常剩余时间.

所以,十分疑惑为何会出现keyTTL0的情况,当时第一感觉问题会不会出现在Twemproxy里面,于是让复杂源码开发的同事查一下twemproxy中是否有对ttl命令的二次处理,于此同时登录到那台twemproxy上,ttl查看相关key,确认结果确实为0,如下图所示:

遇到这种问题,首选怀疑是否是个例,于是自行插入key测试:


 测试过程如上图所示:

1.   setex a 10 1;设置一个key a,过期时间10s,值为1.

2.   通过TTL命令查看a的剩余过期时间,结果为6s.

3.   等待一会儿,再次TTL查看,key的过期时间竟然为0

果然不是个别现象。同时源码的同事反馈,twemproxy本身并未对ttl命令做过任何处理,故我们通过内部的find_key工具,获取该key所在的hash环上的real server(一致性hash算法),到所在的redis再确认一下:


        看来确实是redis本事的问题,我们开始怀疑是Redis的内部出现的bug,于是在其他版本上进行了测试,返回的结果都是正确的,看来版本bug的可能性很高,但是并不能确定。

   我们又在其他的同版本实例上, 进行了同样的测试,但是却并未发现TTL返回0的情况。看来只能去查看源码了。

   于是我们查看了redis对于ttl这个命令的源代码,代码如下:

    代码中确实出现了TTL = 0 的情况,理论上对于存在过期时间的key,应该返回-2才对,而这个代码中,第一个if语句(应该返回-2)并没有执行,才导致调入了第二个循环里,而理论上当前的key的过期时间一定小于当前时间戳(且不为-1),所以TTL应该是小于0,而在代码里,作者将TTL<0的情况处理成TTL=0,那问题就在为什么第一个个if没有生效上了,既该条件的主要判断函数lookupKeyRead并没有返回NULL再查看该函数的代码:


从这开始终于看出点端倪了,该函数之所以没有返回NULL,也是由于第一个if语句并没有return NULL,从代码的评论中可以看出,当redis作为slave的时候,是可能不返回NULL的。


expireIfNeeded函数的注释中可以看到,当当前的RedisSlave时,为了保证主从数据的一致性,是并不会将当前key删除的,触发这一句:if (server.masterhost != NULL) return now > when;当前的时间now一定是大于key存储的过期时间的,故该函数还是返回了1,这样又回到lookupKeyRead,函数中。下面的这段函数起到决定性作用:

以下几个条件满足的时候,该函数才会Return NULL

1.   当前链接存在

2.   当前链接不是master

3.   当前链接的命令存在

4.   当前链接的命令flagsREDIS_CMD_READONLY的与为True

前三个比较在测试过程中,一定是为True的,问题在第四个条件上,这里又引出了Redis Commandflags,在客户端,通过client list,可以查看到当前链接的flags


可以看到,执行ttl命令的flagsN,而在下面的代码中可以看出flags=N时,表示flags=0,所以在上面的代码中,flags & REDIS_CMD_READONLY = 0 &2REDIS_CMD_READONLY = 2redis.h中定义),故这个if语句也没有进入,所以并没有返回NULL,因此导致ttlGenericCommand命令返回了TTL=0的结果。(至于redis使用这些flags的原理以及上面的if语句的原理,还需要更加深入的分析,这里就不再阐述了)

所以,这种情况下,我们才知道,如果一个redis作为slave,且将slave-read-only设置为off,并写入了一个带有TTLkey时,当key过期后,该key是不会被Redis删除的,且TTL在过期后永远为0

带着这样的判断,我们在该redis上执行info命令确认了一下,果然该redisslave,咨询了相关部署的同事得知,该业务在进行数据迁移过程中,存在多级复制和双写的情况,所以才将redis slave设置为可写状态,此时将slaveslaveof 设置成no one,既断开同步,再次排查所有过期keyTTL都返回-2了。

所以,使用Redis的童鞋们,注意一下,在进行服务迁移等情况所构成多级复制链的时候,在relay上进行过期key的读写处理的时候需要注意TTL带来的问题,若以后遇到TTL返回等于0的时候也可以第一时间确定问题所在了。

(感谢@流木东 的技术支持)
阅读(82) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~
评论热议
请登录后评论。

登录 注册