High-performance IO model: Reactor vs Proactor, how does it work?

We all know that a lot of ideas in the field of science and technology actually come from real life, such as the high-performance network communication models Reactor and Proactor that I’m going to share today. This ingenious design thinking is quite amazing.

1. Why should we study?

A tall building starts from the ground. If you want to achieve something in technology, you must practice your inner strength. With the rapid development of the Internet, the speed of technological change is beyond imagination. Maybe the skills you have mastered with great effort will become outdated in a few years (such as JSP, sturts/sturts2), but some things are timeless, such as: architectural thinking, design thinking, mastering these essences can help you quickly adapt to technological changes. Reactor and Proactor are two classic high-performance models in network IO processing. Learning them can gain different understandings in network IO processing. The two models can be highly abstracted as the following figure:

2. Reactor Model

1. Definition

Reactor, translated into Chinese as "reactor", is a passive process, which can be understood as "when receiving client events, Reactor will call the corresponding code to process according to the event type". The Reactor model is also called the Dispatcher mode. The bottom layer is I/O multiplexing combined with thread pool, which is mainly used for server-side processing of high-concurrency network IO requests. The core ideas of the Reactor model can be summarized into two "three types":

• 3 types of events: connection event, read event, write event;
• 3 roles: reactor, acceptor, handler;

2. Events

• The client sends a connection request to the server, which corresponds to a connection event on the server;
• After the connection is established, the client sends a write request to the server. After receiving the request, the server needs to read the content from the request, which corresponds to the server's read event.
• After processing, the server returns the result value to the client, which corresponds to the server's write event;

The description of the event can be found in the figure below:

3. Roles

The above describes the events of Reactor. Each event needs to have a dedicated person in charge. In the Reactor model, this person in charge is the role, which is described as follows:

• The connection event is handled by the acceptor, which is only responsible for receiving the connection. After receiving the connection, the acceptor will create a handler to handle subsequent read and write events on the network connection.
• Read and write events are processed by the handler, which responds to the client after processing;
• In high-concurrency scenarios where connection events and read and write events occur simultaneously, the reactor role is required to monitor and distribute events: connection events are handled by the acceptor; read and write requests are handled by the handler;

4. Reactor Thread Model

There are three types of Reactor thread models: single-Reactor single-thread model, single-Reactor multi-thread model, and multi-Reactor multi-thread model.

(1) Single Reactor Single Thread Model

The single-Reactor single-thread model is easy to understand: accepting requests, business processing, and responding to requests are all handled in one thread.

① Model abstraction

② Working principle

• Reactor listens to events through the select function, and distributes them to Acceptor or Handler through dispatch after receiving the events;
• If the client connection event is monitored, it is distributed to the Acceptor for processing. The Acceptor accepts the connection through accept and creates a Handler to handle various subsequent events of the connection.
• If it is not a connection establishment event, the Reactor will call the Handler corresponding to the connection (the Handler created in step 2) to respond;
• The Handler completes the entire business process through the process of read-> business processing-> send;

③ Advantages and Disadvantages

The advantages are simplicity and no thread competition. The disadvantages are that the performance of multi-core CPUs cannot be fully utilized and brought into play. When the business takes a long time, it is easy to cause blockage.

④ Case

• Redis versions below 6.0 use a single-reactor single-thread model. Because Redis uses memory and the CPU is not a performance bottleneck, the single-reactor single-thread model can support the high performance of Redis stand-alone services. In the next WeChat article, I will share how Redis uses the Reactor model and IO multiplexing mechanism.
• Netty4 can use a single Reactor single-thread model through parameter configuration;

(2) Single Reactor Multi-Thread Model

Since the single-reactor single-thread mode cannot fully utilize and give full play to the performance of multi-core CPUs, the single-reactor multi-thread model was born.

① Model abstract diagram

② Working principle

• In the main thread, the Reactor object monitors events through select, and distributes them to the Acceptor or Handler through dispatch after receiving the events;
• If the client connection event is monitored, it is distributed to the Acceptor for processing. The Acceptor accepts the connection through accept and creates a Handler to handle various subsequent events of the connection.
• If it is not a connection establishment event, the Reactor will call the Handler corresponding to the connection (the Handler created in step 2) to respond. Note that the Handler of this model is only responsible for responding to events and does not perform business processing;
• After the Handler reads the data through read, it will send it to the Processor for business processing;
• The Processor will complete the actual business processing in an independent sub-thread, and then send the response result to the Handler of the main thread for processing; after receiving the response, the Handler returns the response result to the client through send;

③ Advantages

A thread pool is used to process business logic, which can fully utilize the processing power of multiple CPUs.

④ Disadvantages

• Multi-threaded data sharing and access are relatively complex. For example, after the child thread completes the business processing, it needs to pass the result to the Reactor of the main thread for sending, which involves the mutual exclusion and protection mechanism of shared data;
• Although multi-threaded business logic is introduced, event monitoring and response still need to be handled by Reactor. Therefore, instantaneous high concurrency may cause Reactor performance bottleneck;

