Set an expiration time (timeout) on the key. Once the time expires, the key will be automatically deleted. This feature term is often called Redis instability.
Once the expiration time is set, the key can only be cleared, deleted, or its contents rewritten by command. These commands include del, set, getset, and all *store commands. These commands can only change the stored value of the value corresponding to the key without changing the setting of the expiration time. For example, using incr to change the value corresponding to the key, using lpush to add a new element to the lists, using hset to set the value of the field corresponding to the value, etc. These operations do not affect the expiration time attribute that has been set for the key.
Keys with an expiration time set can still be re-persisted using the persist command.
If the key has an expiration time set and has not been deleted, after renaming it with the rename command, the expiration time will be transferred to the new key. In fact, after the rename command renames the key, all the attributes corresponding to the original key are transferred.
If expire or pexpire is called with a negative value as a parameter and the timestamp has passed when expire or pexpireat is called, then the key will be deleted instead of waiting for expiration.
refresh expiration time
For a key with an expiration time set, you can still call expire to update its expiration time. This
The difference between the new version and the version lower than 2.1.3
Before version 2.1.3, if the setting time triggers the work of modifying the value, the key will be deleted, which will affect the master-slave replication. Later versions have been corrected.
return value
returns an integer value
1) If the expiration time is set successfully, return 1
2) If the setting fails or the key does not exist, return 0
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
Suppose you have a web service and are interested in the latest N pages of data that the user has visited, recorded every 60 seconds and placed in lists. This way the entire list will contain useful confidence, such as which product the user is interested in. This is very easy to implement in Redis:
MULTI RPUSH pagewviews.user:<userid> http://..... EXPIRE pagewviews.user:<userid> 60 EXEC
If the user does not visit the website for more than 60 seconds, the key will be deleted, and only later ones will be recorded.
This pattern can also be implemented using incr instead of rpush:
multi incr pageview.user:<userid>:<productid> http:...... expire pageview.user:<userid>:<productid> 60 exec
Redis Expires
The expiration time of keys, Redis does not set the validity time, in other words, the key will exist until the user explicitly deletes it, such as the del command. The expire command family will set an expiration time for the key, which will make key storage take more time. Once the expiration time is set, the key will be deleted when the time expires.
The expire command can reset the lifetime of the key. The persist command will persist the key.
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
Accuracy of Expire
The setting of the expiration time in Redis 2.4 is not high-precision, and the error is between 0 and 1 second. Accuracy improved to 0 to 1 millisecond starting from 2.6.
expire and persist
The setting of the expiration time is stored in absolute seconds of unix time (the version above 2.6 is absolute milliseconds). That is, even if the Redis service has stopped, time is still running.
For accuracy, computer time must remain stable. If the rdb file is moved between two servers with a large time difference, interesting things will happen, as all keys are set to expire.
Even on the same running database instance, it will always check the computer's time setting. If you set the expiration time of a key to be after 1000 seconds, and then set the system time to delay by 2000 seconds, then the key will be deleted immediately instead of by the 1000 second time-to-live.
Implementation of Expire keys in Redis
In terms of implementation, there are two methods: passive and active.
Passive mode means that keys with an expiration time set will only be discovered and deleted when the client accesses them.
This method is of course not good enough, because some keys will not be accessed again. Therefore, regularly and randomly detect keys, and perform clear operations on expired keys so that they can be deleted from the key space.
Specifically, Redis performs 10 checks per minute:
1) Randomly find 20 keys with expiration time set in all constructions
2) Delete the keys that have expired
3) If more than 25% of the keys are deleted, then execute again from 1) until the proportion of deleted keys is reduced to less than 25%
This means that, at any given moment, the maximum number of expired keys is equal to the maximum number of write operations performed per second divided by 4.
Processing of copy links and AOF files when keys are expired and clear
For consistency and better performance. When a key expires, the del operation to delete the AOF file is performed synchronously between the master and slaves, so there is no possibility of consistency errors.
However, the slaves cannot perform the del operation alone, but wait for the del command sent by the master, which will carry all the expired setting information at this time, so when the slave is selected to become the master, it can separately clear the expiration date keys, exactly like a master.