到期

语法
EXPIRE key seconds [NX | XX | GT | LT]
从以下位置开始可用：
1.0.0
时间复杂度：
O（1）
ACL 类别：
@keyspace, @write, @fast,

设置超时key. 超时过期后，密钥将自动删除。 在 Redis 中，通常说具有关联超时的密钥是 voltile 术语。

超时只能通过删除或覆盖 密钥的内容，包括DEL,SET,GETSET和所有*STORE命令。 这意味着，所有在概念上更改存储在 密钥而不用新密钥替换它，则超时保持不变。 例如，使用INCR，推送新值 放入一个列表中，其中包含LPUSH更改哈希的字段值，或使用HSET是 将保持 timeout 不变的所有作。

超时也可以被清除，将 key 变回持久 key， 使用PERSIST命令。

如果键重命名为RENAME，则关联的生存时间将传输到 新密钥名称。

如果键被RENAME，就像在现有键的情况下一样Key_A被RENAME Key_B Key_A，如果 原版Key_A是否关联了超时，则新键Key_A将 继承了 的所有特性Key_B.

请注意，调用EXPIRE/PEXPIRE使用非正超时或EXPIREAT/PEXPIREATwith a time in past 将导致密钥被删除而不是过期（因此，发出的密钥事件将为del不expired).

选项

这EXPIRE命令支持一组选项：

  • NX-- 仅当 key 没有 expir 时才设置 expir
  • XX-- 仅当 key 具有现有 expir 时才设置 expiration
  • GT-- 仅当新过期时间大于当前过期时间时，才设置过期时间
  • LT-- 仅当新过期时间小于当前过期时间时，才设置过期时间

非易失性密钥被视为无限 TTL，目的是GT和LT. 这GT,LT和NX选项是互斥的。

刷新过期

可以调用EXPIREusing as 参数中已经有 existing expire 集。 在这种情况下，键的生存时间将更新为新值。 有许多有用的应用程序可用于此目的，下面的 Navigation session pattern 部分中记录了一个示例。

Redis 2.1.3 之前的差异

在 2.1.3 之前的 Redis 版本中，使用 命令更改其值具有完全删除键的效果。 之所以需要这种语义，是因为复制层中的限制 现已修复。

EXPIRE将返回 0，并且不会更改设置了 timeout 的键的超时。

例子

Give these commands a try in the interactive console:

SET mykey "Hello" EXPIRE mykey 10 TTL mykey SET mykey "Hello World" TTL mykey EXPIRE mykey 10 XX TTL mykey EXPIRE mykey 10 NX TTL mykey

Pattern: Navigation session

Imagine you have a web service and you are interested in the latest N pages recently visited by your users, such that each adjacent page view was not performed more than 60 seconds after the previous. Conceptually you may consider this set of page views as a Navigation session of your user, that may contain interesting information about what kind of products he or she is looking for currently, so that you can recommend related products.

You can easily model this pattern in Redis using the following strategy: every time the user does a page view you call the following commands:

MULTI
RPUSH pagewviews.user:<userid> http://.....
EXPIRE pagewviews.user:<userid> 60
EXEC

If the user will be idle more than 60 seconds, the key will be deleted and only subsequent page views that have less than 60 seconds of difference will be recorded.

This pattern is easily modified to use counters using INCR instead of lists using RPUSH.

Appendix: Redis expires

Keys with an expire

Normally Redis keys are created without an associated time to live. The key will simply live forever, unless it is removed by the user in an explicit way, for instance using the DEL command.

The EXPIRE family of commands is able to associate an expire to a given key, at the cost of some additional memory used by the key. When a key has an expire set, Redis will make sure to remove the key when the specified amount of time elapsed.

The key time to live can be updated or entirely removed using the EXPIRE and PERSIST command (or other strictly related commands).

Expire accuracy

In Redis 2.4 the expire might not be pin-point accurate, and it could be between zero to one seconds out.

Since Redis 2.6 the expire error is from 0 to 1 milliseconds.

Expires and persistence

Keys expiring information is stored as absolute Unix timestamps (in milliseconds in case of Redis version 2.6 or greater). This means that the time is flowing even when the Redis instance is not active.

For expires to work well, the computer time must be taken stable. If you move an RDB file from two computers with a big desync in their clocks, funny things may happen (like all the keys loaded to be expired at loading time).

Even running instances will always check the computer clock, so for instance if you set a key with a time to live of 1000 seconds, and then set your computer time 2000 seconds in the future, the key will be expired immediately, instead of lasting for 1000 seconds.

How Redis expires keys

Redis keys are expired in two ways: a passive way and an active way.

A key is passively expired when a client tries to access it and the key is timed out.

However, this is not enough as there are expired keys that will never be accessed again. These keys should be expired anyway, so periodically, Redis tests a few keys at random amongst the set of keys with an expiration. All the keys that are already expired are deleted from the keyspace.

In order to obtain a correct behavior without sacrificing consistency, when a key expires, a DEL operation is synthesized in both the AOF file and gains all the attached replicas nodes. This way the expiration process is centralized in the master instance, and there is no chance of consistency errors.

However while the replicas connected to a master will not expire keys independently (but will wait for the DEL coming from the master), they'll still take the full state of the expires existing in the dataset, so when a replica is elected to master it will be able to expire the keys independently, fully acting as a master.

RESP2/RESP3 Reply

One of the following:

  • Integer reply: 0 if the timeout was not set; for example, the key doesn't exist, or the operation was skipped because of the provided arguments.
  • Integer reply: 1 if the timeout was set.

History

  • Starting with Redis version 7.0.0: Added options: NX, XX, GT and LT.
RATE THIS PAGE
Back to top ↑