一次Redis TTL 为0的问题排查

转自：

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

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

 当时听完就觉得问题很诡异，按照之前的经验来说，Redis的TTL怎么也不可能为0啊，见：

 Redis的key，通过TTL命令返回key的过期时间，一般来说有3中：

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

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

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

所以，十分疑惑为何会出现key的TTL为0的情况，当时第一感觉问题会不会出现在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函数的注释中可以看到，当当前的Redis为Slave时，为了保证主从数据的一致性，是并不会将当前key删除的，触发这一句：if (server.masterhost != NULL) return now > when;当前的时间now一定是大于key存储的过期时间的，故该函数还是返回了1，这样又回到lookupKeyRead，函数中。下面的这段函数起到决定性作用：

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

1.   当前链接存在

2.   当前链接不是master

3.   当前链接的命令存在

4.   当前链接的命令flags于REDIS_CMD_READONLY的与为True

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

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

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

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

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

（感谢@流木东 的技术支持）