When we use Redis, we usually set an expiration time, of course, there is no expiration time, that is, never expire.

When we set the expiration time, how redis determines whether it is expired or not, and what policy is used to delete it.

Redis sets the expiration time:

Expire key time(in seconds) – this is the most common

Setex (String Key, int seconds, String Value) – String unique mode

Note:

With the exception of the string’s own methods that set the expiration time, all methods rely on the expire method to set the time

If no time is set, the cache will never expire

If you set an expiration time and then want the cache to never expire, use the Persist key

There are three expiration strategies:

Time to delete

Description: When setting the expiration time of a key, a timer is created for the key to delete the key when the expiration time comes

Advantages: Ensure that the memory is released as soon as possible

Disadvantages:

  • If there are a lot of expired keys, deleting these keys will take up a lot of CPU time. In the case of tight CPU time, the CPU cannot spend all of its time doing important things, but also needs to spend time deleting these keys
  • Timer creation time. If a timer is created for each key whose expiration time is set (a large number of timers are generated), performance is seriously affected

Lazy delete

Description: The key is not deleted when it expires. Each time the key is obtained, the system checks whether the value is expired. If the value is expired, the system deletes it and returns NULL.

Advantages: The delete operation only occurs when the key value is passed, and only the current key is deleted, so the CPU time is relatively small, and the deletion is already necessary (if not deleted, we will obtain the expired key).

Disadvantages: Memory leaks can occur if a large number of keys are not fetched for a long time after the timeout period (useless garbage takes up a large amount of memory)

Periodically delete

Description: Delete an expired key every once in a while

Advantages:

  • Reduce CPU usage by limiting the duration and frequency of delete operations – Deal with the disadvantages of “scheduled delete”
  • Periodically delete expired keys – Deal with the downside of lazy deletes

Disadvantages:

In terms of memory friendly, it is not as good as “timed delete” (which takes up a certain amount of memory, but not as much memory as “lazy delete”) in terms of CPU time friendly, it is not as good as “lazy delete” (which periodically compares and deletes operations, but is better than timed deletion)

Difficulty: Reasonably set the execution duration of deletion operation (how long is the execution duration of each deletion) and the execution frequency (how long is the execution frequency of each deletion) (this depends on the server running condition). Too long execution time or too high execution frequency will put pressure on CPU.

After each periodic deletion operation is performed, it is necessary to record which flag bit the traversal cycle reached, so that the next periodic time comes, the cycle will start from the last position

Note: Memcached only uses lazy deletion, while Redis uses both lazy deletion and periodic deletion. This is another difference between the two.

Setnx key2 value2: This method is similar to memcached’s add method in that if key2 already exists, it returns false and does nothing; If the set key2 does not exist, this method sets the cache key2-value2. If key2 is already in redis, the setnx method will return false. If key2 is not deleted, the setnx method will return false. Expiration check key2).

Expiration strategy adopted by Redis

Lazy delete + delete regularly

Lazy deletion process:

  • Before performing operations such as GET or setnx, check whether the key is expired.
  • If the key expires, delete it and perform related operations.
  • If no, directly perform the corresponding operation.

Periodic deletion process (in simple terms, randomly delete less than or equal to a specified number of expired keys for each library of a specified number of libraries) :

  • Iterate through each database (the number of “databases” specified in redis.conf, default is 16)
  • Check the specified number of keys in the current library (default: 20 keys per library, note that the loop is executed 20 times, as described below)
  • If no key in the current library is set to expire, the next library is traversed directly
  • Obtain a random key with an expiration time and check whether the key expires. If the key expires, delete it
  • Check whether the periodic deletion has reached the specified period. If so, exit the periodic deletion.

For periodic delets, there is a global variable current_db in the program to record the number of libraries to be traversed. Suppose there are 16 libraries, and we have traversed 10 of them on this periodic deletion, so the current_DB would be 11. The next periodic deletion would start on the 11th library. Assuming current_db is equal to 15, then the loop starts again at library 0 (where current_db==0).

conclusion

In practice, if we want to design our own expiration policy, when using lazy deletion + periodic deletion, it is particularly critical to control the duration and frequency, which needs to be adjusted according to the server performance, the amount of concurrency, etc., so as to achieve the best.

Welcome to Java and big data friends to join the Java architecture exchange: 855835163 group provides free architecture information and: Java engineering, high performance and distributed, high performance, simple to understand. High architecture. Performance tuning, Spring, MyBatis, Netty source analysis and big data and other knowledge points of advanced advanced dry goods free live explanation can come in together to learn and exchange oh