We often hear that Redis It's single threaded , There will be questions ： Why single threaded Redis That fast ？
Here's something to understand ：Redis A single thread , Mainly refers to Redis Network of IO And key value pairs are read and written by one thread , This is also Redis The main process of providing external key value storage service . but Redis Other functions of , Like persistence 、 Delete asynchronously 、 Cluster data synchronization, etc , It's all done by extra threads .
We know that multithreading can improve concurrent performance , What then? Redis Will use single thread , Instead of multithreading ？ Why is single thread so fast ？
Let's learn about it Redis The reason for single threading .
Why single threaded ？
Using multithreading , Although it can increase system throughput , Or increase system scalability , But there are also costs .
Redis The data is in memory , Is Shared , If multithreading is used, there will be competition for shared resources , We need to introduce mutex to solve , Make parallel to serial . In the end, the system throughput does not increase with the number of threads .
in addition , Multithreading development requires fine design , It will increase the complexity of the system , Reduce the ease of debugging and maintainability of the code . To avoid these problems ,Redis Single threaded mode .
Single thread Redis Why so fast ？
Generally speaking , The processing power of single thread is much worse than that of multithreading , that Redis But it can use the single thread model to achieve hundreds of thousands of processing power per second , Why is that ？
One side ,Redis Most operations are done in memory , And use efficient data structure , For example, hash tables and jump tables . On the other hand ,Redis Adopted Multiplexing mechanism , Make it on the Internet IO A large number of client requests can be processed simultaneously in the operation , Achieve high throughput .
Before learning multiplexing , We need to understand that network operations are based on IO Models and potential blockpoints .
basic IO Models and choke points
With Get Request as an example , In order to deal with a Get request ：
- Need to listen for client requests （bind/listen）
- Establish a connection with the client （accept）
- from socket Read request in （recv）
- Parse client send request （parse）
- Read the key value data according to the request type （get）
- Finally, the result is returned to the client , That is to socket Write back the data in （send）.
The figure below shows the process , among ,bind/listen、accept、recv、parse and send It belongs to the Internet IO Handle , and get Attribute key value data operation .
But the network here IO In operation , There's a potential choke point , Namely accept() and recv().
- When Redis Listening to a connection request from a client , But when the connection has not been successfully established , Will be blocked. accept()
- When Redis adopt recv() When reading data from a client , If the data has not arrived ,Redis It's going to be blocked all the time recv()
This leads to Redis The whole thread is blocked , Unable to process other client requests , Efficiency is very low . however , Fortunately, ,socket The network model itself supports non blocking mode .
Socket The network model can be set in non blocking mode .
This will guarantee Redis Threads are not like basic IO The model has been waiting at the blocking point , It will not lead to Redis Unable to process actual incoming connection requests or data .
Here's the multiplexing mechanism .
Multiplexing based high performance I/O Model
Linux Of IO Multiplexing mechanism refers to the processing of multiple by one thread IO flow , That is to say select/epoll Mechanism .
stay Redis Running single thread , This mechanism allows the kernel to , There are multiple listening sockets and connected sockets at the same time .
In order to inform when the request arrives Redis Threads ,select/epoll Provides Event based callback mechanism , namely For the occurrence of different events , Call the corresponding processing function .
The workflow of callback mechanism ：
- select/epoll Once I hear that FD There is a request to arrive on , The corresponding event will be triggered , And put it in an event queue .
- Redis Single thread can process the event queue , There's no need to keep polling for requests , avoid CPU Waste of resources .
because Redis The event queue is being processed all the time , So it can respond to client requests in time , promote Redis Response performance of .
however , It should be noted that , On different operating systems , The multiplexing mechanism is also applicable .
stay “Redis basic IO Model ” In the figure , What are the potential performance bottlenecks ？
Redis Single threaded processing IO Request performance bottlenecks mainly include 2 In terms of ：
1、 Any request in server Once it happens, it takes time , Will affect the whole server Performance of In other words, the subsequent requests have to wait for the previous time-consuming request to be processed , To be dealt with by oneself .
Time consuming operations include ：
- operation bigkey： Write a bigkey It takes more time to allocate memory , Again , Delete bigkey Freeing memory can also take time
- Using overly complex commands ： for example SORT/SUNION/ZUNIONSTORE, perhaps O(N) command , however N It's big , for example lrange key 0 -1 Query the full amount of data at a time
- A lot of key Concentration expired ：Redis The expiration mechanism is also executed in the main thread , A lot of key The expiration of a set can result in the processing of a request , Time consuming to delete expired key, It takes longer
- Elimination strategy ： The stroll strategy is also executed in the main thread , When memory exceeds Redis After the memory limit , Each write needs to be eliminated key, It will be It takes longer .
- AOF The brush plate is on always Mechanism ： Every time you write, you need to brush this operation to disk , Writing to disk is much slower than writing to memory , Will slow down Redis Performance of
- Master slave total synchronous generation RDB： Although fork Child processes generate data snapshots , but fork This moment will also block the whole thread , The larger the instance , The longer the blocking time
terms of settlement ：
- Business people are needed to avoid
- Redis stay 4.0 Launched lazy-free Mechanism , hold bigkey Time consuming operations to free memory are executed in asynchronous threads , Reduce the impact on the main thread
2、 When the amount of concurrency is very large , Single thread read-write client IO Data has performance bottlenecks , Although IO Multiplexing mechanism , But read and write client data is still synchronized IO, Only a single thread can read the client data in turn , Can't make use of CPU Multicore .
terms of settlement ：
- Redis stay 6.0 Multithreading has been introduced , It can be used in high concurrency scenarios CPU Multi core multi thread read and write client data , Further improve server performance
- Of course , The client side only reads and writes , The real operation of each command is still single threaded