When using Redis, there is usually an expiration date, but there is also no expiration date. When the expiration time is set, how redis determines whether it is expired or not, and what policy is used to delete it.

Setting expiration Time

  • Expire key time(in seconds) This is the most commonly used
  • Setex (String key, int seconds, String Value) String unique mode

Except for the string’s own expire methods, the expire method is used to set the time. If the expire time is not set, the cache will never expire. If the expire time is set and you want the cache to never expire later, use the persist key

Three expiration strategies

Time to delete

When you set the expiration time of a key, you can create a timer for the key and delete the key when the expiration time is up

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

If the key expires, the system does not delete it. Each time it obtains a value from the key, the system checks whether the value expires. If the value expires, 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 we do not delete the key at this time, we will obtain the expired key.)

Disadvantages:

  • If a large number of keys are not fetched for a long time after the timeout period, memory leaks may occur (useless garbage occupies a large amount of memory)

Periodically delete

Delete expired keys at intervals

Advantages:

  • Reduce the CPU footprint of deletes by limiting the length and frequency of deletes – dealing with the disadvantage of “timed deletes”
  • Delete expired keys periodically – Deal with the downside of lazy deletes

Disadvantages:

  • On the memory-friendly side, it is not as good as “timed deletion” (which takes up some memory, but not as much as lazy deletion)
  • In terms of CPU time friendly, it is not as good as “lazy delete” (periodically comparing and deleting operations, not as good as lazy CPU, but better than timing)

Difficult points:

  • Properly set the execution duration (how long does each deletion take) and the execution frequency (how often does each deletion take) (this depends on the server running condition), each execution time is too long, or the execution frequency is too high on the CPU is a kind of pressure.
  • 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

Description:

  • Memcached only uses lazy deletion, whereas Redis uses both lazy deletion and periodic deletion. This is another difference (and one that redis has over memcached).
  • 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, each library of a specified number of libraries is randomly deleted with less than or equal to a specified number of expired keys

  • Iterate through each database (the number of “databases” specified in redis.conf, 16 by default)
  • 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, we have a global variable currentDB in our program that records a library that we’re going to iterate over, let’s say we have 16 libraries, we’re going to iterate over 10 libraries, so currentDB is going to be 11, and then we’re going to iterate over the 11th library, let’s say currentDB is equal to 15, So I’m going to start from library 0 again (currentDB ==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.

I hope this will help you,Many PHPer will always encounter some problems and bottlenecks when they are advanced. They have no sense of direction because they write too much business code, so they don’t know where to start to improve. I have sorted out some information about this, including but not limited to: Distributed architecture, high scalability, high performance, high concurrency, server performance tuning, TP6, Laravel, Redis, Swoole, Swoft, Kafka, Mysql optimization, shell scripting, Docker, micro services, Nginx, etcI need to poke here PHP advanced architect >>> Practical video, big factory interview documents for free