Whenever we create a key in Redis, this key is created without any timeout or expiration value. So they live forever in the Redis server, even if they will not be used after a period of time. So it is a good practice to set a timeout for your Redis keys.
Redis key timeout can be set either while creating a new key or at any time after creating the key.
e.g while setting value using the SET command a given key, we can set timeout by using the following options along with the SET command.
EX
seconds -- Set the specified expire time, in seconds.PX
milliseconds -- Set the specified expire time, in milliseconds.KEEPTTL
-- Retain the time to live associated with the key.
Example commands of setting timeout while creating a KEY.
Example commands of setting timeout after creating a KEY.
when the key expires after the specified timeout, the GET command returns (nil).
Redis supports the following operations related to Key expiration.
- Set timeout or time to live for a given key.
- Check the timeout.
- Remove the timeout.
Set timeout — Redis supports below 4 commands to set the timeout.
EXPIRE — sets the timeout in seconds
PEXPIRE — sets the timeout in milliseconds
EXPIREAT — set timeout to the epoch Unix timestamp value in seconds
PEXPIREAT — set timeout to the epoch Unix timestamp value in milliseconds
Check timeout — Redis provides below 2 commands to check the timeout
PTTL — returns the timeout in milliseconds
TTL — returns the timeout in seconds
Remove the expiration or timeout
PERSIST — command to remove the timeout
You can visit the official Redis website to check the commands in detail.
Below are some important points about KEY expirations.
- A key with an expiration time set is called volatile in Redis terminology.
- The timeout or expiration time will be cleared automatically by some commands. The commands which delete or overwrite the value at the provided key will remove the expiration time also. Such commands are DEL, SET, GETSET, and all *STORE commands.
- This means that the commands that conceptually alter the value for a key without replacing its value, will not remove the timeouts. Such commands are INCR, LPUSH, HSET, etc.
- If we rename a key using the command RENAME, the timeout will be transferred to the new key name.
- If we set a -ve value for commands EXPIRE, PEXPIRE, the key will be deleted immediately.
- Similarly, If we set an epoch timestamp value from the past for the commands EXPIREAT, PEXPIREAT, the key will be deleted immediately.
- Note that in both of the above points I have mentioned that the keys will be deleted (instead of expiring), so the event emitted from the command will be del and not expired. Try out this.
- Setting the expiration value to a key that already has some expiration set, the expiration time will be updated to the new timeout value.
What is the accuracy of the key Expiration?
In Redis 2.4 the expire error could be between zero to one second out.
Since Redis 2.6 the expire error is from 0 to 1 millisecond.
How does Redis Stores the expiration time?
Redis stores the expiration information as absolute Unix timestamps in milliseconds (for Redis versions >2.6). So the time flows even when the Redis server is not active. This means that the keys will expire surely whenever the Redis server becomes active again.
To work the expiration accurately, the server clock must be stable even in case of a server crash, system failures, etc.
How Redis expire keys?
A key is passively expired, whenever a client accesses a key and that key has already timed-out.
But there might be some keys that may not be accessed forever, So these keys also need to be expired.
For this situation, Redis does the following.
- Test some random keys from the set of keys having some expiration value.
- Delete the keys that are expired from this randomly sampled keys.
- Repeated steps 1 and 2 until the deleted keys from step 2 becomes less than 25%.
How does Redis handle Expiration in Replicated Redis servers?
In a master-slave replicated setup, the master drives the expiration of keys and the replicated server follows their master.
The replicated servers do not expire the keys themselves, they wait for the DEL command from the master server.
Whenever a key is expired, the master server sends a DEL command to each of its replicated servers, and then replicated servers delete the expired keys.