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

Mycat user's Manual:

The system I paw O can be divided into blocking type, non-blocking synchronous type and non-blocking asynchronous type.

Blocking Ihamdo O means that control will not be returned to the caller until the calling operation is over. As a result, the caller was blocked and couldn't do anything else during this time. What's even more frustrating is that while waiting for the IO result, the caller's thread is unable to free up to respond to other requests, which is a waste of resources. In the case of the read () operation, the code that calls this function will remain frozen here until there is data in the socket cache it reads.

By contrast, non-blocking synchronization immediately returns control to the caller. The caller does not need to wait, it gets two results from the called function: either the call is successful, or the system returns an error flag telling the caller that the current resource is not available. You can wait or try again. For example, the read () operation, if the current socket has no data to read, immediately returns EWOULBLOCK/EAGAIN, telling the caller of read () that "the data is not ready, you can try again later."

In non-blocking asynchronous calls, it is slightly different. When the calling function returns immediately, it also tells the caller that the request has started. The system uses another resource or thread to complete the call, and notifies the caller when it is done (for example, through a callback function). Take ReadFile () of Windows or aio_read () of POSIX. After calling it, the function returns immediately, and the operating system starts reading in the background.

Among the above three forms of IO, in theory, non-blocking asynchrony has the highest performance and the best scalability.

Synchronous and asynchronous are relative to the way the application interacts with the kernel, synchronous needs to ask actively, while asynchronous kernel notifies the application when IO events occur, blocking and non-blocking are just the way the system implements functions when calling system calls.

For JAVA's API:

Java.net.Socket is a typical blocking IOjava NIO non-blocking synchronous java AIO non-blocking asynchronous.

MyCAT originated from Cobar,Cobar, the front end is NIO, the back end is BIO, and the back end reads and writes through java.net.Socket, so each time the Cobar backend reads and writes, it will cause thread blocking, and the total number of connections that can be supported by the backend becomes the bottleneck.

When MyCAT is modified based on Cobar, AIO of Java 7 is directly adopted, and non-blocking asynchronism is realized at both ends. Because Linux does not really implement AIO, actually tested, AIO is not faster than NIO, but the performance is slower than NIO. So in the second half of 2014, MyCAT made a major change to the network communication framework to support both AIO and NIO, allowing users to choose which way through the startup parameters. Although AIO is now slower than NIO, MyCAT still retains the AIO implementation, just to wait for Linux to support AIO directly after it really implements it.

Reactor and Proactor

MyCAT implements both NIO and AIO. In order for readers to understand the code implementation more clearly, this paper first introduces two design patterns corresponding to NIO and AIO distribution: Reactor and Proactor.

Generally speaking, event sharer (event demultBossiplexor) is required for Ihammer O reuse mechanism. The function of the event sharer is to distribute the read and write event sources to the handlers of the read and write events, just like the courier shouting downstairs: whose what has been delivered, come and get it. At the beginning, the developer needs to register the event of interest with the sharer and provide the corresponding event handlers, or callback function; the event sharer will distribute the requested event to these handler or callback functions when appropriate.

The two modes that involve event sharers are called Reactor and Proactor. The Reactor mode is based on synchronous Imab O, while the Proactor mode is related to asynchronous Imax O. In Reactor mode, the event separator waits for an event or the state of an application or operation to occur (such as a file descriptor readable or socket readable), and the event separator passes the event to a pre-registered event handler or callback function, which does the actual read and write operation.

In Proactor mode, the event handler (or initiated on behalf of the event separator) directly initiates an asynchronous read and write operation (equivalent to a request), while the actual work is done by the operating system. When initiating, the parameters you need to provide include the cache area used to store the read data, the size of the read data, or the cache area used to store outgoing data, and the callback function after the request. The event splitter learns of the request, silently waits for the request to be completed, and then forwards the completion event to the appropriate event handler or callback. For example, on Windows, event handlers deliver an asynchronous IO operation (called overlapped technology), event separators and other IOCompletion events are completed. The typical implementation of this asynchronous pattern is based on the underlying asynchronous API of the operating system, so we can call it "system-level" or "real" asynchronous, because the specific read and write is done by the operating system.

The difference between the scenarios of Reactor and Proactor:

Here's what Reactor does: wait for the event response (Reactor job) to distribute the "Ready-to-Read" event to the user handle (Reactor job) read data (user handler job) process data (user handler job)

Let's take a look at what the real asynchronous mode Proactor does: wait for event response (Proactor job) read data (Proactor job) distribute "Read-Completed" events to user handles (Proactor job) process data (user handler job)

As can be seen from the above, the main difference between Reactor and Proactor mode is who does the real read and write operation. In Reactor, the application needs to read or write data by itself, while in Proactor mode, the application does not need to read or write from the cache, and the operating system will read or write the cache to the real IO device.

Finally, it is easier to understand by combining the following two pictures (this is someone else's picture, not original):\

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.