Wenxin Yiyan's summary of the new features of Redis6.0
Table of contents
1: From single-threaded processing of network requests to multi-threaded processing
1.1 The processing speed of a single main thread processing network requests is slow
1.2 In Redis 6.0, how does the main thread and IO thread cooperate to complete request processing?
1.3 How to enable multithreading
2. Realize server-side assisted client-side caching
Question: How does data modification invalidate the client cache
Solution: normal mode, broadcast mode
3. From simple password-based access to fine-grained permission control
3.1 Fine-grained access control
New features of Redis6.0
Multi-IO threads for network processing can improve the speed of network request processing, and client-side caching allows applications to directly read data locally on the client. These two features can improve the performance of Redis. In addition, fine-grained permission control allows Redis to control the access permissions of different users according to the granularity of commands, which strengthens the security protection of Redis. The RESP 3 protocol enhances the functions of the client, making it easier for applications to use different data types of Redis
1: From single-threaded processing of network requests to multi-threaded processing
In Redis 6.0, the first new feature that received a lot of attention was multithreading . This is because Redis has always been known for its single-threaded architecture. Although some command operations can be executed with background threads or sub-processes (such as data deletion, snapshot generation, and AOF rewriting), from network IO processing to actual The read and write command processing is done by a single thread.
As the performance of network hardware improves, the performance bottleneck of Redis sometimes occurs in the processing of network IO, that is, the speed of a single main thread processing network requests cannot keep up with the speed of the underlying network hardware.
1.1 The processing speed of a single main thread processing network requests is slow
the first method
Use the user mode network protocol stack (such as DPDK) to replace the kernel network protocol stack, so that the processing of network requests does not need to be executed in the kernel, but can be processed directly in the user mode.
For high-performance Redis, avoiding frequent network request processing by the kernel can greatly improve request processing efficiency. However, this method requires adding support for the user-mode network protocol stack in the overall architecture of Redis, and it is necessary to modify the network-related parts of the Redis source code (such as modifying all network sending and receiving request functions), which will bring a lot of development work quantity. Moreover, the new code may also introduce new bugs, resulting in system instability. Therefore, this method is not used in Redis 6.0.
The second method
Multiple IO threads are used to process network requests to improve the parallelism of network request processing. Redis 6.0 takes this approach.
However, Redis's multi-IO threads are only used to process network requests. For read and write commands, Redis still uses a single thread to process them. This is because network processing is often the bottleneck when Redis processes requests, and multiple IO threads process network operations in parallel, which can improve the overall processing performance of the instance. If you continue to use a single thread to execute command operations, you don't need to develop an additional multi-thread mutual exclusion mechanism to ensure the atomicity of Lua scripts and transactions. In this way, the implementation of the Redis threading model is simple.
1.2 In Redis 6.0, how does the main thread and IO thread cooperate to complete request processing?
Phase 1: The server and client establish a Socket connection and allocate processing threads
First, the main thread is responsible for receiving connection establishment requests. When a client requests to establish a Socket connection with the instance, the main thread will create a connection with the client and put the Socket into the global waiting queue. Then, the main thread assigns the Socket connection to the IO thread through the polling method.
Phase 2: The IO thread reads and parses the request
Once the main thread assigns the Socket to the IO thread, it will enter the blocking state, waiting for the IO thread to complete the reading and parsing of the client request. Because there are multiple IO threads processing in parallel, this process can be completed quickly.
Phase 3: The main thread executes the requested operation
When the IO thread finishes parsing the request, the main thread will still execute these command operations in a single-threaded manner. The following picture shows the three stages just introduced, you can look at it to deepen your understanding.
Phase 4: IO thread writes back to Socket and main thread
Empty the global queue. After the main thread executes the request operation, it will write the results that need to be returned into the buffer. Then, the main thread will block and wait for the IO thread to write these results back to the Socket and return them to the client.
z is the same as the IO thread reading and parsing requests. When the IO thread writes back to the Socket, multiple threads are executing concurrently, so the speed of writing back to the Socket is also very fast. After the IO thread finishes writing back to the Socket, the main thread will clear the global queue and wait for subsequent requests from the client.
1.3 How to enable multithreading
In Redis 6.0, the multithreading mechanism is disabled by default. If you need to use the multithreading function, you need to complete two settings in redis.conf.
1. Set the io-thread-do-reads configuration item to yes to enable multi-threading.
io-threads-do-reads yes2. Set the number of threads.
Generally speaking, the number of threads is smaller than the number of CPU cores of the machine where the Redis instance is located. For example, for an 8-core machine, Redis officially recommends configuring 6 IO threads.
io-threads 6In practical applications, it is found that the CPU overhead of the Redis instance is not large, but the throughput has not been improved. You can consider using the multi-threading mechanism of Redis 6.0 to speed up network processing, thereby improving the throughput of the instance.
2. Realize server-side assisted client-side caching
Redis 6.0 has added an important new feature: the client-side caching function assisted by the server is implemented, also known as the Tracking function .
Function of the tracking function: the Redis client in the business application caches the read data locally in the business application, and the application directly reads the data locally quickly.
Question: How does data modification invalidate the client cache
When the data is cached locally on the client, if the data is modified or invalidated, how to notify the client to invalidate the cached data?
Solution: normal mode, broadcast mode
The Tracking function implemented in 6.0 implements two modes to solve this problem.
The first mode is normal mode.
In this mode, the instance will record the key read by the client on the server side and monitor whether the key has been modified. Once the value of the key changes, the server will send an invalidate message to the client to notify the client that the cache is invalid.
When using the normal mode, the server will only report an invalidate message for the recorded key . That is to say, after the server sends an invalidate message to the client, if the key is modified again, the server will not Send the invalidate message to the client again. Only when the client executes the read command again, the server will monitor the read key again and send an invalidate message when the key is modified.
The reason why the server only reports an invalidate message for the recorded key
The consideration of this design is to save limited memory space. After all, if the client no longer accesses the key, but the server still records the modification of the key, memory resources will be wasted.
CLIENT TRACKING ON|OFFThe second mode is broadcast mode.
In this mode, the server will broadcast the invalidation of all keys to the client. Disadvantage: If the key is frequently modified, the server will send a large number of invalidation broadcast messages, which will consume a lot of network bandwidth resources.
In actual application, the client will register the prefix of the key that it wants to track. When the key with the registered prefix is modified, the server will broadcast the invalidation message to all registered clients. Different from normal mode, in broadcast mode, even if the client has not read the key, as long as it registers the key to be tracked, the server will notify the client of the key invalidation message.
How the client uses the broadcast mode to receive the key expiration message:
After the client executes the following command, if the server updates the key user:id:1003, then the client will receive an invalidate message.
CLIENT TRACKING ON BCAST PREFIX(前缀) userThis broadcast mode of monitoring keys with a prefix matches our naming convention for keys very well. In actual application, the same business name prefix will be set for keys under the same business.
Common mode and broadcast mode require the client to use the RESP 3 protocol, which is a newly enabled communication protocol in 6.0.
For clients using the RESP 2 protocol, another mode needs to be used: redirection mode (redirect). In the redirection mode, the client that is notified of the invalidation message executes the subscription command SUBSCRIBE to specifically subscribe to the channel _redis_:invalidate for sending the invalidation message. At the same time, use another client and execute the CLIENT TRACKING command to set the server to forward the invalidation message to the client using the RESP 2 protocol.
How to enable clients using the RESP 2 protocol to also accept invalidation messages
Suppose client B wants to get invalidation messages, but client B only supports RESP 2 protocol, and client A supports RESP 3 protocol. Execute SUBSCRIBE and CLIENT TRACKING on clients B and A respectively, as follows:
//客户端B执行，客户端B的ID号是303
SUBSCRIBE _redis_:invalidate
//客户端A执行
CLIENT TRACKING ON BCAST REDIRECT 303After setting, if a key-value pair is modified, client B can get the invalidation message through the _redis_:invalidate channel.
3. From simple password-based access to fine-grained permission control
Prior to Redis 6.0, secure access to an instance could only be controlled by setting a password. For example, a client was required to enter a password before connecting to an instance. For some high-risk commands (such as KEYS, FLUSHDB, FLUSHALL, etc.), before Redis 6.0, these commands can only be renamed through rename-command to avoid direct calls by clients
3.1 Fine-grained access control
First, version 6.0 supports creating different users to use Redis.
Before version 6.0, all clients can use the same password to log in, but there is no concept of user, but in version 6.0, users can be created with the ACL SETUSER command.
ACL SETUSER normaluser on > abcIn addition, version 6.0 also supports setting access permissions for command operations at the granularity of users
Suppose you want to set the user normaluser to only call Hash-type command operations, but not String-type command operations, execute the following command
ACL SETUSER normaluser +@hash -@stringIn addition to setting the access control authority of a certain command or a certain type of command, version 6.0 also supports setting the access authority at the granularity of the key. The specific method is to use the tilde "~" and the prefix of the key to indicate the access control key. For example, you can set the user normaluser to only perform command operations on keys prefixed with "user:":
ACL SETUSER normaluser ~user:* +@allRedis 6.0 can set different users to access the instance, and based on the granularity of users and keys, set the command operations that a user allows or prohibits for certain keys
4: Enable RESP 3 protocol
Redis 6.0 implements the RESP 3 communication protocol, while RESP 2 was used before. In RESP 2, the communication content between the client and the server is encoded in the form of byte arrays, and the client needs to decode the transmitted data by itself according to the operation command or data type, which increases the complexity of client development.
However, RESP 3 directly supports differentiated encoding of various data types , including null values, floating-point numbers, Boolean values, ordered dictionary collections, and unordered collections. The so-called distinguishing encoding refers to distinguishing different data types directly through different initial characters. In this way, the client can directly judge the initial character of the message to realize the data conversion operation and improve the efficiency of the client.
In addition, the RESP 3 protocol can also support the client to implement client-side caching in normal mode and broadcast mode.
5. Summary of Redis6.0
Because Redis 6.0 has just been launched, new features still need to be deployed and verified in actual applications, so if you want to try Redis 6.0, you can try to use Redis 6.0 on non-core business first, on the one hand, you can verify the new features On the other hand, it can also avoid the core business being affected due to the instability of new features.
Which new feature or features of Redis 6.0 will help you?
From the perspective of improving performance, the multi-IO thread feature in Redis 6.0 can relieve the pressure of Redis's network request processing. By increasing the ability to process network requests through multi-threading, the overall performance of the instance can be further improved. Some people in the industry have already evaluated that compared with single-threaded Redis before 6.0, the multi-thread performance of 6.0 has indeed improved. Therefore, this feature will be of great help to business applications.
In addition, the user-based command-grained ACL control mechanism is also very useful. When Redis provides external services in a cloud-based manner, it will face multi-tenant (such as multi-user or multiple microservices) application scenarios. With the new ACL feature, we can safely support multi-tenant shared access to Redis services.
Spend time on yourself, many people are just passers-by and don't care