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

Editor to share with you what are the new features of Redis6.0, I believe most people do not know much about it, so share this article for your reference, I hope you can learn a lot after reading this article, let's go to know it!

Redis 6.0is coming.

Redis 6.0.0 stable version (GA) is finally released, this version provides many exciting new features and functional improvements, such as the new network protocol RESP3, new cluster agent, ACL, etc., of which the most attention should be "multithreading". With many questions, let's start with "Redis 6.0new features".

1. Was the previous version of Redis6.0 really single-threaded?

When Redis processes client requests, including acquisition (socket read), parsing, execution, content return (socket write), and so on, it is handled by a sequential main thread, which is called "single thread". But if it is not strictly single-threaded after Redis4.0, in addition to the main thread, it also has background threads dealing with some slow operations, such as cleaning up dirty data, releasing useless connections, deleting large key, and so on.

2. Why didn't I use multithreading before Redis6.0?

Officials have answered similar questions: when using Redis, there is almost no case where CPU becomes a bottleneck, and Redis is mainly limited by memory and network. For example, on an ordinary Linux system, Redis can process 1 million requests per second by using pipelining, so if the application mainly uses O (N) or O (log (N)) commands, it will hardly consume too much CPU.

After using single thread, the maintainability is high. Although the multithreading model performs well in some aspects, it introduces the uncertainty of program execution order and brings a series of problems of concurrent reading and writing. it increases the complexity of the system, and may cause performance loss caused by thread switching, even locking and unlocking, and deadlock. Redis has very high processing performance through technologies such as AE event model and IO multiplexing, so there is no need to use multithreading. The single-thread mechanism greatly reduces the complexity of the internal implementation of Redis, and Hash's lazy Rehash, Lpush and other "thread-unsafe" commands can be carried out without locks.

Why does 3.Redis6.0 introduce multithreading?

Redis keeps all the data in memory, and the response time of memory is about 100 nanoseconds. For small packets, the Redis server can handle 80000 to 100000 QPS, which is the limit of Redis processing. For 80% of companies, single-threaded Redis is enough.

But with more and more complex business scenarios, some companies are prone to hundreds of millions of transactions, so they need a larger QPS. The common solution is to partition the data and use multiple servers in the distributed architecture, but this scheme has great shortcomings, such as too many Redis servers to be managed and high maintenance costs; some commands suitable for a single Redis server are not suitable for data partitioning; data partitioning can not solve hot read / write problems; data skew, redistribution and magnification / reduction become more complex, and so on.

From the point of view of Redis itself, because the read/write system call of the read-write network takes up most of the CPU time during Redis execution, the bottleneck mainly lies in the IO consumption of the network, and there are two main directions of optimization:

Improve network IO performance, typical implementations such as using DPDK instead of kernel network stack

Use multithreading to take full advantage of multicore, typical implementations such as Memcached.

This way of protocol stack optimization has little to do with Redis, and supporting multithreading is the most effective and convenient mode of operation. So to sum up, there are two main reasons why redis supports multithreading:

The server CPU resources can be fully utilized. At present, the main thread can only use one core.

Multithreaded tasks can share the read and write load of Redis synchronous IO

Is multithreading enabled by default in 4.Redis6.0?

Multithreading for Redis6.0 is disabled by default, using only the main thread. To open it, you need to modify the redis.conf configuration file: io-threads-do-reads yes

How to set the number of threads when 5.Redis6.0 multithreading is enabled?

After multithreading is enabled, you also need to set the number of threads, otherwise it will not take effect. Also modify the redis.conf configuration file

With regard to the setting of the number of threads, there is an official suggestion: 4-core machines are recommended to be set to 2 or 3 threads, 8-core machines are recommended to be set to 6 threads, and the number of threads must be less than the number of machine cores. It is also important to note that the larger the number of threads, the better. Officials believe that more than 8 is basically meaningless.

What is the effect of performance improvement when multithreading is adopted in 6.Redis6.0?

Redis author antirez mentioned in RedisConf 2019 sharing that the multithreaded IO feature introduced by Redis 6 has at least more than doubled the performance improvement. In China, Daniel has used the unstable version to test in Aliyun esc, and the performance of the GET/SET command in 4-thread IO is almost double that of single-thread.

Test environment:

Redis Server: Aliyun Ubuntu 18.04 GHZ 8 CPU 2.5 GHZ, 8 GB memory, mainframe model ecs.ic5.2xlarge

Redis Benchmark Client: Aliyun Ubuntu 18.04 Magi 82.5 GHZ CPU, 8G memory, mainframe model ecs.ic5.2xlarge

Test results:

For details, see: https://zhuanlan.zhihu.com/p/76788470

Note 1: these performance verification tests are not stress tested for strict delay control and different concurrency scenarios. The data can only be used as a reference for verification, not as an online indicator.

Note 2: if multithreading is enabled, it is recommended to use at least a 4-core machine, and the Redis instance has taken up a considerable amount of CPU time-consuming time, otherwise it is meaningless to use multithreading. So it's estimated that 80% of the company's developers just take a look.

The implementation mechanism of 7.Redis6.0 multithreading?

The process is summarized as follows:

