CN112565286A

CN112565286A - Task response method, device, equipment and storage medium based on RPC access

Info

Publication number: CN112565286A
Application number: CN202011500127.1A
Authority: CN
Inventors: 禹希初; 杨华中; 吴宏超
Original assignee: Kingdee Software China Co Ltd
Current assignee: Kingdee Software China Co Ltd
Priority date: 2020-12-17
Filing date: 2020-12-17
Publication date: 2021-03-26

Abstract

The application relates to a task response method and device based on RPC access, computer equipment and a storage medium. The method comprises the following steps: receiving an RPC access request initiated by a client, generating a network access task, and performing corresponding service processing; determining task waiting time corresponding to a network access task; when the network access task is completed within the task waiting time, obtaining a corresponding service processing result and feeding the service processing result back to the client; when the network access task is not completed within the task waiting time, creating a corresponding task identifier, responding to the RPC access request, and feeding back the task identifier to a client; the fed-back task identifier is used for indicating the client to inquire the task state corresponding to the network access task based on the task identifier; and obtaining a service processing result corresponding to the network access task. By adopting the method, the network access efficiency can be improved.

Description

Task response method, device, equipment and storage medium based on RPC access

Technical Field

The present application relates to the field of communications technologies, and in particular, to a method, an apparatus, a device, and a storage medium for responding to a task based on RPC network access.

Background

A public cloud generally refers to a cloud that can be used by a third-party provider to provide users, and an enterprise provides services directly to external users through its own infrastructure. And an external user accesses the service through the Internet and does not own cloud computing resources. In the conventional scheme, at the server side, a Remote Procedure Call (RPC) is typically performed in the following manner: receive request-process task-return response. In a typical public cloud environment, a network access timeout limit is usually set in order to improve network access efficiency. The network access timeout is that the server does not respond within the task waiting time set by the default of the program, and information cannot be fed back according to the access requirement of the access initiator. The network access timeout is typically set to be short (60 seconds for some public clouds).

To prevent the client network timeout of RPC calls due to too long task execution time, it is currently typical to execute asynchronously: when the server side of the RPC receives the call request, generating a task and submitting the task to a task management module for execution, and then immediately returning a task ID to the client side; and if the client of the RPC needs to obtain the execution result of the task, the client uses the task ID as a parameter to obtain the result through another RPC call after waiting for a period of time.

However, for the asynchronous execution mode in the conventional scheme, although the largest unknown factor of task execution time can be avoided, network timeout can be avoided to a certain extent. However, most RPC access requests have returned results, so in order to obtain the results, a complete RPC access usually requires at least two network requests (a first request is initiated; a second request is obtained, and even more network requests are needed to obtain the results), and the problem of low network access efficiency still exists.

Disclosure of Invention

In view of the foregoing, it is desirable to provide a task response method, apparatus, computer device and storage medium based on RPC access, which can improve the efficiency of network access.

A task response method based on RPC access, the method comprising:

receiving an RPC access request initiated by a client, generating a network access task according to the RPC access request, and performing corresponding service processing according to the network access task;

determining task waiting time corresponding to the network access task;

when the network access task is completed within the task waiting time, acquiring a corresponding service processing result, responding to the RPC access request, and feeding back the service processing result to a client;

when the network access task is not completed within the task waiting time, creating a corresponding task identifier for the network access task, and responding to the RPC access request and feeding back the task identifier to a client; the fed-back task identifier is used for indicating the client to inquire the task state corresponding to the network access task based on the task identifier;

and responding to a task query instruction initiated by the client, querying and feeding back task state information of a corresponding network access task according to a task identifier carried in the task query instruction.

In one embodiment, the RPC access request carries an objective function identifier, and the objective function is used to perform corresponding service processing according to the network access task, and includes:

searching a target function corresponding to the target function identification from a server-side local function library according to the target function identification;

and calling the target function according to the network access task to execute service processing corresponding to the target function.

In one embodiment, the method further comprises:

after a network access task is generated at a server side, task management is carried out on the network access task through a task management module, and after the server side carries out corresponding business processing according to the network access task, a business processing result of the network access task is cached through the task management module.

In one embodiment, the task management of the network access task by the task management module includes:

queuing the network access tasks according to the priority or time sequence through the task management module to obtain a task queue;

sequentially executing the network access tasks according to the task queue through the task management module;

and caching the service processing result corresponding to each network access task through the task management module.

In one embodiment, the feeding back the service processing result to the client in response to the RPC access request includes:

through the task management module, after the caching of the service processing result of the network access task of the server is completed, the processing thread of the RPC access request initiated by the client is actively awakened, and the service processing result is actively fed back to the client through the processing thread.

In one embodiment, the task waiting time comprises a task waiting time with a fixed duration and a task waiting time with a non-fixed duration;

the task waiting time with the fixed time length is used for indicating the server end to carry out task response within the task waiting time with the fixed time length from the moment of receiving the RPC access request;

the task waiting time with the non-fixed duration is used for indicating the server to carry out task response at any time specified by the client, the server or the task management module.

