设置key的过期韶光，超过韶光后，将会自动删除该key。在Redis的术语中一个key的干系超时是不愿定的。
超时后只有对key实行DEL命令或者SET命令或者GETSET时才会打消。 这意味着，从观点上讲所有改变key的值的操作都会使他打消。 例如，INCR递增key的值，实行LPUSH操作，或者用HSET改变hash的field所有这些操作都会触发删除动作。
利用PERSIST命令可以打消超时，使其变成一个永久的key。
如果key被RENAME命令修正，干系的超时时间会转移到新key上面。
如果key被RENAME命令修正，比如原来就存在Key_A,然后调用RENAME Key_B Key_A命令，这时不管原来Key_A是永久的还是设置为超时的，都会由Key_B的有效期状态覆盖。
刷新过期韶光
对已经有过期韶光的key实行EXPIRE操作，将会更新它的过期韶光。有很多运用有这种业务场景，例如记录会话的session。
返回值
integer-reply, 详细的:
1 如果成功设置过期韶光。0 如果key不存在或者不能设置过期韶光。例子
案例: Navigation session
想象一下，你有一个网络做事器，你对用户最近访问的N个网页感兴趣，每一个相邻的页面设置超时时间为60秒。在观点上你为这些网页添加Navigation session，如果你的用户，可能包含有趣的信息，他或她正在探求什么样的产品，你可以推举干系产品。
你可以利用下面的策略模型，利用这种模式：每次用户浏览网页调用下面的命令：
如果用户60秒没有操作，这个key将会被删除，不到60秒的话，后续网页将会被连续记录。
这个案例很随意马虎用INCR代替RPUSH
附录: Redis 过期韶光Keys的过期韶光
常日Redis keys创建时没有设置干系过期韶光。他们会一贯存在，除非利用显示的命令移除，例如，利用DEL命令。
EXPIRE一类命令能关联到一个有额外内存开销的key。当key实行过期操作时，Redis会确保按照规定韶光删除他们。
key的过期韶光和永久有效性可以通过EXPIRE和PERSIST命令（或者其他干系命令）来进行更新或者删除过期韶光。
过期精度
在 Redis 2.4 及以前版本，过期期韶光可能不是十分准确，有0-1秒的偏差。
从 Redis 2.6 起，过期韶光偏差缩小到0-1毫秒。
过期和持久
Keys的过期韶光利用Unix韶光戳存储(从Redis 2.6开始以毫秒为单位)。这意味着纵然Redis实例不可用，韶光也是一贯在流逝的。
要想过期的事情处理好，打算机必须采取稳定的韶光。 如果你将RDB文件在两台时钟不同步的电脑间同步，有趣的事会发生（所有的 keys装载时就会过期）。
纵然正在运行的实例也会检讨打算机的时钟，例如如果你设置了一个key的有效期是1000秒，然后设置你的打算机韶光为未来2000秒，这时key会立即失落效，而不是等1000秒之后。
Redis如何淘汰过期的keys
Redis keys过期有两种办法：被动和主动办法。
当一些客户端考试测验访问它时，key会被创造并主动的过期。
当然，这样是不足的，由于有些过期的keys，永久不会访问他们。 无论如何，这些keys该当过期，以是定时随机测试设置keys的过期韶光。所有这些过期的keys将会从密钥空间删除。
详细便是Redis每秒10次做的事情：
测试随机的20个keys进行干系过期检测。删除所有已经由期的keys。如果有多于25%的keys过期，重复步奏1.这是一个平凡的概率算法，基本上的假设是，我们的样本是这个密钥控件，并且我们不断重复过期检测，直到过期的keys的百分百低于25%,这意味着，在任何给定的时候，最多会打消1/4的过期keys。
在复制AOF文件时如何处理过期
为了得到精确的行为而不捐躯同等性，当一个key过期，DEL将会随着AOF笔墨一起合成到所有附加的slaves。在master实例中，这种方法是集中的，并且不存在同等性缺点的机会。
然而，当slaves连接到master时，不会独立过期keys（会等到master实行DEL命令），他们任然会在数据集里面存在，以是当slave当选为master时淘汰keys会独立实行，然后成为master。
