When the candidate was asked questions about redis during the interview, a phenomenon was found: some candidates could not distinguish between the “key expiration strategy” and the “memory elimination strategy” of redis. Today, let’s talk about the two brothers.
Simply put, the expiration policy is how redis deletes a key when it reaches the specified expiration time; The obsolescence strategy refers to how redis handles when memory is insufficient.
Redis has two key expiration methods: passive and active.
**Passive mode: * * when the client tries to access an expired key, redis finds that the key has expired and deletes it.
**Active mode: * * set a timer for each key with an expiration time set, and delete the key when the expiration time is reached.
The problem with passive mode is obvious. Some keys may not be accessed for a long time, or even never be accessed, wasting memory resources.
There is also a problem with the active mode. You need to constantly check whether the key has expired, which consumes too much CPU resources.
There is also a method of regular deletion. For example, after 30s, you can scan the keys that have set the expiration time and delete those that have expired. This approach seems to combine the advantages of the first two, but it is still too rough.
So, how does redis handle expired keys? The answer is that the passive + optimized version is deleted regularly. Passive has been said. Let’s see how redis optimizes periodic deletion.
How redis does it:
- Randomly select 20 keys with expiration time
- Delete the keys that have reached the expiration time
- If more than 1/4 (5) of the 20 selected keys have expired, repeat step 1 until the expired keys are less than 1/4
The above steps are performed 10 times per second.
Redis achieves a balance between memory and CPU resources through this passive + optimized version of periodic deletion, which neither makes invalid keys occupy too much memory, nor consumes too much CPU for scanning.
In redis 2.4 and earlier versions, the expiration time may not be very accurate, with an error of less than 1 second.
Since redis 2.6, the expiration time error has been reduced to less than 1ms.
Redis supports the following memory obsolescence strategies:
Allkeys stands for all keys, volatile stands for only keys with expiration time
Noeviction: when the memory is not enough, the client returns an error when trying to execute a command that may use more memory (except del and a few exceptions).
LRU: delete the least recently used key to make room for new data.
Random: randomly delete keys to make room for new data.
TTL: delete the key with the shortest TTL (time to live) to make room for new data.
It should be noted that under the volatile LRU, volatile random and volatile TTL policies, if a key that does not meet the conditions (for example, a key without an expiration time) is found, the processing method is basically based on noeviction.
Obsolescence strategy best practices:
- It is recommended to use allkeys LRU when you want the keys to have a power-law distribution (similar to the two eight rule, 20% of the keys receive 80% of the visits).
- If your access to keys is average and belongs to the type of rain and dew, it is recommended to use allkeys random.
- If most of your keys are expired, volatile TTL is recommended.
Object: key with expiration time
Problem solving: how to handle the expired key
Object: all keys (or only for expire keys)
Problem solving: what to do when the memory is insufficient
Although they look very similar, they do not do the same thing. There is no direct relationship between them and they will not affect each other.