In one embodiment, when the task state information indicates that the network access task is not completed, the task state information is used to instruct the client to continuously initiate a task query instruction until a service processing result corresponding to the network access task is obtained.

A RPC access based task response apparatus, the apparatus comprising:

the task execution module is used for receiving an RPC access request initiated by a client, generating a network access task according to the RPC access request and performing corresponding service processing according to the network access task;

the determining module is used for determining task waiting time corresponding to the network access task;

the feedback module is used for acquiring a corresponding service processing result when the network access task is completed within the task waiting time, and feeding back the service processing result to the client in response to the RPC access request;

the feedback module is further configured to create a corresponding task identifier for the network access task when the network access task is not completed within the task waiting time, and feed back the task identifier to the client in response to the RPC access request; the fed-back task identifier is used for indicating the client to inquire the task state corresponding to the network access task based on the task identifier;

and the feedback module is also used for responding to a task query instruction initiated by the client, querying and feeding back task state information of a corresponding network access task according to a task identifier carried in the task query instruction.

A computer device comprising a memory and a processor, the memory storing a computer program, the processor implementing the following steps when executing the computer program:

determining task waiting time corresponding to the network access task;

A computer-readable storage medium, on which a computer program is stored which, when executed by a processor, carries out the steps of:

determining task waiting time corresponding to the network access task;

According to the task response method and device based on RPC access, the computer equipment and the storage medium, after the RPC access request initiated by the client is received, the corresponding network access task can be generated, and therefore the network access task is executed. Meanwhile, a task waiting time is preset, and if the processing of the network access task is completed and a corresponding result is obtained within the task waiting time, the RPC access request can be responded in time; if the network access task is not processed within the task waiting time, the task identifier of the network access task corresponding to the RPC access request is fed back to the client and then the current RPC access process is ended. Therefore, the client can know the processing progress of the network access task in time and obtain the corresponding service processing result in time, the RPC access efficiency is improved, and unnecessary task waiting time of the client is reduced.

By the mode, the RPC access efficiency can be greatly improved, unnecessary task waiting time is reduced for the RPC process which can obtain the access result in time, smooth completion of the RPC access is guaranteed by feeding back the task identifier for the RPC process which cannot obtain the access result in time, the access request does not need to be submitted repeatedly, simplicity and reliability are realized, the task waiting time and the network request cost of the client are reduced, and the network access efficiency is effectively improved.

Drawings

FIG. 1 is a diagram of an application environment of a task response method based on RPC access in one embodiment;

FIG. 2 is a timing diagram that illustrates asynchronous execution of network access tasks in one embodiment;

FIG. 3 is a timing diagram for network access using result pushing in one embodiment;

FIG. 4 is a flow diagram of a RPC access based task response method in one embodiment;

FIG. 5 is a flow diagram that illustrates corresponding business processing performed on network access tasks using an objective function, according to an embodiment;

FIG. 6 is a timing diagram of the steps of a RPC access-based task response method in one embodiment;

FIG. 7 is a block diagram of a task response device based on RPC access in one embodiment;

FIG. 8 is a computer device based on RPC access in one embodiment.

Detailed Description

In order to make the objects, technical solutions and advantages of the present application more apparent, the present application is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the present application and are not intended to limit the present application.

The task response method based on RPC access can be applied to the application environment shown in FIG. 1. Wherein, the client 102 communicates with the server 104 through the network. The client 102 sends the RPC access request to the server 104 according to its own requirements, and the server generates a network access task according to the RPC access request, and the network access task is stored in the task management module 106. The task management module 106 executes the network access task, caches a service processing result obtained by executing the network access task after the network access task is executed, and informs the server 104 of a task execution completion state, so that the server 104 can respond according to a thread processing state of a current RPC access request of the client 102 and feed back the service processing result to the client 102. In the process, the processing threads of the server and the client are independent from the processing threads between the server and the task management module.

In the above embodiments, the client 102 may be, but is not limited to, various personal computers, notebook computers, smart phones, tablet computers, and portable wearable devices, and the server 104 may be implemented by an independent server or a server cluster formed by a plurality of servers. The task management module 106 may be a device that provides functions of queuing, executing, managing, controlling, and the like for tasks, which is set independently from the server, or may be implemented by a software module deployed at the server, and the like, which is not limited in the present application.

In order to better understand the present application, before describing the RPC access-based task response method of the present application, how to obtain a task structure by asynchronously executing a network access task in the following conventional scheme is introduced. Referring to FIG. 2, a timing diagram of the asynchronous execution of network access tasks in one embodiment is shown. As shown in fig. 2, to prevent the task execution time from being too long and causing the client network of RPC calls to timeout, the typical practice is to execute asynchronously: when the server side of the RPC receives the call request, generating a task and submitting the task to a task management module for execution, and then immediately returning a task ID to the client side; and if the client of the RPC needs to obtain the execution result of the task, the client uses the task ID as a parameter to obtain the result through another RPC call after waiting for a period of time.

However, the task result obtained by the polling method has some inevitable defects, which are embodied in the following aspects:

