key的过期时间

通常，Redis key被创建时不会自动关联过期时间，key将长久存在，除非通过DEL等命令显示的删除。EXPIRE命令簇可以为指定的key关联一个过期时间，代价是一点额外的内存开销。当key被设置了过期时间后Redis要保证在超时时移除该key。key的过期时间可被EXPIRE命令更新或者被PERSIST命令完全移除。

过期时间的精度

Redis2.4中expire精度不高，通常在0到1秒间，Redis2.6以后expire精度可以控制在0到1毫秒内。

过期与持久化

key的过期信息以绝对Unix时间戳的形式存储（Redis2.6之后以毫秒级别的精度存储）。这意味着，即使Redis实例没有运行也不会对key的过期时间造成影响。

为了使过期时间更正确的工作，必须检查计算机的时间。如果将RDB快照从一台计算机移动到另一台时间超前或滞后的计算机便会发生好玩的事情，比如数据刚载入便超时。即使是在同一机器的同一实例中若计算机的时间不正确或发生了变化同样为引起问题，比如一批数据的过期时间被设置为了1000，之后计算机时间意外的快了2000秒，那么这些key将立刻过期，而不是1000秒后过期。

Redis如何使key过期

Redis key过期的方式有二：被动方式和主动方式

当clients试图访问设置了过期时间且已过期的key时，为主动过期方式。

但仅是这样是不够的，因为可能存在一些key永远不会被再次访问到，这些设置了过期时间的key也是需要在过期后被删除的。因此，Redis会周期性的随机测试一批设置了过期时间的key并进行处理。测试到的已过期的key将被删除。典型的方式为,Redis每秒做10次如下的步骤：

1.随机测试100个设置了过期时间的key

2.删除所有发现的已过期的key

3.若删除的key超过25个则重复步骤1

这是一个基于概率的简单算法，基本的假设是抽出的样本能够代表整个key空间，redis持续清理过期的数据直至将要过期的key的百分比降到了25%以下。这也意味着在任何给定的时刻已经过期但仍占据着内存空间的key的量最多为每秒的写操作量除以4.

replication link和AOF文件中的过期处理

为了获得正确的行为而不至于导致一致性问题，当一个key过期时DEL操作将被记录在AOF文件并传递到所有相关的slave。也即过期删除操作统一在master实例中进行并向下传递，而不是各salve各自掌控。这样一来便不会出现数据不一致的情形。当slave连接到master后并不能立即清理已过期的key（需要等待由master传递过来的DEL操作），slave仍需对数据集中的过期状态进行管理维护以便于在slave被提升为master会能像master一样独立的进行过期处理。