redis的key的过期机制

redis是一个 高性能的key-value数据库.我们可以对其中的key设置一个过期时间,相关命令如下:

1.在创建一个key value 的时候同时设置过期时间

比如: set key1 value1 EX 60 表示: 我们想要将这个 key value 放到redis中,并在其中保存60秒.

set key2 value2 PX 60 表示:我们想要将这个key value放到redis中,并在其中保存 60毫秒

2.对于已经存在的key value, 

比如: 事先有 set key3 value3

我们想为 key3 设置一个过期时间, 我们可以采用以下命令:  

expire  key3 60  表示: 我们要对已经存在的kye3 设置为 在 60秒之后(无效,或者被删除)

我们可以查看一个key当前的 存活(有效?)时间.

使用ttl key4 即可查看剩余有效时间.

==============================以上命令,没有说明返回值表示的意思================

首先说到 "过期", 比如说一个面包, 其保质期为1天. 那么, 我们怎么判定它的有效期?一般情况, 会在做好面包的时候,在标签上打上一个生产日期, 在我们在消费这个面包的时候, 会把我们当前的日期, 和面包的标签上的有效期做一个对比,假如时间差超过1天, 那么我们就判定这个面包过期了, 就是说,我们为面包设置一个基准点.其实, 也可能有另外一种实现的方式,就是在每个面包做好之后,在上面加一个定期器, 我们在消费这个面包的时候,只要看这个定期器中的显示,就可以知道这个面包是否已经过期.

======================

有了上面的一段啰嗦,现在我们就能对redis中的过期机制,起码有两种实现方式, 方式1, 保存一个起始时间,就是面包例子中的打上生产日期, 附上有效时间. 方式2.每一个key内维护一个类似定时器的东西...(这个做起来,维护成本就太大了...,与高性能的旗号违背), redis中key的过期信息,就是通过保存一个过期时间和起始时间信息来维护的.(说明:redis 2.6及其以上版本用毫秒为单位保存 起始时间,2.6以前版本用 unix时间戳保存,所以存在的误差也可能不一样, 2.4版本误差在1秒以内,2.6版本误差在1毫秒以内)

这就有一个有趣的事情, 就是操作的时候,务必确保当前跑redis的机子上的时间是正确的,(一时间联想到了linux下改个系统时间都需要输入管理员密码的用意何在,防止程序随意修改系统时间,可能会导致一部分需要依赖系统时间的程序无法运行)

做了一个小实验: 设置一个key的有效期为60秒,在60秒内将计算机的时间改到1分钟之后,那么这个key 马上失效(突然联想到之前有些应用时间过了就用不了了....so... ) 

所以, 在我们每次用get 命令去取一个key的时候,先把key找到,再判断这个key是否已经过期(自动联想我们看一个面包是否已经过期...).如果已经过期了, redis就不给我们返回对应的value值了. 这是redis 处理key过期的active方式, 但是 仅仅依靠这种方式是不够的,可以想象,假如,我们放置很多具有有效期的key value在redis中,仅仅是每次都判断一个key是否已经过期,那么到最后,系统中就会存在许多垃圾(已经过期,但是又没有人去清理...). 所以,redis,还会每秒钟执行10次以下的流程:

1.随机抽取100个设定了有效期的key,检查其有效期,如果已经过期,则将其删除.

2.如果抽取到的100个key中超过25个已经过期,那么返回步骤1,

这就是redis中清除已经过期的key的 passive 方法.

=====================================

可能会影响(或者使用者觉得会影响)key有效期的操作.

1.会删除有效期的操作.

 del 命令.

expire命令

set 命令

getset 命令

另外,其他改变值的操作都是不会修改有效期的, (文章原文:. This means that all the operations that conceptually alter the value stored at the key without replacing it with a new one will leave the timeout untouched. For instance, incrementing the value of a key with INCR, pushing a new value into a list with LPUSH, or altering the field value of a hash with HSET are all operations that will leave the timeout untouched.)

此外,还有一个命令,rename . 假如存在 key1 value1 .  并且key1存在一个有效期, 那么使用rename key1 key2.这时候,key2的生存时间也会和原key1保持一致. 另外一种情况: 存在 key1, value1, key2,value2.  并且key1存在一个有效期,  那么使用rename key1 key2.这时候 key2对应的value是 value1, value2将被覆盖,而且 key2的所有characteristics将会被 原key1的所有characteristics. (文章原文: it does not matter if the original Key_A had a timeout associated or not, the new key Key_Awill inherit all the characteristics of Key_B)

这一小段一开始让我疑惑:

If a key is renamed with RENAME, the associated time to live is transferred to the new key name.

If a key is overwritten by RENAME, like in the case of an existing key Key_A that is overwritten by a call likeRENAME Key_B Key_A, it does not matter if the original Key_A had a timeout associated or not, the new key Key_Awill inherit all the characteristics of Key_B.

有   ranamed with rename

...overwritten by rename ... 

===================================

redis删除已过期节点时对于  aof文件以及 主从节点集群时的处理方式

当一个key过期时,redis会同步删除对应的aof文件,假如key分布在主从集群的节点时, 也会同步删除 对应的 slaves上的key.值得注意的是, slaves不会主动删除已经过期的key,而会一直等待master的删除命令. 只有当一个slave成为了master之后,才会主动删除已经过期的key.