(1) multiple network requests are required: since most RPC have returned results, in order to obtain the results, a complete RPC usually requires at least two network requests (the first time of initiating the request; the second time of obtaining the results, even more network requests are needed to obtain the results), which inevitably reduces the network access efficiency.

(2) Additional task latency is required: because the client terminal is difficult to accurately estimate the actual execution time of the server terminal, the task waiting time of the client terminal cannot be set to be very short frequently in order to obtain the result when the client terminal requests the next network as far as possible; if it is desired to reduce task latency by getting results as quickly as possible, multiple network requests may result because the task has not yet been completed. No matter how the task waiting time is set, the result is obtained in a polling mode, and the task waiting time of the client side is always longer than the actual execution time of the server side. This can significantly increase the overall execution time of the business process while waiting for the results of the RPC to decide on subsequent processing.

To address this problem, a scheme of implementing network access using result push as shown in fig. 3 has been produced. Namely: after the client sends the RPC request, the client does not wait for the task processing result; instead, after the task management module executes the task, the server side initiates a reverse RPC call (callback) to push the result to the client side. However, using the "result push" mechanism to solve the waiting problem of the client introduces a great complexity in the whole system, resulting in some generally more difficult problems, such as:

(1) the client programming model is changed from 'synchronous execution' into 'asynchronous execution', and a complete service process related to RPC needs to be forcibly split into a plurality of independent sub-processes, so that huge jump battles are brought to development, operation and maintenance.

(2) In order to prevent the result processing time of the client from being too long to cause network timeout when the result is pushed, the client must also introduce the same asynchronous task execution mechanism.

When the client and the server belong to different companies or different systems, it is very difficult to maintain the complex coordination mechanism; while a complete business process may involve multiple RPC calls, maintaining a multi-system participatory result push (callback) coordination mechanism would be an impossible task due to the drastically increased complexity.

(3) The result pushing mechanism still needs two network requests to process one complete RPC call; the vulnerability of two network requests is inversely a minor problem compared to the increased system complexity.

The present application is a scheme obtained by improving some problems existing in the above scenario. Before describing the RPC access-based task response method in the present application, the following explanations are first made for some terms involved in the embodiments of the present application:

asynchronous task: after the task is submitted to the server, the task submitting party does not need to wait for the result after the task is executed.

A client: the party initiating the RPC call sends the request parameters through the network and expects to obtain the execution result.

A server side: the party realizing RPC calling receives the request parameters through the network and returns the result after execution.

A task management module: the basic device or module for providing queuing, executing, managing and controlling functions for tasks can be located in the server or exist independent of the server. The task management module can separately execute the task scheduling management thread.

RPC: and Remote Procedure Call (Remote Procedure Call), wherein the client remotely calls a function at the server end to execute a corresponding network access task through network communication. Specifically, the client side tells the server side what network access task needs to be executed by calling the target function located at the server side through network communication, and after finding the corresponding target function, the server side calls the target function to execute the corresponding network access task and feeds back the result to the client side. And (3) network access task: after receiving the RPC call request from the client, the server needs to identify the RPC call request, and determines what kind of access task the client requests the server to complete, namely the network access task the server needs to complete.

And (3) service processing results: and calling a target function located locally to execute a corresponding network access task and then obtaining a service processing result.

Task identification: after the server side generates the network access tasks, each network access task corresponds to a task identifier for indicating the network access task.

And (4) task state: the task management module executes the task state of the network access task, including but not limited to task performed completion, task execution, and the like.

And a task query instruction: and the instruction is initiated by the client and used for inquiring the processing state of the network access task of the corresponding RPC access request at the server based on the task identifier.

For example, the client calls the function a to process the target data information of the server to obtain a corresponding service processing result based on its own requirements, but because the client and the server belong to two objects, the client cannot directly process the target data by using the function a, and at this time, the client needs to call the server by using an RPC to tell the server that the server needs the function a to process the service processing result of the target data. After the server side knows the information, a network access task is correspondingly generated, in this example, "processing target data by using a function" is performed, the network access task is stored in a task queue of the task management module, and the task management module executes the network access tasks according to the sequence of the task queue to obtain a corresponding service processing result to respond to the RPC request of the client side. In the process, if the network access task is not processed and completed within the specified time, the server side feeds back a task identifier corresponding to the network access task (for example, a task is numbered or other modes capable of identifying the network access task) to the client side in time, and the client side knows that the network access task requested by the client side is not completed and needs to continue waiting after receiving the task identifier, and can initiate a task query instruction according to the task identifier to acquire a task state of the task management module for executing the network access task.

As shown in fig. 4, in an embodiment, a specific flow of the RPC access-based task response method provided by the present application includes:

step S402, receiving an RPC access request initiated by a client, generating a network access task according to the RPC access request, and performing corresponding service processing according to the network access task.

Specifically, the client initiates a request of RPC call to the server, and the server correspondingly generates a network access task after receiving the request and stores the network access task in the task management module. The task management module executes the network access task, caches the result of the executed task, and then awakens the task processing thread of the client through the server. In other words, after the client initiates an RPC access request, the server generates a corresponding network access task according to the RPC access request of the client, and calls a corresponding local function to perform an execution process on the task.

