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

This article introduces the relevant knowledge of "how to master DRPC architecture". Many people will encounter such a dilemma in the operation of actual cases, so let the editor lead you to learn how to deal with these situations. I hope you can read it carefully and be able to achieve something!

Architecture analysis

With the picture and the truth, let's take a look at the architecture diagram of DRPC:

From the figure above, the entire DRPC is divided into three parts:

Client: code that actually uses DRPC services

DRPCServer: the DRPC server from a Client perspective is the one that hides all the implementation details of DRPC from Client's eyes.

Storm: the Storm here refers to the Spout, Bolt of the storm that really implements the DRPC function, such as JoinResult, ReturnResults, and so on.

What's interesting here is that for DRPCServer, Client and Storm are both "clients", but they do different jobs. Let's analyze the entire request submission and return the process to see what they have done:

First, DRPCClient submits the request to DRPCServer

DRPCServer first generates a request-id for the request, and then throws it into a request-id-> request pool

When DRPCServer puts request into the pool, it generates a Semaphore at the same time, and puts the Semaphore into a request-id-> semaphore pool.

At the same time, it calls semaphore.acquire () to wait on the semaphore for the result to arrive.

The Storm component gets the request that needs to be processed from the request-id-> request pool

Through DRPCSpout, PreapreRequest, JoinResult, ReturnResults and a bunch of guys to process the request.

Send the result of the processed request back to the request-id-> result pool of DRPCServer.

At the same time, the semaphore corresponding to the request will be extracted from the request-id-> semaphore pool through request-id, and the semaphore will be released by calling semaphore.release ().

After the semaphore is released, the waiting thread blocked on the DRPCServer can continue to execute, go to the request-id-> result pool to fetch the result and return it to the waiting client.

Asynchronous DRPC

Storm does not support asynchronous DRPC yet, but it should be very simple to implement asynchronous DRPC based on the above model. I drew something like this:

The changes are small compared to the synchronous DRPC above:

After the request is submitted, the server does not wait on the Semaphore, but immediately returns a Future object to the client.

This Future object carries the information of request-id

Maintain a request-id-> result pool on the client side. When the client calls future.get () in the future, it will look for the result in this pool.

After the server finds that the result of the request comes, it goes back to the result pool of the client.

This is the end of the content of "how to master DRPC architecture". Thank you for reading. If you want to know more about the industry, you can follow the website, the editor will output more high-quality practical articles for you!

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.