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

This article mainly introduces "why redis is single-threaded". In daily operation, I believe many people have doubts about why redis is single-threaded. The editor consulted all kinds of materials and sorted out simple and easy-to-use methods of operation. I hope it will be helpful for you to answer the doubt of "why redis is single-threaded"! Next, please follow the editor to study!

There has always been a misunderstanding that high-performance servers must be multi-threaded.

The reason is simple because of the second misunderstanding: multithreading must be more efficient than single threading. Actually this is not so.

Before talking about this, I hope everyone can have an understanding of CPU, memory, and the speed of the hard disk. In this way, we may have a deeper understanding. Friends who do not understand: how much faster is CPU than memory and hard disk?

The core of redis is that if all my data is in memory, my single-threaded operation is the most efficient, why? because the essence of multithreading is to simulate the situation of multiple threads by CPU, this simulated situation has a price, that is, context switching. For a memory system, it is the most efficient without context. When redis binds a piece of data in memory with a single CPU, and then reads and writes multiple times to the data in that memory, it is done on a single CPU, so it handles this thing in a single thread. In the case of memory, this scheme is the best solution-Ali Shen Xun.

Because a CPU context switch is probably around 1500ns.

It takes about 250us to read the continuous data of 1MB from memory. Assuming that the data of 1MB is read 1000 times by multiple threads, then there are 1000 time context switches.

Then there is 1500ns * 1000 = 1500us. I only 250us after reading 1MB data in a single thread. You use 1500us just to switch the time context. I don't count the time you read a little bit of data each time.

So when do you use multithreading?

The answer is: slow situations such as storage in the lower layer. Like a disk.

Memory is a very high IOPS system, because I want to apply for a piece of memory to apply for a piece of memory, destroy a piece of memory I destroy a piece of memory, memory application and destruction is very easy. And the memory can be applied for size dynamically.

The characteristic of the disk is that IPOS is very low, but the throughput is very high. This means that a large number of read and write operations must be saved together and then submitted to disk with the highest performance. Why?

If I have a transaction group operation (that is, several separate transaction requests, such as write, read, read, write, and so on), I can do it one by one in memory because the IOPS is very high, but if there is such a request on disk.

My first write operation is like this: first I address on the hard disk, which probably costs 10ms, then I read a data that may cost 1ms, and then I calculate (ignore it), and then write back to the hard disk is 10ms, a total of 21ms

The second operation took 10ms to read, the third to write cost 21ms, and then I read 10ms, write 21ms, five requests cost a total of 83ms, which is the best case, if it is in memory, probably less than 1ms.

So for the disk, with such a large throughput, the best solution must be for me to put N requests together in a buff and submit them together.

The method is asynchronous: the request and the processing thread are not bound, the requesting thread puts the request in a buff, and then the processing thread processes the buff when the buff is almost full. Then the buff is unified to write to the disk, or read the disk, so that the efficiency is the highest. Isn't that what IO in java does?

This is the best way to deal with slow devices, such as disk, network, SSD, etc.

It is common to deal with these problems in a multithreaded, asynchronous way, as the famous netty does.

Finally, I made it clear why redis is single-threaded, and when to use single-threading and multithreading. In fact, it is also a very simple thing, but when the foundation is not good, it is really embarrassing.

Make up a master quote: let's talk about why a single core cpu binds a piece of memory with the highest efficiency.

"We can't let the operating system load balance, because we know our own programs better, so we can manually assign the CPU core to it without taking up too much CPU." by default, a single thread will randomly use the CPU kernel when making system calls. In order to optimize Redis, we can use tools to bind a fixed CPU kernel for a single thread to reduce unnecessary performance loss!

As a program of single-process model, redis often starts multiple instances on a single server in order to make full use of multi-core CPU. In order to reduce the switching overhead, it is necessary to specify the CPU on which each instance is running.

Taskset on Linux can bind a process to a specific CPU. You know your programs better than the operating system, in order to avoid the scheduler foolishly scheduling your programs, or to avoid the overhead of cache invalidation in multithreaded programs.

At this point, the study on "why redis is single-threaded" is over. I hope to be able to solve your 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.