Step S404, determining task waiting time corresponding to the network access task.

Specifically, to improve the efficiency of client RPC calls, the server may be provided with task latency. If the task management module obtains the task result corresponding to the RPC access request within the task waiting time, the task management module can directly wake up the task processing thread of the client through the server side to perform subsequent processing. If the task management module does not obtain the task result corresponding to the RPC access request in time within the task waiting time, the server side also feeds back the task identifier of the network access task corresponding to the RPC access request of the client side to the client side, and the client side can initiate the task query instruction again according to the task identifier until the service processing result corresponding to the RPC access request is obtained.

Therefore, after the server generates the network access task, it needs to respond to the RPC access request from the client within the specified task waiting time. In the task waiting time period, the processing thread of the RPC access request initiated by the client does not end, but is in a waiting state.

Step S406, determining whether the network access task is completed within the task waiting time.

Namely, the task waiting time is taken as a judgment standard, and corresponding processing is respectively carried out for the network access task completed in the task waiting time and the network access task not completed in the task waiting time. When the network access request is completed within the task waiting time, it jumps to step S408, otherwise, it jumps to step S410.

Step S408, when the network access task is completed within the task waiting time, a corresponding service processing result is obtained, and the service processing result is fed back to the client in response to the RPC access request.

Specifically, within the task waiting time, if the task management module completes the network access task and obtains the corresponding service processing result, the information of task processing completion is fed back to the server in time and the processing thread of the RPC access request in the waiting state is awakened, and after the server sends the service processing result to the client, the processing thread can be ended and the response is completed.

Step S410, when the network access task is not completed in the task waiting time, a corresponding task identifier is established for the network access task, and the task identifier is fed back to a client in response to the RPC access request; and the fed back task identifier is used for indicating the client to inquire the task state corresponding to the network access task based on the task identifier.

Specifically, in the task waiting time, if the task management module does not execute the processing to complete the network access task and the task waiting time is counted to end, a signal indicating that the task has not been executed is fed back to the client. In this embodiment, this signal is the task identifier. The task identifier corresponds to a network access task of the server, and the server can correspondingly attach an identification identifier to each network access task at any time before the task waiting time is finished. The task identifier may be any identifier information that can distinguish each network access task, such as a number or an identification code of the network access task, and this is not specifically distinguished in this embodiment. In some cases, the task identifier may also be generated by the task management module and synchronized to the server.

If the client receives the task identifier corresponding to the network access task instead of the service processing result corresponding to the RPC access request after the task waiting time is over, it means that the network access task is not executed and completed within the specified task waiting time, or the network access task is still in the processing process. Meanwhile, the task identifier can also provide a query parameter for the client, and the client can initiate a task query instruction again through the task identifier to query a service processing result corresponding to the prior RPC access request corresponding to the task identifier. The task query instruction may be an RPC call or other instruction form that can achieve the above-mentioned purpose.

Step S412, responding to a task query instruction initiated by the client, querying and feeding back task state information of a corresponding network access task according to a task identifier carried in the task query instruction.

Specifically, if the client does not obtain the service processing result corresponding to the RPC access request as expected after the task waiting time is over, the client may initiate a task query instruction again according to the requirement after receiving the corresponding task identifier, and the task query instruction does not request network access again, but directly queries the service processing result corresponding to the previous RPC access request. If the server side displays that the network access task is processed and finished and obtains a corresponding service processing result, the service processing result is fed back to the client side, otherwise, the task identification is continuously sent to the client side, and the client side can initiate a next task query instruction according to the task processing result until the corresponding service processing result is obtained.

Therefore, after the client initiates the RPC call task, the client receives a specific feedback no matter whether the server can give the task processing result corresponding to the RPC call or not after a task waiting time. The feedback may be a specific task processing result, that is, the server completes the response to the client within a specified time, or may be information in the task processing, that is, a task identifier of a network access task is received. The client receives the task identifier, and obtains the following information: the network access task corresponding to the RPC access request corresponding to the task identifier is not yet processed, and the client still needs to wait for a period of time to obtain a corresponding processing result. Therefore, the client can initiate the query of the processing result of the corresponding RPC network access task again at one or more moments after receiving the task identifier, and the processing result can be obtained in time after the network access task processing of the server is completed.

Therefore, on one hand, if the client cannot obtain the result of the RPC access request in the task waiting time, the client can still obtain a task identifier representing that the task is executing, and according to the task identifier, the client can still obtain the result corresponding to the RPC access request from the server according to the requirement of the client. On the other hand, if the client can obtain the result of the RPC access request in the task waiting time, the system does not need to set an additional task identifier for each RPC request, but only sets the task identifiers for the processes which do not obtain the result of the RPC access request in the task waiting time, and simultaneously informs the client of waiting, the access request does not need to be repeatedly submitted, and the RPC access efficiency can be effectively improved.

