Shulou(Shulou.com)06/02 Report--

This article mainly introduces "the expiration time of redis and the principle of expiration deletion mechanism". In daily operation, I believe that many people have doubts about the expiration time of redis and the principle of expiration deletion mechanism. Xiaobian consulted all kinds of materials and sorted out simple and easy-to-use operation methods. I hope it will be helpful to answer the doubts about "expiration time and expiration deletion mechanism principle of redis". Next, please follow the editor to study!

One: set the expiration time

Redis has four commands that can be used to set the time to live and expire for keys:

EXPIRE: set the key lifetime to ttl seconds PEXPIRE: set the key lifetime to ttl milliseconds EXPIREAT: set the key expiration time to the number of seconds specified by timestamp timestamp PEXPIREAT: set the key expiration time to the millisecond timestamp specified by timestamp. Second: save the expiration time

So how is the information about the expiration time and survival time of these key saved in redis?

Answer: the expiration time of all keys in the database is saved in the expires dictionary in the database structure redisDb. We call the expire dictionary an expired dictionary.

(1) an expired dictionary is a pointer to a key object in the key space.

(2) the value of the expiration dictionary is an integer of type longlong, which holds the expiration time of the database key pointed to by the key-a millisecond UNIX timestamp.

The following figure is an example of a database with an expired dictionary:

Expired dictionaries are stored in the redisDb structure:

Typedef struct redisDb {... Dict * dict; / / database key space, which holds the dict * expires / / expiration dictionary of all key-value pairs in the database, and the expiration time of keys.} redisDb

From the above structure, we can see that the expire dictionary (expired dictionary) and the dict dictionary (the database key space, which holds all the key-value pairs in the database) are juxtaposed, which shows the importance of the expire dictionary.

Three: remove expiration time

The PERSIST command removes the expiration time of a key:

127.0.0.1 OK127.0.0.1:6379 > set message "hello" OK127.0.0.1:6379 > expire message 60 (integer) 1127.0.0.1 OK127.0.0.1:6379 > ttl message (integer) 54127.0.1 > persist message (integer) 1127.0.1 > ttl message (integer)-1

The persist command is the anti-command of the expire command, which looks for a given key in the expiration dictionary and removes it from the expiration dictionary.

For example, in the current state of the database (as shown in the figure above), when removing the expiration time for the key of book:

Redis > persist book (integer) 1

The database will be updated to the following state:

As you can see in the figure, when the PERSIST book command is executed, the book key in the expired dictionary disappears.

Four: calculate and return the remaining survival time

The ttl command returns the remaining lifetime of the specified key in seconds. Pttl returns in milliseconds. Both commands get the remaining lifetime by calculating the difference between the current time and the expiration time.

127.0.0.1 expire minping 6379 > set minping shuxinOK127.0.0.1:6379 > expire minping 60 (integer) 1127.0.0.1 integer 6379 > ttl minping (integer) 57127.0.0.1 integer 6379 > ttl minping (integer) 27127.0.1 integer 6379 > pttl minping (integer) 23839127.0.0.16379 >

The redis source code is:

Void ttlCommand (redisClient * c) {ttlGenericCommand (c, 0);} void pttlCommand (redisClient * c) {ttlGenericCommand (c, 1);} void ttlGenericCommand (redisClient * c, int output_ms) {long long expire, ttl =-1; / * if the key does not exist, return-2 * / if (lookupKeyRead (c-> db,c- > argv [1]) = = NULL) {addReplyLongLong (c mahrow2); return } / * if the key exists * / / * if the survival time is not set, return-1, otherwise return the actual remaining time * / expire = getExpire (c-> db,c- > argv [1]); if (expire! =-1) {/ * the expiration time minus the current time is the remaining time of the key * / ttl = expire-mstime () If (ttl < 0) ttl = 0;} if (ttl = =-1) {addReplyLongLong (CMHI);} else {/ * convert milliseconds to seconds * / addReplyLongLong? Ttl: ((ttl+500) / 1000));}} V: delete policy for expired keys

If a key is expired, will it be deleted from memory immediately after the expiration time? If not, when will it be deleted after expiration?

There are actually three different deletion strategies:

(1): delete immediately. When setting the expiration time of the key, a callback event is created, and when the expiration time is reached, the deletion of the key is automatically performed by the time processor.

(2): lazy deletion. If the key expires, it expires, no matter. Each time you press key from the dict dictionary, check whether the key has expired, delete it if it expires, and return nil, and if it does not expire, return the key value.

(3): delete regularly. Every once in a while, check the expires dictionary to delete the expired keys.

As you can see, the second is passive deletion, the first and third are active deletion, and the first is more real-time. The following is a specific analysis of these three deletion strategies.

Delete now

Deleting immediately ensures the maximum freshness of the data in memory, because it ensures that expired keys will be deleted immediately after expiration, and the memory they occupy will be released. But deleting immediately is the least friendly to cpu. Because deletion takes up cpu time, it will put extra pressure on cpu if it happens when cpu is busy, such as doing intersection or sorting calculations.

And the current redis event processor handles time events-unordered linked list, the time complexity of finding a key is O (n), so it is not suitable to deal with a large number of time events.

Lazy deletion

Lazy deletion means that after a key value expires, the key value will not be deleted immediately, but will not be detected to expire until the next time it is used. So the disadvantage of lazy deletion is obvious: a waste of memory. Both the dict dictionary and the expires dictionary hold information about this key value.

For example, some data that is updated by point in time, such as log logs, may not be accessed for a long time after expiration, so you have to waste so much memory to store log during this time. This can be fatal for redis whose performance depends heavily on memory size.

Scheduled deletion

From the above analysis, immediate deletion will take up a lot of cpu in a short time, while lazy deletion will waste memory over a period of time, so regular deletion is a compromise.

Scheduled deletion is to perform deletion operations at regular intervals, and to reduce the impact of deletion operations on cpu by limiting the length and frequency of deletion operations. On the other hand, timing deletion also effectively reduces the memory waste caused by lazy deletion.

Six: strategies used by redis

The expired key deletion strategy used by redis is lazy deletion plus periodic deletion, both of which are used together.

At this point, the study of "the expiration time of redis and the principle of expiration deletion mechanism" is over. I hope to be able to solve everyone's doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

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.