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

Source: Redislabs

Author: Kyle Davis

Translation: Kevin (official account: middleware)

Redis 4.0 brings an amazing function to Redis ecology: Modules (module). Modules is a major transformation of Redis. It is an open environment for custom data types and full-speed computing within Redis. But while most of the attention to this version is focused on Modules, the new version also introduces a very important command, which is the game changer: UNLINK.

You can use the redis-cli connection redis-server to execute the info command to see if the UNLINK command can be used in the current version of redis. The info response will tell you all about the server. In the first part (# Server), one line of the returned result has a value of redis_version. If the value is greater than 4. 0, you can use the UNLINK command. Not all Redis providers are up to date, so it is best to check the redis version before changing the code.

Let's review one of the key architectural features of Redis: single threading. Redis is a single-threaded application in most cases. It only does one thing at a time, so it can do these things faster. Multithreading is a bit complex and introduces locks and other issues that may slow down the application. Although Redis (up to version 4. 0) performs a small amount of operations through multithreading, it usually completes one command before starting another command.

You may not think much about using the DEL command to delete a key value compared to fast reading and writing, but in many cases, deleting data is also important. Like most commands in Redis, DEL commands run in a single thread, and if you get a few thousand bytes of key value, it takes less than a millisecond, which you don't know. However, what happens when you get a key size of megabytes, 100 megabytes, or 500 megabytes? Data structures such as hashes, sorting, lists, and so on will add more data over time, resulting in a dataset of GB size. What happens when you use the DEL command to delete the big Key? Because Redis operates in a single thread, the entire service is waiting when the request is processed, and you need to wait for the command to complete before performing other operations. At the same time, we consider a more complex scenario where the data stored in these keys may already contain tens of millions of small requests, so the application or operator may not really understand how long it will take to delete the data.

Reason will tell us not to run a command like this on a sort set with 1 million elements:

> ZRANGE some-zset 0-1

However, executing the DEL command in the above some-zset collection will take the same time as above-there is no transport overhead, but it will always allocate memory, and you will always get stuck in the CPU busy. Before using UNLINK, you may want to do some non-atomic deletions in conjunction with the SCAN command to avoid the nightmare of constantly allocating memory. No matter which way is used above, it is unacceptable.

As you may have guessed, use the UNLINK command to replace DEL! Syntactically, UNLINK is the same as DEL, but UNLINK provides a more ideal solution. First, it removes the key value from the entire key value space. Then, in another thread, it starts to reclaim memory. From a multithreading perspective, this is a safe operation because it removes the item (in the main thread) from the key space, making it inaccessible to other Redis commands.

If you have a fast-growing key value-regardless of the size of the key value, UNLINK is an O (1) operation (per key; in the main thread). It may take hundreds of milliseconds or more to delete a large value using DEL, while UNLINK will complete in less than a millisecond (including network round trips). Of course, your server will still need to spend some time reallocating memory for that value in another thread (where the job is O (N), where N is the allocation of deleted values), but the performance of the main thread will not be seriously affected by what is going on in another thread.

So, should you replace all DEL commands in your code with UNLINK commands? Of course, in a few cases, DEL is just what you need. Here I can think of two things:

1. In MULTI / EXEC or pipeline, the DEL command is an ideal choice when adding and removing large values. In this case, UNLINK does not immediately free up space, and you may have trouble dealing with busy situations (if memory is full).

2. In more urgent cases, you can write data without quick response to eviction data.

In an ideal environment without extreme memory limits, it's hard to think of not using UNLINK. UNLINK will provide more consistent behavior, overall better performance, and very small code changes (no need to change if the command can be renamed in the client). If UNLINK is appropriate for your application, change your DEL to UNLINK at this point, and then see how its performance improves.

For more high-quality middleware technical information / original / translated articles / materials / practical information, please follow the official account of "Brother Middleware"!

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.