In a specific application scenario, such as a picture recognition environment, the client initiates an RPC call based on its own needs. For example, the server side is requested to provide all the pictures containing flowers in the database. After receiving the RPC call request, the server generates a network access task, that is: and inquiring and acquiring all pictures containing flowers in the database. The specific query process can be obtained by calling a local function to perform data information processing, for example, if the pictures of the database have parameter marks on whether the pictures contain flowers when being stored, the pictures with the parameter marks can be obtained by using local function query. The above examples are for illustration only, and many methods for implementing the above processes will be apparent to those skilled in the art, which are not described in detail in this application.

The network access task generated by the server is written into the task management module and appears on the task list of the task management module. And the task management module sequentially executes the tasks on the task list, caches the processing result of each task and informs the server of the processed state information. After the network access task of 'inquiring and acquiring all pictures containing flowers in the database' is completed, a plurality of pictures containing flowers are taken out from the database, and the task management module caches the pictures and informs the server that the network access task is completed.

Meanwhile, due to the fact that the task waiting time is set, if the task management module finishes inquiring the pictures containing the flowers in the database and obtains the pictures containing the flowers and patterns in the database when the task waiting time is over, the server side can directly awaken the thread because the processing thread of the RPC access request initiated by the client side for the first time is still waiting at the moment, and the obtained pictures containing the flowers are fed back to the client side to finish the response. If the task management module does not finish querying the database containing the flower pictures when the task waiting time is over, the server end also feeds back task identifiers corresponding to the network access task of querying and acquiring all the pictures containing the flowers in the database to the client end, and when the client end initiates an RPC call request again through the task identifiers, the server end directly queries the state and the result of the corresponding network access task according to the task identifiers, and the task of querying and acquiring all the pictures containing the flowers in the database cannot be generated again.

After receiving an RPC access request initiated by a client, the task responder based on RPC access can generate a corresponding network access task, so as to execute the network access task. Meanwhile, a task waiting time is preset, and if the processing of the network access task is completed and a corresponding result is obtained within the task waiting time, the RPC access request can be responded in time; if the network access task is not processed within the task waiting time, the task identifier of the network access task corresponding to the RPC access request is fed back to the client and then the current RPC access process is ended. Therefore, the client can know the processing progress of the network access task in time and obtain the corresponding service processing result in time, the RPC access efficiency is improved, and unnecessary task waiting time of the client is reduced.

In an embodiment, as shown in fig. 5, an RPC access request initiated by a client carries an objective function identifier, where the objective function is used to perform corresponding service processing according to a network access task, and the method includes:

step S502, according to the target function identification, searching a target function corresponding to the target function identification from a server-side local function library.

It should be noted that in the field of remote network access, RPC is to call a remote function located at a server end as a local function. Therefore, in this process, the client needs to specify the function that the client needs to call at the remote end (server end), and also needs to inform the server end of the information of the function that the client needs to call when initiating the RPC call.

Specifically, the RPC access request sent by the client carries the relevant information of the target function, that is, the target function identifier in this embodiment, and the server can find the target function corresponding to the RPC access request in the local function library according to the target function identifier.

Step S504, according to the network access task, the objective function is called to execute the business processing corresponding to the objective function.

Specifically, after the server determines that the client needs to call the local target function, the server needs to call the specific target function according to the specific content of the network access task to execute and complete the network access task, and finally obtains the corresponding service processing result.

In the embodiment, the client can timely know the processing progress of the network access task and timely obtain the corresponding service processing result, so that the RPC access efficiency is improved, and the unnecessary task waiting time of the client is reduced. By the mode, the RPC access efficiency can be greatly improved, unnecessary task waiting time is reduced for the RPC process which can obtain the access result in time, smooth completion of the RPC access is guaranteed by feeding back the task identifier for the RPC process which cannot obtain the access result in time, the access request does not need to be submitted repeatedly, simplicity and reliability are realized, the task waiting time and the network request cost of the client are reduced, and the network access efficiency is effectively improved.

In one embodiment, after a network access task is generated at a server side, task management is performed on the network access task through a task management module, and after the server side performs corresponding service processing according to the network access task, a service processing result of the network access task is cached through the task management module.

For example, in a period of time, the server receives A, B, C, D, E requests of five network access tasks, and in order to improve the efficiency of processing the network access tasks, the task management module needs to sort the network access tasks according to a certain rule, determine the execution sequence of each task, and inform the server in time after the task is executed, so that the server can perform the next processing. For example, if the task management module finally determines that the processing sequence of the network access task is A, D, C, B, E, the sequence of the task management module executing the task is A, D, C, B, E first. After each task is executed, the task management module also caches a service processing result corresponding to each task and notifies the server of the completed state of the task.

In the embodiment, by setting the task management module, the network access task of the server can be managed, the execution condition of the network access task of the server can be obtained in time, and the problem that the RPC access request of the client fails due to the fact that the task execution is disordered due to too many network access tasks of the server is avoided. Meanwhile, the threads of the task management module for executing the network access task can be independently carried out from the RPC request processing threads, occupation cannot occur between the threads, and the RPC request processing efficiency is further improved.

In one embodiment, the task management module performs task management on the network access task, and includes: queuing the network access tasks according to the priority or time sequence through the task management module to obtain a task queue; sequentially executing the network access tasks according to the task queue through the task management module; caching the service processing result corresponding to each network access task through the task management module

