Non-blocking I/O Server Model and blocking I/O Server Model

Non-blocking I/O Server Model and blocking I/O Server Model

Let's take a look at this situation. You and thousands of players are super fans of World of Warcraft. Every weekend, they will form a group of bosses. The game server is Alexander every weekend, because at least several hundred thousand users are online at the same time. Is it feasible to use our multi-thread blocking server as a game server? First, analyze the features of the game server:

① An online game is not like a web page. Once it is opened, the connection can be closed. Online Games must have a persistent and stateful connection. Each client must have a persistent connection with the server to send messages quickly and timely. As the number of concurrent users increases, the multi-thread blocking server cannot allocate a thread to each client.

② Unlike ordinary application servers, online games with CS structure generally put complicated logic processing on the client, while on the game server only process simple logic and even only transmit messages. In such a simple logic, we actually allocate a thread to each request. Is this seriously different from the actual situation?

③ Online games require fast response, timely message exchange, and bidirectional communication. Therefore, frequent requests and responses are required. If we have used persistent connections, but the server does not have new data every time and does not need to be sent to the client. So we still occupy a thread, isn't it a waste?

From the above analysis, for online games and other such occasions, our traditional multi-threaded server is obviously insufficient. The thread pool can alleviate the resource occupation caused by frequent IO calls to a certain extent, but the pool has a certain size limit. In the face of the high concurrency of thousands of client requests, but it is always not the best solution. Is it possible to maintain many persistent connections with one or a few threads? The following describes a new server model-non-blocking server model.

One of the most important features of the non-blocking server model is that an interface is returned immediately after it is called, without blocking the wait. As shown in 2-6-2-1, when multiple clients request from the server, the server stores a socket connection list and a dedicated thread polls the list. If you find that a socket has data readable, you can call the corresponding read operation of the socket. If you find that the socket has data writable, you can call the corresponding write operation of the socket; if a socket is interrupted, the socket close operation is called. To achieve better performance, you can also combine the thread pool. Once the socket that needs to be processed (read data, write data, and close) is detected, another thread is started to process the data.

Figure 2-6-2-1 non-blocking Server Model

 

In this way, no matter how many socket connections can be managed by a thread, a thread is responsible for Traversing these socket lists and handing them over to the thread pool, which makes good use of the blocking time, the processing capability is improved. However, this model involves traversing all the socket lists and processing data merging. It also occupies a large amount of CPU resources when idle, and is still not suitable for high concurrency scenarios. Make some improvements-the event-driven model. Its core is event-driven, and the thread does not traverse the socket list. Instead, it detects events and responds to detected events one by one. This greatly improves the detection efficiency and improves the processing capability.

What is a blocking or non-blocking io stream?

The advantages and disadvantages of blocking and non-blocking IO packages in Java are the cornerstone behind NIO design: the reactor mode, which is used for the architecture mode of event Multi-Channel Separation and allocation. Reactor: an architecture pattern used for event Multi-Channel Separation and allocation. Generally, two methods are available for a file or device specified by a file descriptor: blocking and non-blocking. Blocking means that when you try to read and write the file descriptor, the program enters the waiting state if there is nothing to read at the time or it cannot be written at the moment, until something is readable or writable. For non-blocking states, if nothing is readable or not writable, the read/write function returns immediately without waiting. A common practice is: each time a Socket connection is established, a new thread is created to communicate with the Socket separately (through blocking ). This method has a high response speed and is easy to control. It is very effective when the number of connections is small, however, generating a thread for each connection is undoubtedly a waste of system resources. If there are many connections, there will be insufficient resources. Another efficient method is to store a Socket connection list on the server side and round-robin the list. If data is readable on a Socket port (read-only ), the corresponding read operation of the socket connection is called. If a Socket port is found to be writable (write-ready), the corresponding write operation of the socket connection is called; if the Socket connection of a port has been interrupted, call the corresponding destructor to close the port. This greatly improves the efficiency of fully utilizing server resources. In the traditional blocking IO mode, each connection must be handled by a thread, and the thread cannot exit. Non-blocking I/O. Because it is based on the reactor mode, it is used in the architecture mode of event Multi-Channel Separation and allocation, so it can be processed by the thread pool. When the event comes, it is processed, and the thread is returned after processing. The traditional blocking method cannot use a thread pool for processing. If there are currently 10000 connections, the non-blocking method may be done with a thread pool of 1000 threads, the traditional blocking method requires 10000 requests. If the number of connections is large, there will be insufficient resources. The core advantage of non-blocking is here. First, let's analyze the bottleneck of traditional blocking IO. When the number of connections is small, traditional I/O writing is easy to use. However, as the number of connections increases, traditional I/O problems will not work. As mentioned above, the traditional IO processing consumes one thread for each connection, and the program efficiency increases with the increase of the number of threads when the number of threads is small, but after a certain number, is reduced with the increase in the number of threads. Here we come to the conclusion that the bottleneck of traditional blocking IO is that it cannot process too many connections. Then, the purpose of non-blocking IO is to solve this bottleneck. How is non-blocking I/O implemented? The number of threads for non-blocking IO processing connections is not linked to the number of connections. That is to say, 10000 threads are not required to process 10000 non-blocking IO connections, you can use 1000 or 2000 threads for processing. Because non-blocking IO processing connections are asynchronous. When a connection sends a request to the server, the server treats the connection request as a request "Event" and assigns this "Event" to the corresponding function for processing. We can put this processing function in the thread for execution, and return the thread after execution. In this way, a thread can process multiple events asynchronously. Most of the time for blocking I/O threads is wasted waiting for requests.

Is java io blocked or not?

Of course it is blocked.