Use two different strategies to delete expired keys, namely the lazy delete policy and the regular delete policy
1.1 Lazy Delete Policy
When an expired key is accessed, Redis will check whether the key expires. If it expires, it will be deleted immediately. If it has not expired, Redis will continue to process it like a normal key. This approach is called lazy deletion because Redis will only check if it expires when it needs to access a key and delete it after it is found that it expires. The advantage of this strategy is that it can save the CPU overhead of deleting keys, because Redis will only delete keys if needed.
1.2 Regular deletion strategy
Redis also uses a periodic deletion strategy to remove expired keys. Under this strategy, Redis will scan the database every once in a while, look for all expired keys and delete them. This method is called regular deletion, because Redis performs this operation regularly. The advantage of this strategy is that it can ensure that expired keys in the Redis database can be deleted in time, thereby avoiding wasting space.
1.3 Strategy Summary
The default configuration of Redis is to use both lazy deletion and regular deletion strategies. When Redis uses both strategies at the same time, the lazy deletion strategy can save CPU overhead, and the regular deletion strategy can ensure that expired keys are deleted in time.
In some special cases, we may need to adjust the Redis deletion strategy. For example, for some less important data, we can only use lazy deletion strategy to reduce the CPU overhead of Redis. For some more important data, we can only use regular deletion strategy to ensure the correctness of the data. These adjustments can be achieved through the configuration parameters of Redis.
The lazy delete strategy allows Redis to use memory more efficiently, because it checks whether it expires only if it needs to access a key. However, it may cause the expired key to stay in memory for a long time until it is accessed next time. A regular deletion strategy can ensure that expired keys are deleted in time, but may have a certain impact on performance because it requires periodic traversal of the entire database. To balance memory usage and performance, Redis usually uses both strategies.
2. Lazy deletion strategy and the use of regular deletion strategy
Redis's lazy delete policy and regular delete policy are both on by default, so in normal cases, we do not need to make any special configuration to use both strategies.
If you want to adjust Redis's deletion policy, you can configure it in the following ways:
Lazy deletion policy
Redis's lazy deletion strategy is enabled by default. If you want to turn off lazy deletion, you can set the following parameters to no in Redis' configuration file:
# Whether to enable lazy deletion# If set to no, Redis will not use the lazy delete policy# Default is yeslazyfree-lazy-eviction no
Regular deletion policy
Redis's periodic deletion strategy is controlled by a configuration parameter, which defaults to 10 seconds, that is, Redis will check the expired key every 10 seconds and delete the expired key. If you want to change this value, you can modify the following parameters in the Redis configuration file:
# Set the periodic period for Redis to delete policies# Default is 10 seconds# Units in secondshz 100
In the above configuration, we set the period of Redis periodic deletion policy to 100 seconds, i.e. Redis checks for expired keys every 100 seconds and deletes the expired keys.
It should be noted that when Redis uses both lazy deletion and regular deletion policies, the lazy deletion policy will be executed first, that is, Redis will check whether the key expires when there is a client requesting a key, and the regular deletion policy will only work if the lazy deletion policy cannot be met.
3. Why does it cause expired data to be read in Redis
Although the periodic deletion strategy can free up some memory, Redis not the number of random data checks each time to avoid excessive deletion operations having an impact on performance. If there is a lot of expired data and it has not been accessed again, the data will be retained in the Redis instance. These retention data are an important factor in the reason why business applications read expired data.
After the lazy deletion strategy is implemented, the data will only be actually deleted when it is accessed again. If the client reads the remaining expired data from the main library, the main library will trigger the deletion operation. At this time, the client will not read the expired data. However, the slave library itself does not perform a deletion operation, and if the client accesses the remaining expired data from the library, the slave library does not trigger data deletion.
4. Will expired data be returned to the client from the library?
Before Redis 3.2, expired data will be returned from the library. After Redis3.2, expired data will not be returned from the library, and will return empty values, but it may still be read.
If you are using a version before Redis 3.2, then when the library reads the service, it will not determine whether the data expires, but will return expired data. After version 3.2, Redis has made improvements. If the read data has expired, the library will not be deleted, but will return a null value, which avoids the client reading expired data. Therefore, when applying master-slave clusters, try to use Redis 3.2 and above.
Using the version after Redis 3.2, expired data will still be read. This is related to the command used by Redis to set the expiration time. Some commands set the expiration time for data may be delayed on the slave library, resulting in the expiration data that should be expired on the slave library.
4.1 Command description for setting data expiration time
- EXPIRE and PEXPIRE: They set the data to the survival time calculated from the time the command is executed;
- EXPIREAT and PEXPIREAT: They will directly set the expiration time of the data to a specific point in time.
The master and slave library are fully synchronized. When the EXPIRE command is received, the master library executes directly and the full synchronization is completed and sent to the slave library. When the slave library is executed, the survival time will be added based on the current time, and the expiration time will be significantly delayed.
To avoid this situation, use the EXPIREAT/PEXPIREAT command in business applications to set the expiration time of the data to a specific time point to avoid reading outdated data.
Summarize
The above is personal experience. I hope you can give you a reference and I hope you can support me more.