Redis 6.0 stable version
Redis 6.0.0 stable version provides many new features and functional improvements, such as the new network protocol RESP3, new Cluster agent, ACL, etc. I think what everyone is most concerned about may still be "multi-threading". Let's take a look at the new features of redis 6.0 version.
(Learning video sharing:redis video tutorial)
1. Are versions before Redis6.0 really single-threaded?
When Redis handles client requests, including acquisition (socket reading), parsing, execution, content return (socket writing), etc., they are all processed by a sequential and serial main thread. This is what is called "Single threaded". But strictly speaking, it is not single-threaded since Redis 4.0. In addition to the main thread, it also has background threads that handle some slower operations, such as cleaning dirty data, releasing useless connections, deleting large keys, etc.
2. Why didn’t multi-threading be used before Redis6.0?
The official has responded to a similar question: When using Redis, there is almost no situation where the CPU becomes a bottleneck. Redis is mainly limited by memory and network. For example, on a normal Linux system, Redis can handle 1 million requests per second by using pipelining, so if the application mainly uses O(N) or O(log(N)) commands, it will hardly take up much CPU.
After using a single thread, maintainability is high. Although the multi-threading model performs well in some aspects, it introduces uncertainty in the order of program execution, brings about a series of problems with concurrent reading and writing, increases system complexity, and may involve thread switching or even locking. Performance loss caused by unlocking and deadlock. Redis has very high processing performance through AE event model and IO multiplexing and other technologies, so there is no need to use multi-threading. The single-thread mechanism greatly reduces the complexity of Redis's internal implementation. Hash's inertia, Rehash, Lpush and other "thread-unsafe" commands can be executed without locks.
3.Why does Redis6.0 introduce multi-threading?
Redis places all data in memory. The response time of the memory is about 100 nanoseconds. For small data packets, the Redis server can handle 80,000 to 100,000 QPS, which is also the limit of Redis processing. For 80% of companies, single-threaded Redis is sufficient.
But with increasingly complex business scenarios, some companies can easily reach hundreds of millions in transaction volume, so they need larger QPS. A common solution is to partition the data in a distributed architecture and use multiple servers, but this solution has very big shortcomings, such as too many Redis servers to manage and high maintenance costs; some solutions are suitable for a single Redis server. Commands do not work with data partitions; data partitions cannot solve hotspot read/write issues; data skew, reallocation and scaling up/down become more complex, etc.
From the perspective of Redis itself, because the read/write system calls for reading and writing the network occupy most of the CPU time during Redis execution, the bottleneck mainly lies in the IO consumption of the network. There are two main directions for optimization:
• Improve network IO performance. Typical implementations include using DPDK to replace the kernel network stack.
• Use multi-threading to fully utilize multi-cores. Typical implementations include Memcached.
This method of protocol stack optimization has little to do with Redis. Supporting multi-threading is the most effective and convenient operation method. So in summary, redis supports multi-threading for two main reasons:
• It can make full use of server CPU resources. Currently, the main thread can only use one core
• Multi-threaded tasks can be shared by Redis to synchronize IO reading and writing Load
4.Does Redis6.0 enable multi-threading by default?
Multi-threading in Redis6.0 is disabled by default, and only the main thread is used. If you want to enable it, you need to modify the redis.conf configuration file: io-threads-do-reads yes
5. When Redis6.0 multi-threading is enabled, how to set the number of threads?
After turning on multi-threading, you need to set the number of threads, otherwise it will not take effect. Also modify the redis.conf configuration file
Regarding 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, and 8-core machines are recommended to be set to 6 threads. The number of threads must be smaller than the number of machine cores. It should also be noted that the larger the number of threads, the better. Officials believe that more than 8 threads are basically meaningless.
6. After Redis6.0 adopts multi-threading, what is the performance improvement effect?
Redis author antirez mentioned when sharing at RedisConf 2019: The multi-threaded IO feature introduced in Redis 6 can at least double the performance improvement. Domestic experts have also used the unstable version to conduct tests on Alibaba Cloud esc. The performance of the GET/SET command in 4-thread IO is almost doubled compared to that of a single thread.
test environment:
Redis Server: Alibaba Cloud Ubuntu 18.04, 8 CPU 2.5 GHZ, 8G memory, host model ecs.ic5.2xlarge
Redis Benchmark Client: Alibaba Cloud Ubuntu 18.04, 8 2.5 GHZ CPU, 8G memory, host Model ecs.ic5.2xlarge
Test result:
For details, please see: https://zhuanlan.zhihu.com/p /76788470
Note 1: These performance verification tests do not perform stress testing on strict delay control and different concurrency scenarios. The data is for verification reference only and cannot be used as an online indicator.
Note 2: If you enable multi-threading, it is recommended to use at least a 4-core machine and the Redis instance has occupied a considerable amount of CPU time. Otherwise, there is no point in using multi-threading. So it is estimated that 80% of company developers will just take a look.
7.Redis6.0 multi-threading implementation mechanism?
The process is briefly described as follows:
1. The main thread is responsible for receiving the connection establishment request, obtaining the socket and putting it into the global Waiting for the read processing queue
2. After the main thread processes the read event, it allocates these connections to these IO threads through RR (Round Robin)
3. The main thread blocks and waits for the IO thread to finish reading the socket
4 . The main thread executes the request command in a single-threaded manner, and the requested data is read and parsed, but not executed.
5. The main thread blocks and waits for the IO thread to write the data back to the socket.
6. Unbind, Clear the waiting queue
(Picture source: https://ruby-china.org/topics/38957)
The design has the following characteristics:
1. IO thread or Reading the socket at the same time, or writing at the same time, not reading or writing at the same time
2. The IO thread is only responsible for reading and writing socket parsing commands, and is not responsible for command processing
8. After turning on multi-threading, Are there thread concurrency safety issues?
As can be seen from the above implementation mechanism, the multi-threaded part of Redis is only used to process the reading and writing of network data and protocol analysis, and the execution of commands is still executed sequentially in a single thread. So we don't need to consider the concurrency and thread safety issues of controlling keys, lua, transactions, LPUSH/LPOP, etc.
9. How to install Redis6.0.1 (the official version of 6.0 is 6.0.1) on Linux environment?
This is no different from installing other versions of redis. There are no pitfalls in the whole process, so I won’t describe it here. The only thing to note is that the number of configured multi-threads must be smaller than the number of cores of the CPU. Check the number of cores with the command:
[root@centos7.5 ~]# lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 4 On-line CPU(s) list: 0-3
10. Compare the multi-threading model of Redis6.0 and the multi-threading model of Memcached
In the past few years, memcached was a commonly used caching solution for major Internet companies. Therefore, the difference between redis and memcached has basically become a must-ask interview question for interviewers regarding caching. In recent years, memcached has been used less and basically It's all redis. However, with the addition of multi-threading features in Redis 6.0, similar problems may still occur. Next, we will only make a brief comparison of the multi-threading models.
As shown in the figure above: Memcached server works in master-woker mode, and the server uses socket to communicate with the client. The main thread and worker thread use pipe pipes to communicate. The main thread uses libevent to monitor the read events of listen and accept. After the event responds, it encapsulates the data structure of the connection information, selects the appropriate working thread according to the algorithm, and distributes the connection task carrying the connection information. The corresponding thread uses the connection descriptor to establish and The client's socket connects and performs subsequent data access operations.
Comparison between Redis6.0 and Memcached multi-threading models:
Similar points: both adopt the master thread-worker thread model
Different points: Memcached executes the main logic in the worker thread, and the model is more It is simple, achieves true thread isolation, and conforms to our conventional understanding of thread isolation. Redis returns the processing logic to the master thread. Although it increases the complexity of the model to a certain extent, it also solves issues such as thread concurrency security.
11. How does the Redis author comment on the new feature of "multi-threading"?
Regarding the feature of multi-threading, Antirez once explained in 6.0 RC1:
There are two feasible ways for Redis to support multi-threading: the first is like "memcached "That way, a Redis instance opens multiple threads, thereby increasing the number of operations that can be performed per second in simple commands such as GET/SET. This involves multi-threaded processing such as I/O and command parsing, so we call it "I/O threading". The other is to allow slower 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 use "I/O threading". Redis is mainly subject to the network and memory during runtime, so improving redis performance is mainly through multiple redis instances, especially redis clusters. Next, we will mainly consider improving two aspects:
1. Multiple instances of the Redis cluster can reasonably use the disk of the local instance through orchestration to avoid rewriting AOF at the same time.
2. Provide a Redis cluster proxy to facilitate users to abstract a cluster when there is no better cluster protocol client.
As a supplement, Redis is a memory system like memcached, but it is different from Memcached. Multithreading is complex, and a simple data model must be considered. The thread executing LPUSH needs to service other threads executing LPOP.
What I really expect is actually "slow operations threading". In redis6 or redis7, "key-level locking" will be provided so that threads can fully gain control of the key to handle slow operations.
See: http://antirez.com/news/126
12. IO multiplexing is often mentioned in Redis threads. How to understand it?
This is a type of IO model, the classic Reactor design pattern, sometimes also called asynchronous blocking IO.
Multi-channel refers to multiple socket connections, and reuse refers to reusing one thread. There are three main multiplexing technologies: select, poll, and epoll. epoll is the latest and best multiplexing technology available. The use of multi-channel I/O multiplexing technology allows a single thread to efficiently handle multiple connection requests (minimizing the time consumption of network IO), and Redis operates data in memory very quickly (in-memory operations will not become a problem here). Performance bottleneck), the above two points mainly contribute to the high throughput of Redis.
13. Do you know Redis’ easter egg LOLWUT?
This has actually been around since Redis 5.0, but forgive me for just knowing it. The author describes this function as "LOLWUT: a piece of art inside a database command", "a piece of art inside a database command". You can call it sentiment, or you can call it an easter egg. I won’t reveal what it is specifically. Friends who don’t know what it is like me can refer to: http://antirez.com/news/123. It will be randomly generated every time it is run.
Related recommendations:redis database tutorial
The above is the detailed content of Introduction to new features of redis version 6.0. For more information, please follow other related articles on the PHP Chinese website!