content
1. Why use the Reactor design pattern
The initial model of concurrent programming --- multi-threaded blocking IO model
Solve blocking IO + multi-threaded resource waste --- Reactor model
2. Reactor thread model classification
Single Reactor Single Thread Model
Single Reactor Multithreading Model
Multi-Reactor multi-threading model
foreword
- A wonderful review of the previous article, based on epoll to encapsulate a simple reactor reactor pattern, event loop
1. Why use the Reactor design pattern
The initial model of concurrent programming --- multi-threaded blocking IO model
- Disadvantage 1: Each connect corresponds to a thread, which occupies system resources. When the number of concurrency is too large, the system resources are not enough to support. (The amount of concurrency is limited on system resources)
- Disadvantage 2: Blocking IO, when waiting for IO to arrive, will block the thread, block the occupied thread, the thread utilization rate is low, and the number of threads is limited, which is a great waste of resources (occupying the thread does not work)
Solve blocking IO + multi-threaded resource waste --- Reactor model
- Based on the idea of pooling, avoid creating a thread for each connection, and hand over the business processing to the thread pool after the connection is completed. (Turn on the work_threads thread pool to handle business requirements) --- realize the decoupling of network IO and business processing while avoiding the need for each connection a connection creation thread
- Based on the IO multiplexing technology, multiple connections are blocked on the same object, and when an IO event is triggered in multiple connections, the operating system will notify the application to process --- it is still blocked, but multiple IOs are blocked on one object. , so multiplexing: multiple IOs, multiplexing: multiplexing a thread
- Understanding IO multiplexing: Compare with ordinary blocking IO: an IO event blocks a thread alone, multiplex IO multiplexing: multiple IO events block a thread together --- Multiple IO blocking waits are overlapped and blocked together. Improve thread utilization.
Reactor : Collection IO multiplexing + thread pool idea. IO driven ---> event driven (event loop)
2. Reactor thread model classification
According to the number of Reactors and the number of threads processing resources, there are three categories:
Single Reactor Single Thread Model
Complete everything in one Reactor, IO event registration, IO event distribution, IO event processing --- implemented in a single thread
defect:
- A single thread handles all requests, which is really a waste for multi-core CPUs
- When the thread load for processing read and write tasks is too high, the processing speed will decrease, events will accumulate, and in severe cases, timeout will occur, which may cause the client to resend the request, and the performance will get worse and worse.
- It cannot support high access volume, and the server access volume is low, because a large amount of business processing is included in the request to establish a connection for accept, and the business processing takes a long time, resulting in a low proportion of accept and a low number of user accesses that can be supported at the same time.
Typical representative example: redis in-memory database operation data structure in redis
Single Reactor Multithreading Model
Compared with single Reactor single thread, the core is to separate business logic from Reactor and put it into work_threads for processing, so as to realize the decoupling between network IO and business processing. Make full use of multi-core resources, improve performance, and improve user access and reliability
defect:
The Reactor thread is responsible for all events, not only processing the establishment of new connections, but also processing read, send IO events. In high concurrency scenarios, a single thread has performance problems, and in high access scenarios, it cannot respond to a large number of acceptors in time.
Representative: skynet
Multi-Reactor multi-threading model
Compared with the second model, this model splits the Reactor thread into two parts: mainReactor and subReactor. The mainReactor only handles connection events, and the read and write events are handed over to the subReactor for processing. The business logic is still handled by the thread pool .
mainRactor only handles connection events, just use a thread to handle it. The number of subReactors that process read and write events is generally equal to the number of CPUs. One subReactor corresponds to one thread, and the business logic is handled by the thread pool (a separate main thread mainReactor handles connections, which can greatly increase the amount of access) The reliability is greatly improved
This model makes each module have a single responsibility, reduces coupling, and improves performance and stability
This model is widely used in many projects, such as Netty's master-slave threading model memcached, etc.
3. Reactor thread model life
The restaurant generally has a receptionist and a waiter. The receptionist is responsible for receiving customers at the door, and the waiter is responsible for serving customers throughout the process.
Reactor's three thread models can be analogized with receptionists and waiters
Single Reactor Single Thread Model: The receptionist and the waiter are the same person, always serving customers. Suitable for less traffic
Single Reactor multithreading model: one receptionist, multiple waiters. There is a lot of traffic, and one person can't be busy. A special receptionist will receive customers at the door, and then after the table is arranged, a waiter will serve all the time. Generally, each waiter is responsible for several tables in a group.
Multi-Reactor multi-threading model: multiple receptionists, multiple waiters. This is because the traffic is too large, and a receptionist can't be busy
4. Conclusion of this chapter
- This chapter starts with the drawbacks of blocking IO for traditional concurrent servers: multi-threading and eliciting why the Reactor pattern is needed
- Multi-threaded blocking IO: the main disadvantage is: the number of threads that can be created is limited --- concurrency limit
- Blocking IO: Blocking the thread, the utilization of the thread is limited --- the utilization of the thread is not high
- Thread pool: solve the problem of limited number of threads created, reuse threads (decoupling of network IO business logic, avoid creating a thread for one connection)
- IO multiplexing technology: Solve the drawbacks of a large number of threads blocking thread utilization and low utilization.
- A single Reactor single thread handles network IO connection read and write operations + business logic. The network model is unstable, unreliable in the case of ultra-high concurrency, unable to handle customer connection requests in a timely manner, and low access volume
- Single Reactor + multithreading (thread pool) uses work_threads to process business logic, decouples network IO and business logic, and improves the stability and reliability of the server in the face of high concurrency, but for sudden excessive access There are still flaws, because Reactor handles both acceptor and IO read write. And it doesn't take full advantage of the multi-core CPU.
- Multi-Reactor + thread pool model, mainReactor only handles acceptor connections, and subReactor handles IO read and write operations. It greatly improves the access volume + greatly improves the stability and reliability of the server. The modules are low-coupling and have a single responsibility. Meet the requirements of the design pattern