Shulou(Shulou.com)05/31 Report--

Editor to share with you what Redis data deletion methods, I believe that most people do not know much about it, so share this article for your reference, I hope you will learn a lot after reading this article, let's go to know it!

Delete 1.DEL and UNLINK synchronously and asynchronously

The deletion of Key by Redis service itself can be divided into "synchronous deletion" and "asynchronous deletion". Using the DEL command triggers synchronous deletion, and if Key is a complex type with many elements, this process may block the Redis service itself, affecting user access. If you use the UNLINK command, the Redis service first calculates the cost of deleting the Key, making a more intelligent choice of "synchronous deletion" or "asynchronous deletion". Note that the UNLINK command is available only after version 4.0.

two。 Cost calculation

So, how is the cost calculated? For the object type of list,hash,set,zset, if the length is greater than 64 (defined by the macro LAZYFREE _ THRESHOLD), asynchronous deletion will be used. The key will be released from the current db first, and then asynchronously deleted by another thread. For complex types whose length is no more than 64, asynchronous deletion has some more cost of function call and multi-thread synchronization than synchronous deletion, so synchronous deletion is better. For string objects, the underlying data structure sds is a continuous piece of memory, and the complexity of reclaiming this memory by the memory allocator is O (1), so synchronous deletion will not block the service.

In general, we, as users, can replace DEL with UNLINK.

The expulsion of Key 1. Define

Redis processes Key evictions based on whether the memory capacity reaches the upper limit before processing the command.

two。 Expulsion strategy

Redis selects different eviction strategies through the parameter maxmemory:

Volatile-random expels data from any choice of dataset with an expiration time set (server.db[ I] .expires); volatile-lru picks the least recently used data from the dataset (server.db[ I] .dict) (2.8default)

Volatile-ttl looks for the key that is about to expire (minimum ttl) from the dataset (server. DB [I]. Expires) that has been set to expire.

Allkeys-random expels data from any choice in the dataset (server. DB [I]. Dict)

Allkeys-lru picks the least recently used data from the dataset (server. DB [I]. Dict) to expel.

Noeviction forbids data expulsion, never expels data, and returns only an error for write operations (4.0 default)

After version 4.0, the following two expulsion strategies have been added.

Volatile-lfu uses LFU chains in expired collections to expel data

Allkeys-lfu uses the LFU algorithm to expel data from the dataset (server. DB [I]. Dict).

3. Brief introduction

Redis checks to see if the capacity reaches the limit before processing the command.

If the eviction policy is noeviction, the Key is not expelled, but a write failure is returned. After 4.0, before returning the write failure, it will also check whether the lazyfree thread still has a Key to be deleted, and then the write failure will be returned to the user.

For other strategies, the expulsion of Key will be carried out according to the corresponding definition, which will not be discussed in detail here.

In version 4. 0 or later, the expulsion of Key will be based on the parameter lazyfree_lazy_eviction to decide whether to use unlink or del. In version 2. 8, only del is used. The lazyfree_lazy_eviction parameter is no on Qcloud 4.0.

May I ask here, will both master and slave nodes be "expelled"?

The answer is yes, each will be expelled according to its own expulsion strategy, and the delete order for Master node expulsion will also be propagated to the Slave node.

The visit of Key eliminated 1. Define

Accessing an expired Key triggers its deletion.

two。 Brief introduction

Like Key's eviction, Key's access elimination is also triggered based on access events.

The nodes of the master-slave role have different logic in dealing with access elimination.

For Slave nodes, accessing an expired Key,Slave node will return that the Key does not exist, but will not actively delete the Key. The deletion will still be synchronized from the Master.

For Master nodes, version 4. 0 or later will decide whether to use DEL or UNLINK based on the parameter lazyfree-lazy-expire. For version 2. 8, you can only use DEL. These deletions are synchronized to Slave and AOF files.

In versions above Qcloud 4.0, asynchronous deletion is enabled by default, that is, lazyfree-lazy-expire=yes

Timing elimination of Key 1. Define

Redis's own scheduled schedule removes the expired Key.

two。 Brief introduction

How often will the scheduled scheduling be carried out?

The parameter hz of the redis service can control the frequency of timing elimination. Hz defaults to 10, that is, it can be scheduled 100 times per second.

The logic of "visit elimination" just now will only happen in the Master role, so will "visit elimination" also happen?

Generally speaking, the Slave node will not be eliminated regularly, it will only wait for the delete command synchronized from the Master node, thus maintaining the consistency between the master and slave. However, sometimes, users will set the Slave node to be writable, so the Key with expiration time written on Slave will not be eliminated because Master is not aware of it. So after version 4. 0, Redis adds separate logic to remove these expired Key written on slave nodes in timing elimination.

Let's describe "SLOW elimination" below.

SLOW elimination mode. Take hz=10 as an example. The total time for each schedule is 100ms. Here, no 25% of the cpu time is scheduled, that is, 25ms.

For every number of key eliminated, will it be tested whether it exceeds the 25ms?

If you test every time you eliminate 1 Key, it will undoubtedly cost too much. From the point of view of the source code, timing elimination will try to traverse each db and exit the loop after traversing or when the time is up. The first layer loop is to traverse each db, the second layer loop is to traverse the batches of key in the db, and a batch of key is 20. If more than 5 key are successfully eliminated after the end of the third layer cycle (indicating that this db eliminates a lot of key), then the second layer continues the cycle. If it is less than or equal to 5 key, it means that there are not many key to be eliminated in this db, then exit the second layer loop. The third loop is a batch of key that is eliminated one by one key. That is, a maximum of 320 key is judged to see if the cpu elapsed time has been exceeded.

In version 4. 0 or above, DEL or UNLINK will be done based on the parameter lazyfree-lazy-expire (default no). Above version 4.0 of Qcloud, it will be specially configured as yes in order to use UNLINK operation as much as possible. Version 2.8 does not support lazyfree-lazy-expire, so you can only choose the DEL command.

The timing elimination here will also be propagated to the Slave node and recorded to the AOF file in the form of a command.

The above is all the contents of the article "what are the ways to delete Redis data?" Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

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.