Shulou(Shulou.com)05/31 Report--

This article shows you the principle of synchronous API implementation under non-blocking communication in RPC framework Dubbo. The content is concise and easy to understand, which can definitely brighten your eyes. I hope you can get something through the detailed introduction of this article.

Netty basically takes the lead in the field of Java NIO. When it comes to high-performance network communication, Netty is basically used as the underlying communication framework, and Dubbo is no exception. The following will take the Dubbo implementation as an example to show how it implements synchronous communication on the basis of NIO non-blocking communication.

Dubbo is a RPC communication framework that provides inter-process communication. When using dubbo protocol + Netty as the transport layer, API calls are provided in three ways:

Synchronous interface

Asynchronous with callback interface

Asynchronous without callback interface

The synchronization interface is suitable for most environments, the communication mode is simple and reliable, the client initiates the call, waits for the server to process, and the call result returns synchronously. In this way, it is most suitable in high-throughput, high-performance (fast response time) service interface scenarios, which can reduce the additional consumption caused by asynchronism and facilitate the client to ensure consistency.

The asynchronous callback interface is used when the task processing time is long, the client application thread does not want to block waiting, but in order to improve its processing power, it hopes that the server can notify the application thread asynchronously after processing is completed. This method can greatly improve the throughput of the client and avoid dragging the client to death because of the time-consuming problem of the server.

There is no callback API for asynchronism. In some scenarios, in order to further improve the client's throughput, you only need to initiate a server call, which does not need to be related to the call result. You can use this communication method. In general, when there is no need to strictly ensure data consistency or other compensation measures, this can minimize the performance loss caused by remote calls.

Let's take a look at how Dubbo implements these three API. The core code is in com.alibaba.dubbo.rpc.protocol.dubbo.DubboInvoker, corresponding to the following figure, which belongs to the implementation part of the protocol layer. In order to make it convenient for you to accurately locate the location of the code, use screenshots instead of directly pasting the code.

There are three API methods described above. Dubbo is controlled by parameters isOneway and isAsync. IsOneway=true means asynchronous without callback, and isAsync=true means asynchronous with callback, otherwise it is synchronous API. For more information on how to control it, see the following code:

In isOneway==true, when the client send completes the request and directly return an empty result RpcResult;isAsync==true, the client initiates the request, sets a ResponseFuture, and directly return an empty result RpcResult. Then, when the server processing is completed, the client Netty layer will notify the application thread through Future after receiving the response. Finally, in the case of synchronization, the client initiates the request and uses the get () method to block and wait for the server's response.

In the case of asynchronous API, it is better to understand how it is implemented combined with the NIO model (of course, you need to understand the reactor model of NIO first), and then focus on understanding how this get () blocking method is based on non-blocking NIO to achieve synchronous blocking effect.

Go directly inside the get () method.

You can see that it is implemented using Java's locking mechanism, which loops to determine whether a response is received, and returns if it is received or waits for a timeout. The instance object of done is as follows:

Private final Lock lock = new ReentrantLock (); private final Condition done = lock.newCondition ()

Using the reentrant lock ReentrantLock, get a Condition object to do the await operation on it. There are await operations. There are two conditions for when to be awakened. The first is to wait for the timeout timeout. The default dubbo is 1s. The second is to be awakened by other threads, that is, a response from the server is received.

As soon as the signal signal is sent, the await operation in the above loop detection will be returned immediately, and the next isDone judgment will become true and jump out of the loop directly.

If you take a closer look at the code, you will find that another place to be awakened is that there is a thread for timeout polling detection inside the DefaultFuture, which mainly triggers resource recovery and logs exception logs after processing the response timeout.

Private static class RemotingInvocationTimeoutScan implements Runnable {public void run () {while (true) {try {for (DefaultFuture future: FUTURES.values ()) {if (future = = null | | future.isDone ()) {continue } if (System.currentTimeMillis ()-future.getStartTimestamp () > future.getTimeout ()) {/ / create exception response. Response timeoutResponse = new Response (future.getId ()); / / set timeout status. TimeoutResponse.setStatus (future.isSent ()? Response.SERVER_TIMEOUT: Response.CLIENT_TIMEOUT); timeoutResponse.setErrorMessage (future.getTimeoutMessage (true)); / / handle response. DefaultFuture.received (future.getChannel (), timeoutResponse);}} Thread.sleep (30);} catch (Throwable e) {logger.error ("Exception when scan the timeout invocation of remoting.", e) }} static {Thread th = new Thread (new RemotingInvocationTimeoutScan (), "DubboResponseTimeoutScanTimer"); th.setDaemon (true); th.start ();}

It may be doubtful why this trigger operation does not directly detect a timeout inside the get () method and directly calls DefaultFuture.received (Channel channel, Response response) to clean up, but instead starts an additional background thread.

Starting a time-out thread separately has two benefits:

Improve the accuracy of timeout

The polling inside the get () method has a timeout, and the interval between each timeout wake up is at least the length of the timeout, and in the worst case, it may wait for the 2*timeout to time out. In the timeout polling thread, every 30ms traversal detection can greatly improve the timeout accuracy.

two。 Improve performance and reduce response time

Stripping the timeout processing logic to a separate thread can reduce the time taken by the business thread. The timeout processing has no direct effect on the application and can be processed asynchronously in the background. In addition, in a single thread, there is actually the performance of batch processing.

The above is the implementation principle of three kinds of API calls on the basis of NIO communication, and there may be more processing methods that are better than Dubbo, which can be discussed.

The above is the principle of synchronous API implementation under non-blocking communication in RPC framework Dubbo. Have you learned any knowledge or skills? If you want to learn more skills or enrich your knowledge reserve, you are welcome to 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.