1. The main thread is responsible for receiving the request for establishing a connection, getting the socket and putting it into the global queue for read processing.

2. After the main thread has finished handling the read events, assign these connections to these IO threads through RR (Round Robin)

3. The main thread blocks and waits for the IO thread to finish reading socket

4. The main thread executes the request command through a single thread, requesting data reading and parsing, but does not execute.

5. The main thread blocks and waits for the IO thread to write the data back to socket.

6. Unbind and empty the waiting queue

(photo source: https://ruby-china.org/topics/38957)

The design has the following characteristics:

1. The IO thread is either reading socket or writing at the same time, and will not read or write at the same time

2. The IO thread is only responsible for reading and writing socket parsing commands, not for command processing.

8. Is there a thread concurrency safety problem when multithreading is turned on?

From the above implementation mechanism, we can see that the multithreaded part of Redis is only used to deal with the reading and writing of network data and protocol parsing, and the execution of commands is still executed sequentially by a single thread. So we don't need to think about controlling the concurrency and thread safety of key, lua, transactions, LPUSH/LPOP, and so on.

How do I install Redis6.0.1 on a 9.Linux environment (the official version of 6.0 is 6.0.1)?

This is no different from installing other versions of redis, and there are no holes in the whole process, so I won't describe it here. The only thing to note is that the number of configured multithreads must be less than the number of cores of cpu. Check the number of cores command:

[root@centos7.5 ~] # lscpuArchitecture: x86_64CPU op-mode (s): 32-bit, 64-bitByte Order: Little EndianCPU (s): 4On-line CPU (s) list: 0-3

Compare the multithreading model of 10.Redis6.0 with that of Memcached.

A few years ago, memcached is a commonly used caching scheme for major Internet companies, so the difference between redis and memcached has basically become a necessary question for interviewers in caching. In recent years, memcached has been used less, mostly redis. However, with the addition of multithreading in Redis6.0, similar problems may arise, so let's just briefly compare the multithreading model.

As shown in the figure above: the Memcached server uses master-woker mode to work, and the server uses socket to communicate with the client. The main thread and worker thread use pipe pipeline to communicate. The main thread uses libevent to listen to the read events of listen and accept, encapsulates the data structure of the connection information after the event response, selects the appropriate working thread according to the algorithm, and distributes the connection information with the connection task. The corresponding thread uses the connection descriptor to establish the socket connection with the client and carries on the subsequent access data operation.

Comparison of Redis6.0 and Memcached multithreading models:

The same point: all adopt the master thread-worker thread model

The difference: Memcached executes the main logic in worker threads, so the model is simpler and achieves real thread isolation, which is in line with our general understanding of thread isolation. On the other hand, Redis returns the processing logic to the master thread, which increases the complexity of the model to some extent, but also solves the problems such as thread concurrency safety.

How did the author of 11.Redis comment on the new feature of "multithreading"?

With regard to the feature of multithreading, Antirez explained it in 6. 0 RC1:

There are two possible ways for Redis to support multithreading: the first is to open multiple threads in a Redis instance, like "memcached", to improve the operations that can be performed per second in simple commands such as GET/SET. This involves multi-threaded processing such as iThread O, command parsing, and so on, so we call it "I _ threading". The other is to allow slower, time-consuming commands to be executed in different threads to ensure that other clients are not blocked. We call this threading model "Slow commands threading".

After careful consideration, Redis will not adopt "I redis O threading". Redis is mainly limited by network and memory at run time, so redis performance is improved mainly through multiple redis instances, especially redis clusters. Next, we will mainly consider two aspects of improvement:

Multiple instances of the 1.Redis cluster can reasonably use the disks of the local instance by orchestrating to avoid rewriting the AOF at the same time.

two。 A Redis cluster agent is provided to make it easy for users to abstract a cluster when there is no good cluster protocol client.

In addition, Redis is a memory system like memcached, but different from Memcached. Multithreading is complex, and you must consider using a simple data model, and threads executing LPUSH need to serve other threads executing LPOP.

What I really expect is "slow operations threading", which in redis6 or redis7 will provide "key-level locking" so that threads can gain full control of keys to handle slow operations.

For details, see: http://antirez.com/news/126

IO multiplexing is often mentioned in 12.Redis threads, how to understand it?

This is one of the IO models, the classic Reactor design pattern, sometimes referred to as asynchronous blocking IO.

Multiplexing refers to multiple socket connections, and multiplexing refers to reusing a thread. There are three main techniques for multiplexing: select,poll,epoll. Epoll is the latest and best multiplexing technology at present. Using multi-channel IO multiplexing technology allows a single thread to process multiple connection requests efficiently (minimizing the time consumption of network Redis), and Redis operates data very fast in memory (the operation in memory will not become the performance bottleneck here). The above two points make Redis have high throughput.

13. Do you know Redis's egg LOLWUT?

This has been available since Redis5.0, but forgive me for knowing it just now. This is how the author describes this function as "LOLWUT: a piece of art inside a database command", "a work of art in database commands". You can call it affection, or you can call it a colored egg. I won't reveal what it is. Friends who don't know what it is as much as I do can see: http://antirez.com/news/123, which is randomly generated every time it runs.

These are all the contents of the article "what are the new features in Redis6.0?" 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.