redis 查看key的有效期_Redis的key的过期时间

官方文档：https://redis.io/commands/expire

在key上设置一个过期时间(timeout)，一旦时间到了，这个key将会被自动删除。这种特性术语通常叫做Redis的不稳定性。

一旦设置了过期时间，这个key只能被命令清除、删除或者重写其内容。这些命令包含del、set、getset以及所有的*store命令。这些命令只能改变key对应的value的存储值而不改变过期时间的设置。举个例子，使用incr改变key对应的value、使用lpush添加一个新的元素到lists中、使用hset设置field对应value的值等等这些操作都不影响已经对key设置的过期时间的属性。

设置了过期时间的key依然可以使用persist命令重新持久化。

如果key设置了过期时间，并且尚未被删除，使用rename命令重新命名后，该过期时间将转移到新的key上。事实上，rename命令重命名key后，原始的key对应属性全部发生转移。

如果调用expire或者pexpire时传给一个负值作为参数以及expireat或者pexpireat调用的时候时间戳已经过去，那么该key将直接被删除而不是等待过期。

刷新过期时间

对一个设置了过期时间的key仍然可以调用expire更新其过期时间。这

新版本和低于2.1.3版本的区别

在2.1.3版本之前，如果设置时间触发了修改value的工作，则key将会被删除，这会影响主从复制，之后的版本已经做了修正。

返回值

返回一个整数值

1)如果过期时间被设置成功，返回1

2)如果设置失败或者key不存在，则返回0

Java代码127.0.0.1:6379> flushdb

OK

127.0.0.1:6379> set mykey "Hello"

OK

127.0.0.1:6379> expire mykey 20

(integer) 1

127.0.0.1:6379> ttl mykey

(integer) 16

127.0.0.1:6379> expire m 10

(integer) 0

127.0.0.1:6379> ttl mykey

(integer) -2

127.0.0.1:6379> ttl m

(integer) -2

假设你有一个web服务并且对用户访问过的最新N页数据感兴趣，每60秒记录一次并放在lists中。这样整个list中就会包含有用的信心，如用户对哪个产品感兴趣。这在Redis中非常容易实现：

Java代码  MULTI

RPUSH pagewviews.user: http://.....

EXPIRE pagewviews.user: 60

EXEC

如果用户超过60秒钟未访问网站，则这个key就会被删除，最终只能记录后来的。

这个模式也可以使用incr代替rpush实现：

Java代码multi

incr     pageview.user:: http:......

expire   pageview.user:: 60

exec

Redis Expires

keys的过期时间，Redis并没有设置有效时间，换句话说，这个key将会一直存在直到用户显式删除，如del命令。expire的命令家族将会给key设置一个过期时间，这使得key存储将花费更多的时间。一旦被设置了过期时间，时间一到，key将会被删除。

expire命令可以重新设置key的存活时间。persist命令则会持久化key。

Java代码127.0.0.1:6379> flushdb

OK

127.0.0.1:6379> set str a

OK

127.0.0.1:6379> ttl str

(integer) -1

127.0.0.1:6379> expire str 20

(integer) 1

127.0.0.1:6379> ttl str

(integer) 13

127.0.0.1:6379> set str b

OK

127.0.0.1:6379> ttl str

(integer) -1

127.0.0.1:6379> expire str 100

(integer) 1

127.0.0.1:6379> ttl str

(integer) 97

127.0.0.1:6379> persist str

(integer) 1

127.0.0.1:6379> ttl str

(integer) -1

Expire的精度

在Redis 2.4过期时间的设置并不是高精度的，误差在0到1秒的误差。从2.6开始精度提高到0到1毫秒。

expire 和persist

过期时间的设置是以unix时间的绝对秒存储的(2.6以上版本是绝对毫秒)。也就是说，即使Redis 服务已经停止了，时间也还在流逝。

为了精确度，计算机时间必须保持稳定。如果将rdb文件在两台有较大时差的服务器上移动，有趣的事情将会发生，就像所有的keys均被设置了过期时间一样。

即使实在同一台正在运行的数据库实例上，它将总是检查计算机的时间设置。如果你设置某个key的过期时间是1000秒后，然后设置系统时间延后2000秒，那么该key则立即被删除而不是由1000秒的存活时间。

Expire在Redis中keys的实现

在实现方式上，有两中方法：被动和主动的。

被动方式是指，设置了过期时间的keys只有在客户端访问的时候才会被发现并对其执行删除从操作。

这种方法当然是不够好，因为有些keys是不会被再次访问到的。所以定期随机地检测keys的，对过期的keys执行清楚操作，以便于存key空间中删除。

明确来说，Redis每分钟执行10次检测：

1)在所有的建中随机找到20个设置了过期时间的keys

2)删除其中已经过期的keys

3)如果超过25%的keys被删除，那么从1)开始再次执行，知道被删除的keys比例降低到25%以下

这意味着，任何给定的时刻，被过期删除的keys的数量最大等于每秒钟写操作执行次数除以4的最大值。

过期清楚keys时复制链接和AOF文件的处理

为了保持一致性并获得较好的性能。当一个key过期时，删除AOF文件的del操作在master和slaves之间同步执行，这样不存在一致性错误的可能。

然而，slaves是不可以单独的执行del操作的，而是等待master发送过来的del指令，而此时会携带全部的过期设置信息，所以当slave被选中成为master时，它就可以单独地清楚过期的keys，完全像一个master一样。