Hello, my name is yes.
Before diving into Netty's Reactor implementation, I want to talk about what exactly is Reactor?
This problem has actually troubled me for a long time. I have found a lot of articles on the Internet before, but when I look at it, I always feel that there is a layer of yarn.
I also went to the Reactor paper, maybe due to my poor personal level, I was even more confused... I was dizzy with a bunch of concepts.
Finally, I went to see the source code of Redis and Netty, because they both implement Reactor, and it seems that Reactor is not as complicated as it looks, and the implementation and theory are still a bit different.
So, next, I will talk about my understanding of Reactor based on the Reactor implementation of the two open source projects I have seen and my own YY, and please correct me if I am wrong.
Understanding of Reactor
What is Reactor? In fact, it is a programming mode or an architectural mode, which is commonly used in modules related to network communication on the server side .
Reactor literally translated into Chinese is a reactor. Although the literal translation is not appropriate, it is indeed related to "reaction".
What is the reaction? React to triggered events .
When I was in college, I believe that many people have done such big jobs as book management systems, which are all based on Java GUI. Of course, it is not important how to implement it. What matters is whether the finished product is clickable after you finish it. A button will pop up a corresponding pop-up box?
Clicking the button will pop up the box, different buttons will pop up different boxes, this is the reaction.
We computers don't pay attention to abstraction, so if we abstract the above, we need different processing logic (method invocation) for different events .
At this point, we got two concepts: event (clicking the button) and processing logic (playing the corresponding box).
Going back to the scene of the pop-up box, think about it, who is listening to the action of the button being clicked to pop up different boxes?
Here, we can easily think of two situations:
- A button sends a thread to guard, as long as the button is clicked, this thread executes the popup
- A thread polls the status of all buttons, and the infinite loop checks that as long as one button is clicked, it finds the box bound to the button, and then pops the button.
If there are few buttons, in fact, sending a few more threads to guard it has little effect. Suppose there are one thousand or ten thousand buttons? In this scenario, the second implementation is better. After all, the button is not always clicked, right?
We map "people", "click buttons" and "pop-up boxes" to network programming, which are threads, events, and processing.
The first case is translated as a thread receives a connection. Whenever an event occurs on the connection, the thread will respond to the event.
This corresponds to the network programming model a long time ago, when there were not so many users on the Internet, and there was only blocking I/O. If the connection did not respond, then the thread had to block waiting for the I/O event to occur.
The translation of the second case is that a thread receives multiple connections. No matter which connection has an event, this thread will find the corresponding processing logic to respond according to the event.
This is the I/O multiplexing based on non-blocking I/O that is currently popular. This scenario is suitable for a large number of users. The server can handle a large number of connections with few threads, as I said above. , after all, the connection (button) is not always requested (clicked).
As for the events I mentioned earlier, there are three basic I/O events: connection events, read events, and write events.
Now back to network I/O, let's look at Reactor again: that is, there is a selector (select/poll/epoll) thread, which manages many connections. As long as an event occurs on a connection, it will wake up the selector thread. This The thread will do different processing according to the type of event that occurs.
This is the Reactor, and the corresponding thread is also called the Reactor thread (just rely on it to react).
What is the scenario without Reactor?
In the first case mentioned above, a thread receives a connection. Unlike the second case, where one thread handles many connections, and one "responsible person" handles multiple clients, there is one person for everything. Does that person feel like a Reactor?
Being able to implement one-to-many responses according to different requests is the core of Reactor in my opinion. As for things such as events, schedulers, and Acceptors, I think they are some concepts that must be done in order to write a thesis or article. Anyway, after understanding it, it is the same thing, because there must be such a number of things to go through the process. thing.
As we know SpringMVC, if a request can find the corresponding Controller, then there must be a unified entry to determine the route, so there must be such a thing, otherwise the request will not be able to reach the Controller, then this thing is called What? Isn't it DispatcherServlet, isn't the Chinese name the front controller.
Therefore, it is not that SpringMVC needs to have such a thing as DispatcherServlet, but SpringMVC needs to have a unified entry to determine the route, so it got an implementation class, which is called DispatcherServlet.
You know what I mean.
The same is true for Reactor. It does not mean that Reactor needs to have something called Demultiplexer, Dispatcher, Handle, and Event Handler to be called Reactor.
Instead, it is based on non-blocking I/O in network I/O, and requires a small number of threads to receive a large number of connections. In such a scenario, a device must be used as a listener to monitor whether there are requests for so many connections at the bottom, and then According to the type of request (abstract event), assigning and calling different processing logic, the above nouns are correspondingly derived.
In terms of specific implementation, Demultiplexer and Dispatcher can of course be the same thread, in the same infinite loop, which is all ok, don't look at the noun to understand, the code must be divided into such two things, no.
Based on the above understanding, and then look at this picture from the Reactor paper, is it easy to understand.
Finally, let's talk about the official answer:
Reactor is a programming mode for server-side in network programming. It is mainly composed of an infinite loop thread based on Selector (the bottom layer is select/poll/epoll), also known as Reactor thread. The I/O operation is abstracted into different events, each event is configured with a corresponding callback function, the Selector monitors the occurrence of the event on the connection, and then distributes and calls the corresponding callback function to process the event.
At last
Well, that's all for today.
Regarding the master-slave Reactor, I believe that as long as you understand what a Reactor is, these should not be difficult, and I will talk about it later when I write Netty's Reactor.
To reiterate, the above are all my Reactor implementations based on Redis and Netty, and then add my own understanding, personal ability is limited, please correct me if there are any mistakes, welcome to discuss in the comment area.
I'm yes, from a little to a million, see you in the next part~