It should be noted that, the process of managing the network access task by using the task management module generally needs to follow a certain rule. One of the important roles of the task management module is that the server may receive multiple RPC access requests from the same or different clients within a period of time, and manage the response sequence of these access requests.

For example, a common response rule includes client priority ranking, the server sets priorities for different clients, and when receiving an RPC access request sent by a higher priority client, the server performs the RPC access request in advance, and performs the RPC access request later on for a lower priority client. Or, the RPC access requests from the client are sorted according to the time when the server receives the RPC access requests, and the RPC access requests received first are executed first. Or judging the execution order according to the category of the RPC access request, and the like. Different server sides may have different response rules according to their own characteristics, server properties, and other factors, or may be a combination of multiple response rules, which is not specifically limited in this embodiment.

In one embodiment, after the task queue is obtained, the task management module needs to sequentially execute the network access tasks according to the sequence of the task queue, and the specific representation form of the task management module may be, but is not limited to, calling a specific function to perform specific data processing and the like. After the network access task is executed, the task management module needs to cache the obtained service processing result, and feed back the task state to the server in time, so that the server can perform the next work, for example, feed back the task state or feed back the service processing result to the client. Through the task management module, the network access tasks received by the server end can be processed in order, and the processing efficiency of the network access tasks of the server end is improved.

In the embodiment, the service processing result is cached, so that the space of the server is not occupied additionally, the server side can feed the result back to the client side more conveniently, and the response efficiency of the RPC access request is further improved.

In one embodiment, the feeding back the service processing result to the client in response to the RPC access request includes: through the task management module, after the caching of the service processing result of the network access task of the server is completed, the processing thread of the RPC access request initiated by the client is actively awakened, and the service processing result is actively fed back to the client through the processing thread.

Specifically, in the process of managing the network access task by using the task management module, although the task waiting time is set, if the service processing result can be fed back to the client at the first time when the service processing result is obtained, the response efficiency of the RPC access request can be further improved. Therefore, the task management module preferably actively wakes up the client to initiate the processing thread of the RPC access request after the service processing result is cached.

In the embodiment, the server side can actively feed back the service processing result to the client side in time within the task waiting time, and does not need to wait for initiating a query instruction to obtain the result.

In one embodiment, the task latency includes a fixed duration task latency and a non-fixed duration task latency; the task waiting time with the fixed time length is used for indicating the server end to carry out task response within the task waiting time with the fixed time length from the moment of receiving the RPC access request; the task waiting time with the non-fixed duration is used for indicating the server to carry out task response at any time specified by the client, the server or the task management module.

Specifically, different server-side data structure rules are different, and different client-side initiated RPC access requests have different characteristics, so that different data protocols adopted for data interaction between the client-server sides are different, and thus the server-side response rules for the client-side RPC access requests are different. Therefore, different task waiting times are correspondingly set in the embodiment. The task waiting time of the embodiment is set according to the characteristics of the client and the server, and includes various expressions, such as task waiting time with fixed time length or non-fixed time length.

The fixed-time task waiting time is used for indicating the server-side task waiting time to perform task response within a fixed time period from the time when the RPC access request is received, that is, the server side has an explicit feedback time, for example, the server needs to perform feedback within 10s, 20s or 30s of task waiting time when the RPC access request is received.

The task waiting time with non-fixed duration also has various expression forms, and can be set by a client or a server or a task management module or can be set independently. For example, the client specifies that the feedback time of the RPC access request is 5s, and then the task waiting time of the access request is 5 s; or the task waiting time is not specified, and the server or the task management module requires the server to perform feedback at a specified time (for example, every 5s, or every 1 minute, or other specified forms) according to its own data rule or other parameters.

The aim of the method is to improve the response efficiency of the RPC access request of the client to the maximum extent and reduce the negative effect of the timely response to the server as much as possible no matter the task waiting time is fixed or the task waiting time is not fixed.

In an embodiment, when the task state information indicates that the network access task is not completed, the task state information is used to instruct the client to continuously initiate a task query instruction until a service processing result corresponding to the network access task is obtained.

Because the server cannot guarantee that each RPC access request initiated by the client can obtain a response within a task waiting time, the server can send a task identifier to the client when a service processing result corresponding to the RPC access request cannot be fed back to the client in time. The client receiving the task identification means that the task is not completed and the result needs to be queried later.

Therefore, in order to obtain the corresponding service processing result as soon as possible, in the above embodiment, the client may continuously initiate the task query instruction after receiving the task identifier until obtaining the corresponding service processing result. The process of the client initiating the task query instruction can be according to a certain time interval or according to the self requirement. For example, the client may perform query every 5 seconds, or may initiate a task query instruction to the server when the client needs a service processing result corresponding to the RPC access request.

In the process, because the processing thread of the RPC access request initiated in advance is already finished, the task management module cannot actively wake up the thread to realize active feedback of the service processing result, but the task management module can actively feed back the task processing state (i.e. the state of task processing completion) to the server side and cache the service processing result to the local.

