Note: This article mainly refers to the design and implementation of Redis
1. Set Expiration time
- Expire key time (in seconds)-this is the most common way
- Setex (string key, int seconds, string value)--the way the string is unique
How to use: View the xxxxxxxxxxxxxxxxxxxxxx of "Java Enterprise project development Practice"
Attention:
- In addition to the string's own unique way of setting the expiration time, other methods rely on the expire method to set the time
- If no time is set, the cache is never expired
- If you set an expiration time, and then want the cache to never expire, use persist key
2. Three Expiration policies
- Timed Delete
- Meaning: When setting the expiration time of key, create a timer for the key, let the timer expire at key, delete the key.
- Advantage: Ensure memory is released as soon as possible
- Disadvantages:
- If the expiration key is many, deleting these keys will take up a lot of CPU time, in the case of CPU time tense, the CPU can not spend all the time to do the important thing, but also need to spend time to delete these keys
- Timer creation time-consuming, if create a timer for each key setting expiration time (there will be a lot of timers), the performance impact is serious
- No one uses it.
- Lazy Delete
- Meaning: Key expires when not deleted, each time the key from the database to check whether expired, if expired, delete, return null.
- Advantage: Delete operation only occurs when the key is removed from the database, and only delete the current key, so the CPU time is relatively small, and the deletion at this point is already up to the point (if not deleted at this time, we get the expired key)
- Cons: If a large number of keys beyond the timeout period, a long time, have not been acquired, then a memory leak may occur (useless garbage occupies a lot of memory)
- Delete periodically
- Meaning: Delete expired key operation once every interval
- Advantages:
- Reduce the CPU time of a delete operation by limiting the length and frequency of the delete operation-the disadvantage of handling a "timed delete"
- Periodic removal of outdated key--processing "lazy Delete" disadvantage
- Disadvantages
- In memory-friendly terms, it's better to "delete it regularly"
- In the CPU time-friendly aspect, rather than "lazy delete"
- Difficulties
- Reasonable set the execution time and execution frequency of the delete operation (this depends on the server operation)
Attention:
- The above-mentioned database refers to the in-memory database, by default, each REDIS server has 16 databases (about the database settings, look at the code below), the default use of No. 0 database, all operations are the operation of the database number No. 0
# Set the number of databases. The default is 16 libraries, using the default DB 0, you can use "Select 1" to select a database # Note: Because the default use of the No. 0 database, then we do all of the cache operations exist on the No. 0 database, # When you look up in the database number 1th, you will not find the previous set cache # To move the cache on database No. 0 to database 1th, you can use "Move key 1" databases 16
View Code
- memcached just uses lazy removal, and Redis uses both lazy and periodic deletions, which is a different point of the two (which can be seen as a point where redis is better than memcached)
- In the case of lazy deletion, it is not only when the key is obtained that the key is checked for expiration, it is also checked on some methods of setting key (Eg.setnx Key2 value2: This method is similar to the memcached Add method, if the set of Key2 already exists, Then the method returns False, does nothing, and if the set Key2 does not exist, then the method sets the cache key2-value2. Assuming this method is called, it is found that Key2 already exists in Redis, but the key2 has expired, and if the delete operation is not performed at this time, the Setnx method will return false directly, that is, the key2-value2 is not reset at this time. So for this method it is important to check the Key2 before setnx execution)
3. The expiration policy used by Redis
Lazy Delete + Periodic delete
- Lazy removal process
- When doing operations such as GET or SETNX, first check if key is out of date,
- If it expires, delete key and perform the appropriate action;
- If it does not expire, perform the appropriate action directly
- Periodically delete a process
- Traverse each database (that is, the number of "database" configured in redis.conf, which defaults to 16)
- Check the specified number of keys in the current library (the default is 20 keys per library, note that the loop executes 20 times, the description below the loop body)
- If no key in the current library sets an expiration time, the traversal of the next library is performed directly
- Randomly get a key that sets the expiration time, check if the key expires, and if it expires, delete key
- Determine if the periodic delete operation has reached the specified length of time, and if it has been reached, exit the regular delete.
Attention:
- For periodic deletion, there is a global variable current_db in the program to record the next library to be traversed, assuming that there are 16 libraries, we this time the periodic deletion traversed 10, then the current_db is 11, the next periodic deletion from the 11th library began to traverse, Assuming that current_db equals 15, then the traversal will start from Library No. 0 (at this point current_db==0)
- Since the time and frequency of periodic deletions have not been manipulated in practice, how are these two values set up as questions?
4, the RDB to the expired key processing
Expired key has no effect on the RDB
5, aof to the expiration of the key processing
Expired key has no effect on aof
Nineth. Redis Expiration Policy
