In addition to Weibo, there is also WeChat
Please pay attention
WeChat public account
Shulou
2025-01-18 Update From: SLTechnology News&Howtos shulou NAV: SLTechnology News&Howtos > Database >
Share
Shulou(Shulou.com)06/01 Report--
Today, I would like to share with you an article about Redis about expired keys, which has four main contents:
How to set the expiration key how to cancel the expiration time of the expiration key what is the expiration policy of the expiration key RDB AOF and replication what is the handling of the expiration key
Set the survival time or expiration time of the key
Redis-there are 4 commands to set the survival time of the key (how long it can live) or the expiration time (when it is deleted)
Expire: set the survival time of key to ttl seconds pexpire: set the survival time of key to ttl milliseconds expireat: set the expiration time of key to the number of seconds specified by timestamp pexpireat: set the expiration time of key to the millisecond timestamp specified by timestamp
The above four commands are essentially implemented through the pexpireat command.
Example: 127.0.0.1 set a testOK127.0.0.1:6379 > EXPIRE a 5 (integer) 1127.0.0.1 EXPIRE 6379 > get a / / distance set time to live command within 5 seconds of execution of "test" 127.0.0.1 set time command 6379 > get a / / distance set time command 5 seconds later (nil) 127.0.0.1lug 6379 > set b 12OK127.0.0.1:6379 > EXPIREAT b 1545569500 ) 1127.0.0.1 time1 6379 > time1) "1545569486" 2) "108616" 127.0.0.1 time1) "1545569506" 2) "208567" 127.0.0.16379 > get b / / distance setting 1545569500 execute after the timestamp of the number of seconds specified (nil)
If we accidentally set the expiration time incorrectly, then we can delete the previous expiration time
Remove expiration time
The persist command removes the expiration time of a key, such as a chestnut:
127.0.0.1 EXPIRE c 1000 (integer) 1127.0.0.1 ttl c / / Expiration time (integer) 9996127.0.1 ttl 6379 > PERSIST c (integer) 1127.0.1ttl c / / No Expiration time (integer)-1PS:ttl returns the remaining survival time of the key in seconds; similarly, the pttl command returns the remaining survival time of the key in milliseconds
At this point, if we don't remove the expiration time, when will a key be deleted if it expires?
There are three answers to this question, which represent three different deletion strategies.
Delete policy for expired keys
Scheduled deletion
While setting the expiration time of the key, create a timer that allows the timer to delete the key immediately when the expiration time of the key is approaching.
Pros: the most memory-friendly. The memory occupied by the key can be released in time.
Disadvantages: unfriendly to CPU. Especially in the case of a large number of expired keys, deleting expired keys will take a considerable amount of CPU time. At the same time, when there is no shortage of memory and CPU, using CPU to delete expired keys that the current task does not want to close will undoubtedly affect the response time and throughput of the server.
Lazy deletion
The laissez-faire key expires, but each time a key is read or written from the key space, it is checked to see if the obtained key has expired. Delete the delete if it expires, otherwise return the key. (PS: the key space is a data structure that holds all the key-value pairs in the database)
Advantages: the friendliest to CPU. The expiration check is performed only during the operation, and the target of deletion is limited to the keys that currently need to be processed, and no CPU time will be spent on deleting other expired keys that have nothing to do with this operation.
Cons: not memory friendly. This is very easy to understand, the key expires, but because it has never been accessed, it is retained (unless you manually perform flushdb to empty all key in the current database. Which is equivalent to a memory leak
Delete periodically
Every once in a while, the program checks the database and deletes the expired keys. It is up to the algorithm to decide how many expired keys to delete and how many databases to check.
This strategy is a compromise between the above two strategies, and it is necessary to set the duration and frequency of deletion operations according to the actual situation.
After understanding the deletion policy of expired keys, what strategy does the redis server use to delete expired keys?
In fact, the Redis server uses two strategies: lazy deletion and periodic deletion, and by using it together, the server can balance CPU and memory very well.
Where lazy deletion is the built-in policy of the redis server. Periodic deletions can be set in two ways:
The hz option for configuring redis.conf is 10 by default (that is, 10 times per second. The higher the value, the faster the refresh frequency and the greater the loss of Redis performance.) configure the maximum maxmemory value of redis.conf. When the used memory exceeds the maxmemory limit, the active cleanup policy will be triggered.
RDB's handling of expired keys
Generate RDB file
The program will be checked by keys in the database, and expired keys will not be saved to the newly created RDB file. Therefore, expired keys in the database will not affect the generation of new RDB files.
Load the RDB file
A case-by-case description is required:
If the server is running in master server mode, the program will check the keys saved in the file when loading the RDB file, and the expired keys will not be loaded into the database. So the expired key will not affect the primary server that loads the RDB file. If the server runs in slave mode, it is loaded into the database when the RDB file is loaded, regardless of whether the key is out of date or not. However, because the master-slave server is synchronizing, the data of the slave server will be emptied. So in general, expired keys have no effect on the slave server that loads the RDB file.
AOF's handling of expired keys
AOF file write
When the server is running in AOF persistence mode, if an expired key in the database has not been deleted, the AOF file will not be affected by that expired key and will remain.
When the expired key is deleted, the program appends a DEL command to the AOF file to explicitly record that the key is deleted.
AOF rewriting
During the AOF rewrite process, it will also be checked by the key of the database, and the expired key will not be saved to the rewritten AOF file. Therefore, it will not affect AOF rewriting.
Copy the processing of expired keys
When the server is running in replication mode, the master server controls the action of deleting expired keys from the server in order to ensure the consistency of the data of the master and slave servers.
So how on earth is it controlled?
After the master server deletes an expired key, it sends a DEL command to all slave servers, telling the slave server to delete the expired key after receiving the command from the server.
PS: when receiving a read command from the client to an expired key from the server, it will still return the corresponding value of the key to the client without deleting it.
Summary
The above is the whole content of this article. I hope the content of this article has a certain reference and learning value for everyone's study or work. Thank you for your support.
Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.
Views: 0
*The comments in the above article only represent the author's personal views and do not represent the views and positions of this website. If you have more insights, please feel free to contribute and share.
Continue with the installation of the previous hadoop.First, install zookooper1. Decompress zookoope
"Every 5-10 years, there's a rare product, a really special, very unusual product that's the most un
© 2024 shulou.com SLNews company. All rights reserved.