In the technical solution of the above embodiment, after the task is submitted, a task waiting time (timeout _ WAIT) mechanism is used to try to WAIT for the task processing result. Because most RPC access requests can be completed within the waiting time limit (several seconds to ten seconds), the client can immediately obtain the result when the RPC call returns a response, and even if the task execution time is too long due to accidental factors, the client can obtain task identification (such as task ID or other identification forms) within an expected time range, so that the long-time waiting which is difficult to expect is avoided, and the probability of network timeout of the client is greatly reduced.

And the task management module actively awakens the processing thread of the RPC access request when the task execution is finished, so that the result can be timely returned to the client, and the extra task waiting time is avoided. Meanwhile, the task management module provides a function of temporarily storing the task processing result, and each participant capable of supporting the RPC access request can acquire the processing result of the task by using the task ID, so that the response efficiency of the server to the RPC access request is further improved.

Specifically, as shown in the timing diagram of fig. 6, which is a specific embodiment, the task response method provided by the present application may be applied to various network access processes based on RPC access.

As shown in fig. 6, according to the time sequence, the client first initiates a first RPC call, which includes a specific task content request, for example, a specific function is called to process some specific data, and a corresponding service processing result is required to be obtained. And after receiving the RPC call, the server generates a network access task and submits the network access task to the task management module, and then the task management module waits for the task waiting time to complete the network access task. And after the network access task is processed, obtaining a corresponding service processing result, temporarily storing the service processing result by the task management module, and then awakening the RPC request processing thread of the server, wherein the server responds to the RPC request processing thread initiated by the client according to the cached service processing result.

It should be noted that the server does not only respond to the RPC request processing thread initiated by the client after the task management module completes the network access task processing, but the server still responds to the RPC request processing thread initiated by the client if the task management module does not complete the network access task processing after the task waiting time is over, and the content of the response is the task identifier corresponding to the network access task.

For the client, after receiving the response content from the server, the client still needs to identify the received response content. If the received service processing result is the service processing result, the RPC call request can be ended, but if the received task identifier is the task identifier, it means that the server does not obtain the service processing result corresponding to the network access task at this time, and the client still needs to wait and then query again.

After a period of time, the client initiates the RPC call again. The method is different from the first initiated RPC call, and the specific content of the request in the RPC call is the processing result corresponding to the network access task corresponding to the task identifier. The server side directly queries according to the task identifier without generating a specific network access task like the first RPC call. As mentioned above, after the task processing module executes the network access task, the task processing module caches the obtained service processing result and notifies the server. Therefore, the server only needs to query the information fed back by the task management module to know whether the network access task queried by the client is completed or not, and feeds back the information according to the RPC call subsequently initiated by the client.

Therefore, in the technical scheme of fig. 6, the client only proposes the network access task that the server specifically needs to execute in the RPC request initiated for the first time, and the server only needs to generate the network access task in the RPC call initiated by the client for the first time. By setting the task waiting time, the client can obtain the service processing result corresponding to the request within the task waiting time or obtain the task identifier of the network access task corresponding to the request. That is, the client receives a valid feedback regardless of whether the task scheduling engine can perform the network access task within the task waiting time. If the received feedback is the task identifier, the client only needs to request to obtain the service processing result of the network access task corresponding to the task identifier in the subsequent RPC call, and does not need to request the server to generate the network access task again. Through the design, the response efficiency of the client is greatly improved, and the pressure of the server is also reduced.

It should be understood that although the various steps in the timing diagrams or flowcharts of fig. 2-6 are shown in order as indicated by the arrows, the steps are not necessarily performed in order as indicated by the arrows. The steps are not performed in the exact order shown and described, and may be performed in other orders, unless explicitly stated otherwise. Moreover, at least some of the steps in fig. 2-6 may include multiple steps or multiple stages, which are not necessarily performed at the same time, but may be performed at different times, which are not necessarily performed in sequence, but may be performed in turn or alternately with other steps or at least some of the other steps.

In one embodiment, as shown in fig. 7, there is provided a RPC access based task response apparatus 700, including: a task execution module 701, a determination module 702, and a feedback module 703, wherein:

the task execution module 701 is used for receiving an RPC access request initiated by a client, generating a network access task according to the RPC access request, and performing corresponding service processing according to the network access task;

a determining module 702, configured to determine a task waiting time corresponding to the network access task;

a feedback module 703, configured to obtain a corresponding service processing result when the network access task is completed within the task waiting time, and feed back the service processing result to the client in response to the RPC access request;

the feedback module 703 is further configured to create a corresponding task identifier for the network access task when the network access task is not completed within the task waiting time, and feed back the task identifier to the client in response to the RPC access request; the fed-back task identifier is used for indicating the client to inquire the task state corresponding to the network access task based on the task identifier;

the feedback module 703 is further configured to respond to a task query instruction initiated by the client, query and feed back task state information of a corresponding network access task according to a task identifier carried in the task query instruction.

In one embodiment, in the task execution module, the RPC access request carries an objective function identifier, and the objective function is used for performing corresponding service processing according to the network access task, and includes:

the searching module is used for searching a target function corresponding to the target function identifier from a server-side local function library according to the target function identifier;

