Traditional blocking I/O mode
The yellow box represents the object, the blue box represents the thread, and the white box represents the API method.
Features
- Obtain input data using blocking IO mode
- Each connection requires an independent thread to complete data input, business processing and processing result data return
potential problems
- When the number of concurrency is large, a thread needs to be created for each connection request, so it takes up a lot of resources.
- After the connection is created, if the current thread has no data operation for the time being, the thread will be blocked at the operation method, resulting in a waste of thread resources.
Reactor mode (Dispatch mode)
To address the potential problems of traditional blocking I/O mode, the solutions are as follows:
- Solve the problem of creating a large number of threads based on the I/O multiplexing model: manage all connections through a blocking object
- Solve the problem of thread resource waste based on thread pool
The design idea of the Reactor pattern is I/O reuse combined with a thread pool .
Core components
- Reator: Reactor runs in a separate thread and is responsible for listening and distributing events to appropriate handlers to react to IO events.
- Handler: actually handles the IO events distributed by the execution Reactor
Advantage
- Fast response: no blocking due to a single synchronization
- Good scalability: fully utilize multi-core CPU resources by easily increasing the number of Reactor instances
- Good reusability: Reactor itself has nothing to do with specific event processing logic and has high reusability
Depending on the number of Reactors and the number of processing resource pool threads, it includes single Reactor single thread, single Reactor multi-thread and master-slave Reactor multi-thread.
Single Reactor single thread
Implementation process
- Reactor monitors client request events through Select and distributes them through Dispatch after receiving the events.
- If it is a connection request, it is processed by the Acceptor, and a Handler object is created to handle the business after the connection is completed.
- If it is not a connection request (such as read), the corresponding Handler is dispatched to respond (read->business processing->send process)
case analysis
- The mode is simple, there is no multi-thread competition, everything is completed by one thread
- Performance issue: Only one thread cannot exert multi-core CPU performance
- Reliability issues: Unexpected thread termination or an infinite loop will cause the system to become unavailable
- Suitable for scenarios where the number of clients is limited and business processing is very fast
Single Reactor multi-threading
Implementation process
- Reactor monitors client request events through Select and distributes them through Dispatch after receiving the events.
- If it is a connection request, it is processed by the Acceptor, and a Handler object is created to handle the business after the connection is completed.
- If it is not a connection request (such as read), the Reactor distribution calls the corresponding Handler to respond (read->distribution task->send process)
- The Handler is only responsible for responding to events and does not do specific business processing . The data read through read will be distributed to a thread in the work thread pool to process the business.
- The work thread pool will allocate independent threads to complete the real business and return the results to the Handler
- After Handler receives the response, it returns the result to the client through send.
case analysis
- Can fully utilize the processing power of multi-core CPU
- Multi-threaded data sharing and access are relatively complex. Reactor handles all event monitoring and response. Performance bottlenecks are prone to occur in single-threaded, high-concurrency scenarios.
Master-slave Reactor multi-threading (Netty is based on this mode)
Implementation process
- The Reactor main thread MainReactor object listens to connection events through select. If a connection request event is received, it will be processed through Acceptor.
- When the Acceptor completes processing of the connection event, the MainReactor assigns the connection to the SubReactor ( a MainReactor has multiple sub-Reactors )
- SubReactor adds the connection to the connection queue for monitoring, and creates a Handler for corresponding event processing
- When a new event occurs, subReactor will call the corresponding Handler to handle
- The Handler is only responsible for responding to events and does not do specific business processing. The data read through read will be distributed to a thread in the work thread pool to process the business.
- The work thread pool will allocate independent threads to complete the real business and return the results to the Handler
- After Handler receives the response, it returns the result to the client through send.
case analysis
- Data interaction between the main thread and sub-threads is simple and has clear responsibilities. The main thread is responsible for receiving connections, and the sub-threads complete subsequent business processing.
- The interaction between the main thread and the sub-thread is simple. The main thread hands over the connection to the sub-thread, and the sub-thread does not need to return data.
- But the programming complexity is relatively high
- Applied to Nginx master-slave Reactor multi-process model, Memcached master-slave multi-threading, Netty master-slave multi-threading