⑤ Case

Netty4 can use a single Reactor multi-threaded model through parameter configuration;

(3) Multi-Reactor Multi-Thread Model

The performance bottleneck of the single-reactor multi-threaded model lies in the processing power of a single reactor, so we naturally think: Can we add more reactors to improve performance? Thus, the multi-reactor multi-threaded model was born.

① Model abstract diagram

② Working principle

• The mainReactor object in the parent thread monitors the connection establishment event through select, receives the event through Acceptor, and assigns the new connection to a child thread;
• The subReactor of the child thread adds the connection assigned by the mainReactor to the connection queue and monitors it, and creates a Handler to handle various events of the connection;
• When a new event occurs, the subReactor will call the corresponding Handler (the Handler created in step 2) to respond;
• The Handler completes the entire business process through the process of read-> business processing-> send;

③ Advantages

• The responsibilities of the parent thread and the child thread are clear. The parent thread is only responsible for receiving new connections, and the child thread is responsible for completing subsequent business processing;
• The interaction between the parent thread and the child thread is simple. The parent thread only needs to pass the new connection to the child thread, and the child thread does not need to return data.

④ Case

• Nginx uses a multi-reactor multi-process model, but the solution is different from the standard multi-reactor multi-process model;
• The open source software Memcache uses a multi-reactor multi-threaded model;
• Netty4 can use multi-reactor multi-threaded model through parameter configuration;

At this point, the analysis of the Reactor model is complete. It should be noted that the three thread models of Reactor described above can also be deployed in the form of processes, which may be somewhat different from threads in terms of logical processing. Next, we will analyze the Proactor model, which is very similar to the Reactor model.

3. Proactor Model

1. Definition

Proactor, translated into Chinese as "proactor", at first glance, this translation is still quite confusing. I personally think that "proactor" is more in line with the original meaning of the Proactor model. Proactor can be understood as "when there are IO events such as connection, reading and writing, the operating system kernel actively notifies our program code after processing the event."

2. Model abstract diagram

3. Working Principle

• Proactor Initiator is responsible for creating Proactor and Handler, and registering both Proactor and Handler to the kernel through Asynchronous Operation Processor;
• The Asynchronous Operation Processor is responsible for processing registration requests and completing I/O operations;
• The Asynchronous Operation Processor notifies the Proactor after completing the I/O operation;
• Proactor calls back different Handlers for business processing according to different event types;
• The Handler completes the business processing, and the Handler can also register a new Handler to the kernel process;

4. Advantages and Disadvantages

• Proactor has higher performance than Reactor when processing time-consuming IO, but the improvement in execution efficiency for low-cost IO is not obvious;
• The asynchronicity of Proactor makes its concurrent processing capability stronger than Reactor;
• The implementation logic of Proactor is complex and the coding cost is much higher than that of Reactor;
• Proactor's asynchrony is highly dependent on the operating system's support for asynchrony. If the operating system does not support asynchrony well, Proactor's performance will be worse than Reactor's.

5. Case

Netty5 uses AIO, and its network communication model is Proactor. However, this version is no longer maintained. The main reason is that Linux's current support for asynchrony is not perfect, which has caused Netty5 to spend a lot of money. The performance is not only not improved compared to Netty4, but may even be reduced.

IV. Conclusion

(1) Reactor is a synchronous non-blocking network model, and Proactor is an asynchronous non-blocking network model;

(2) Reactor is a perfect combination of I/O multiplexing and thread pool;

(3) The Reactor model may seem profound, but it actually reflects many real-life examples, such as:

• In the night market, one boss and one cart are responsible for making noodles by themselves. The boss is responsible for everything from ordering, serving, and settling accounts. This corresponds to the single-reactor single-thread model.
• The hospital's doctor-calling system corresponds to a single-reactor multi-threaded model, where one doctor-calling machine is responsible for calling the number and multiple doctors are responsible for receiving the patient.
• Large-scale catering services correspond to the multi-reactor multi-threaded model, with a receptionist responsible for picking up and dropping off guests, multiple waiters, each of whom is responsible for several tables of guests, and dedicated waiters responsible for serving dishes to guests, such as Haidilao;

(4) Reactor thinking is also often used in daily development. The most common method is single-threaded processing. When the concurrency is large, thread pools are introduced to subdivide the business and use dedicated threads to handle specific tasks. This is similar to the evolution of the Reactor model.

(5) Proactor mainly uses an asynchronous method to handle IO events (for example, when ordering takeout, you don’t need to pay attention to it after placing the order and paying, and you can just handle your own business. When the takeout is ready, the takeout guy will take the initiative to deliver the takeout to you). However, Linux currently does not support AIO very well, and Netty5, which uses this model, eventually died for this reason.