and the execution module is used for calling the target function according to the network access task so as to execute the service processing corresponding to the target function.

In one embodiment, the system further includes a task management module, configured to perform task management on the network access task through the task management module after the server generates the network access task, and cache a service processing result of the network access task through the task management module after the server performs corresponding service processing according to the network access task.

In one embodiment, the task management module performs task management on the network access task, and includes:

and the task queue module is used for queuing the network access tasks according to the priority or time sequence through the task management module to obtain a task queue.

And the task execution module is used for sequentially executing the network access tasks according to the task queue through the task management module.

And the task cache module is used for caching the service processing result corresponding to each network access task through the task management module.

and the awakening module is used for actively awakening the processing thread of the RPC access request initiated by the client after the business processing result of the network access task of the server is cached through the task management module, and actively feeding the business processing result back to the client through the processing thread. .

After receiving an RPC access request initiated by a client, the task response device based on RPC access can generate a corresponding network access task, thereby executing the network access task. Meanwhile, a task waiting time is preset, and if the processing of the network access task is completed and a corresponding result is obtained within the task waiting time, the RPC access request can be responded in time; if the network access task is not processed within the task waiting time, the task identifier of the network access task corresponding to the RPC access request is fed back to the client and then the current RPC access process is ended. Therefore, the client can know the processing progress of the network access task in time and obtain the corresponding service processing result in time, the RPC access efficiency is improved, and unnecessary task waiting time of the client is reduced.

For specific limitations of the RPC access based task response device, refer to the above limitations of the RPC access based task response method, which are not described herein again. The modules in the RPC access-based task response device can be wholly or partially implemented by software, hardware and a combination thereof. The modules can be embedded in a hardware form or independent from a processor in the computer device, and can also be stored in a memory in the computer device in a software form, so that the processor can call and execute operations corresponding to the modules.

As shown in fig. 8, in one embodiment, there is further provided a computer device, which includes a memory and a processor, where the memory stores a computer program, and the processor implements the steps in the method embodiments when executing the computer program. The computer device may be a server and may further include a processor, memory, and a network interface connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The nonvolatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of an operating system and computer programs in the non-volatile storage medium. The computer equipment is used for storing RPC access data, corresponding network access tasks, service processing results, task identifiers, task states and the like. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a RPC access based task response method.

It will be appreciated by those skilled in the art that the computer device configurations listed in the above embodiments do not constitute a limitation on the computer devices to which the present solution applies, and a particular computer device may include more or less components than those listed in the above embodiments, or may combine certain components, or have a different arrangement of components.

In one embodiment, a computer device is further provided, which includes a memory and a processor, the memory stores a computer program, and the processor implements the steps of the above method embodiments when executing the computer program.

In one embodiment, a computer-readable storage medium is provided, on which a computer program is stored, which computer program, when being executed by a processor, carries out the steps of the above-mentioned method embodiments.

It will be understood by those skilled in the art that all or part of the processes of the methods of the embodiments described above can be implemented by hardware related to instructions of a computer program, which can be stored in a non-volatile computer-readable storage medium, and when executed, can include the processes of the embodiments of the methods described above. Any reference to memory, storage, database or other medium used in the embodiments provided herein can include at least one of non-volatile and volatile memory. Non-volatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical storage, or the like. Volatile Memory can include Random Access Memory (RAM) or external cache Memory. By way of illustration and not limitation, RAM can take many forms, such as Static Random Access Memory (SRAM) or Dynamic Random Access Memory (DRAM), among others.

The technical features of the above embodiments can be arbitrarily combined, and for the sake of brevity, all possible combinations of the technical features in the above embodiments are not described, but should be considered as the scope of the present specification as long as there is no contradiction between the combinations of the technical features.

The above examples only express several embodiments of the present application, and the description thereof is more specific and detailed, but not construed as limiting the scope of the invention. It should be noted that, for a person skilled in the art, several variations and modifications can be made without departing from the concept of the present application, which falls within the scope of protection of the present application. Therefore, the protection scope of the present patent shall be subject to the appended claims.

Claims

1. A task response method based on RPC access is characterized by comprising the following steps:

determining task waiting time corresponding to the network access task;

2. The method of claim 1, wherein the RPC access request carries an objective function identifier, and the objective function is used for performing corresponding service processing according to the network access task, and includes:

3. The method of claim 1, further comprising:

4. The method of claim 3, wherein the task managing the network access task through a task management module comprises:

5. The method of claim 4, wherein the feeding back the service processing result to the client in response to the RPC access request comprises:

6. The method of any one of claims 1 to 5, wherein the task latency includes a fixed duration task latency and a non-fixed duration task latency;

7. The method according to any one of claims 1 to 5, wherein when the task state information indicates that the network access task is not completed, the task state information is used to instruct the client to continuously initiate a task query instruction until a service processing result corresponding to the network access task is obtained.

8. A RPC access based task response apparatus, the apparatus comprising:

9. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor, when executing the computer program, implements the steps of the method of any of claims 1 to 7.

10. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method of any one of claims 1 to 7.