Shulou(Shulou.com)06/02 Report--

This article is to share with you about the difference between the Reactor model and the Proactor model, the editor thinks it is very practical, so I share it with you to learn. I hope you can get something after reading this article.

Reactor model

It is a synchronous non-blocking model. Also known as Dispatcher model. Think that if every connection we have to build a thread to handle the connection, then the connection must not be full of multiple threads, then someone may say that the thread pool must be on the thread pool. But this can only solve the problem of the number of threads, but another problem is the problem of resource utilization. When the connection is not disconnected, when the connection is not requested temporarily, does your thread have to block and wait for the request? the thread is still occupied, and other connections do not need this thread when they have requests, which is a waste of resources and low performance.

So how to solve this problem?

Of course, the thread will go up and process it when there is a request from the connection. Then we have to find a "person" to do this, and our business thread will handle the business, that is, there must be a "person" to manage all the connections. He will assign the business thread to handle the connection which he finds has a request.

This is called the Reactor model. The "person" mentioned above is called reactor, which means "reactor" in Chinese translation, that is, he is the one who monitors. If something happens, he will react and distribute the task to the business thread for processing.

Can have single Reactor single thread, single Reactor multithread, multi Reactor multithread

Single Reactor single thread

Select will listen for the event all the time, and distribute it to dispatch after the event arrives. If the requested event is established, the acceptor will be assigned. Acceptor will create a handler to handle the subsequent business. If it is not the requested event, assign a previous corresponding handler to handle the subsequent business.

The advantage of this situation is that it is simple. There are no problems caused by multithreaded shared resources. The disadvantage is that it is single-threaded, wasting more CPU, and only one handler can handle it at a time, and the rest have to wait.

It sounds like it doesn't work. Well, most of the scenarios don't fit, but that's how redis works. Because it handles business fast enough. So this is suitable for use in situations where business processing is extremely fast.

Single Reactor multithreading

When the business processing is not fast, it will be multithreaded.

The difference between this pattern and the above is that the specific business implementation is not handled by handler. Handler is only responsible for read data and sends the data to the business thread. After the business thread has finished processing, the result is returned to handler, and the handler send gives it to the client.

The advantage of this model is that it can make full use of CPU and is suitable for unpleasant business processing. The disadvantage is that there is a problem caused by the scramble for shared resources between multiple threads, and only one Reactor listens and responds. When the number of requests is too large, a Reactor may become a performance bottleneck.

Multi-Reactor multi-thread

So multi-Reactor multithreading is coming.

MainReactor is mainly used to accept connections. The connection assigns a subReactor to the new connection to the acceptor,acceptor, and then the subReactor adds it to its own listener list and creates a handler to handle the connection. After that, the subReactor listens to select to respond to the request for the connection, and then the dispatch gives the corresponding handler read, business processing, and send. MainReactor doesn't care.

So this scheme is equivalent to the main Reactor shunt, only the new connections are accepted by the main Reactor, and the old connections are allocated to the subReactor to respond.

Proactor model

It is an asynchronous non-blocking model. Translated into Chinese as a foreshadowing device. I don't know what it is, it can be called an actuator. That is, we do not have to wait for the Istroke O data to be ready, that is, the kernel cache has read the data to user space. All this has a kernel to help us take care of it, notify Proactor when the data is ready, and then Proactor will call the corresponding Handler for business processing. The cost of traversing the event notification queue selector is saved compared to Reactor.

The handler and proactor are created by initiator and registered to the kernel through Asynchronous Operation Processor, and then the Asynchronous Operation Processor completes the handler O will notify the proactor,proactor and then call the corresponding handler to handle the business.

So theoretically, Proactor is more efficient than Reactor, but linux does not really implement the Proactor model, but epoll simulates the Proactor model.

The above is the difference between the Reactor model and the Proactor model. The editor believes that there are some knowledge points that we may see or use in our daily work. I hope you can learn more from this article. For more details, please follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.