CN112667371A - Asynchronous task processing method, device, equipment and storage medium - Google Patents
Asynchronous task processing method, device, equipment and storage medium Download PDFInfo
- Publication number
- CN112667371A CN112667371A CN202011421418.1A CN202011421418A CN112667371A CN 112667371 A CN112667371 A CN 112667371A CN 202011421418 A CN202011421418 A CN 202011421418A CN 112667371 A CN112667371 A CN 112667371A
- Authority
- CN
- China
- Prior art keywords
- interface
- callback
- asynchronous
- asynchronous task
- task
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
- 238000003672 processing method Methods 0.000 title abstract description 9
- 238000000034 method Methods 0.000 claims abstract description 63
- 238000012545 processing Methods 0.000 claims abstract description 36
- 238000012795 verification Methods 0.000 claims description 53
- 238000004590 computer program Methods 0.000 claims description 8
- 238000004806 packaging method and process Methods 0.000 claims description 4
- 238000012546 transfer Methods 0.000 claims description 4
- 230000008569 process Effects 0.000 description 16
- 238000010586 diagram Methods 0.000 description 6
- 230000003993 interaction Effects 0.000 description 6
- 230000001360 synchronised effect Effects 0.000 description 6
- 230000006870 function Effects 0.000 description 5
- 238000013507 mapping Methods 0.000 description 3
- 230000009286 beneficial effect Effects 0.000 description 2
- 238000005538 encapsulation Methods 0.000 description 2
- 230000008676 import Effects 0.000 description 2
- 230000007246 mechanism Effects 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 230000003190 augmentative effect Effects 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000000694 effects Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000010354 integration Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000006467 substitution reaction Methods 0.000 description 1
Images
Landscapes
- Computer And Data Communications (AREA)
Abstract
The application discloses a processing method, a processing device, processing equipment and a storage medium of an asynchronous task, and belongs to the technical field of networks. The method is applied to electronic equipment, a proxy component is arranged in the electronic equipment, callback data carried in a callback request is obtained through the proxy component, and the first asynchronous task is proved to be successfully warehoused under the condition that the first asynchronous task is obtained according to a first identifier in the callback request, wherein the first asynchronous task is generated before an asynchronous call request corresponding to the callback request is sent, and can be used for executing service processing logic during callback. At this point, the callback data may be passed into the first asynchronous task and the first asynchronous task with the callback data dispatched. The first asynchronous task is obtained through the first identifier, and therefore consistency of calling and callback can be guaranteed.
Description
Technical Field
The present application relates to the field of network technologies, and in particular, to a method, an apparatus, a device, and a storage medium for processing an asynchronous task.
Background
In a business scenario, an asynchronous service is usually involved, for example, a client calls a server, and the asynchronous service means that the client does not get feedback immediately after calling the server, for example, the feedback of the server may be obtained after a long time interval. In addition, in a business scenario of asynchronous service, a business of a client may need a callback of a server to process, for example, taking frozen account-reporting as an example, in a process that the client requests the server to report an account, the client may freeze a bill and then call the server, at this time, the server needs to call back to notify the client whether the bill can be reported, so that the client determines whether to unfreeze the bill.
Therefore, in a business scenario where an asynchronous service requires a callback, how to ensure consistency between a call and the callback becomes an urgent problem to be solved.
Disclosure of Invention
The embodiment of the application provides a processing method, a processing device, processing equipment and a storage medium of an asynchronous task, and can solve the problem that how to ensure the consistency of calling and callback becomes urgent in a service scene which needs asynchronous service and callback. The technical scheme is as follows:
in a first aspect, a method for processing an asynchronous task is provided, where the method is applied to an electronic device, and an agent component is provided in the electronic device, and the method is executed by the electronic device through the agent component, and includes:
obtaining callback data carried in the callback request;
if a corresponding first asynchronous task is obtained according to a first identifier carried in the callback request, transmitting the callback data into the first asynchronous task to obtain a second asynchronous task, wherein the first asynchronous task is generated before an asynchronous call request corresponding to the callback request is sent, and the first asynchronous task is used for executing service processing logic during callback;
dispatching the second asynchronous task.
As an example, the first identifier and the first asynchronous task are both generated before sending the asynchronous call request and are correspondingly stored in the client, and the first identifier is carried in the asynchronous call request when the client calls the server. Therefore, the first asynchronous task is matched through the first identifier, and therefore consistency of calling and callback can be guaranteed.
In one possible implementation manner of the present application, the method further includes:
if the interface calling triggering event is detected, determining whether the interface belongs to an asynchronous interface according to the interface type of the interface to be called;
if the interface belongs to an asynchronous interface, generating the first identifier and the first asynchronous task;
and correspondingly storing the first identification and the first asynchronous task.
Therefore, the first identifier and the first asynchronous task are correspondingly stored, so that when the client receives the callback request of the server, the matched first asynchronous task can be obtained according to the first identifier, and the calling of the client is consistent with the callback of the server.
In one possible implementation manner of the present application, the method further includes:
if the interface to be called corresponds to a verification label, obtaining verification interface information in the verification label, wherein the verification label is used for indicating that the interface needs to be verified;
calling the verification interface indicated by the verification interface information;
and if the interface can be called currently through the verification interface, sending the asynchronous calling request to the interface.
Before the interface is called, whether the interface can be called is determined by calling the verification interface, and the interface is called under the condition that the interface can be called. Therefore, the condition that the interface is not adjustable can be avoided, and the effectiveness of interface calling can be ensured.
In a possible implementation manner of the present application, before obtaining callback data carried in the callback request, the method further includes:
when a callback request corresponding to the asynchronous call request is received, if a queue corresponding to the first identifier exists, packaging callback data carried in the currently received callback request to obtain packaged data;
adding the obtained encapsulated data to a queue corresponding to the first identifier;
the obtaining callback data carried in the callback request includes:
and acquiring the encapsulated data from the queue corresponding to the first identifier to obtain the callback data.
The corresponding queue is set for the asynchronous call request, so that when the callback request is received for multiple times for the asynchronous call request, parameters carried in the callback request at each time can be packaged and then added into the queue, so that one packaged data can be obtained from the queue for processing when the callback processing is carried out, the same operation can be prevented from being executed for each callback, the purpose of duplicate removal is achieved, and the power consumption of a client side can be saved.
In one possible implementation manner of the present application, before the transferring the callback data into the first asynchronous task, the method further includes:
detecting whether the first asynchronous task has been executed;
said passing said callback data into said first asynchronous task, comprising:
and if the first asynchronous task is not executed, executing the operation of transmitting the callback data into the first asynchronous task.
Because multiple callbacks may exist for one asynchronous call request, after the first asynchronous task is acquired, whether the first asynchronous task is executed in other callback processes can be detected, and if the first asynchronous task is not executed, callback data is transmitted into the first asynchronous task, so that the same asynchronous task is prevented from being repeatedly executed.
In a second aspect, a processing apparatus for asynchronous tasks is provided, where the apparatus is applied to an electronic device, where a proxy component is disposed in the electronic device, and the method is performed by the processing apparatus through the proxy component, and includes:
the obtaining module is used for obtaining callback data carried in the callback request;
the transfer-in module is configured to transfer the callback data into a first asynchronous task to obtain a second asynchronous task if the corresponding first asynchronous task is obtained according to a first identifier carried in the callback request, where the first asynchronous task is generated before an asynchronous call request corresponding to the callback request is sent, and the first asynchronous task is used for executing a service processing logic during callback;
and the dispatching module is used for dispatching the second asynchronous task.
In one possible implementation manner of the present application, the obtaining module is further configured to:
if the interface calling triggering event is detected, determining whether the interface belongs to an asynchronous interface according to the interface type of the interface to be called;
if the interface belongs to an asynchronous interface, generating the first identifier and the first asynchronous task;
and correspondingly storing the first identification and the first asynchronous task.
In one possible implementation manner of the present application, the obtaining module is further configured to:
if the interface to be called corresponds to a verification label, obtaining verification interface information in the verification label, wherein the verification label is used for indicating that the interface needs to be verified;
calling the verification interface indicated by the verification interface information;
and if the interface can be called currently through the verification interface, sending the asynchronous calling request to the interface.
In a possible implementation manner of the present application, before the obtaining module obtains the callback data carried in the callback request, the obtaining module is further configured to:
when a callback request corresponding to the asynchronous call request is received, if a queue corresponding to the first identifier exists, packaging callback data carried in the currently received callback request to obtain packaged data;
adding the obtained encapsulated data to a queue corresponding to the first identifier;
the acquisition module is configured to:
and acquiring the encapsulated data from the queue corresponding to the first identifier to obtain the callback data.
In one possible implementation manner of the present application, before the transferring module transfers the callback data into the first asynchronous task, the transferring module is further configured to:
detecting whether the first asynchronous task has been executed;
the incoming module is to:
and if the first asynchronous task is not executed, executing the operation of transmitting the callback data into the first asynchronous task.
In a third aspect, an electronic device comprises a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the method according to any one of the first aspect when executing the computer program.
In a fourth aspect, there is provided a computer readable storage medium having stored thereon instructions which, when executed by a processor, implement the method of any of the first aspects.
In a fifth aspect, there is provided a computer program product containing instructions which, when run on a computer, cause the computer to perform the method of any of the first aspects.
It is understood that the beneficial effects of the second aspect to the fifth aspect can be referred to the related description of the first aspect, and are not described herein again.
The technical scheme provided by the embodiment of the application has the following beneficial effects:
the method comprises the steps of setting a proxy component in the electronic equipment, obtaining callback data carried in a callback request through the proxy component, and under the condition that a first asynchronous task is obtained according to a first identifier in the callback request, indicating that the first asynchronous task is successfully put in storage, wherein the first asynchronous task is generated before an asynchronous call request corresponding to the callback request is sent, and can be used for executing service processing logic during callback. At this point, the callback data may be passed into the first asynchronous task and the first asynchronous task with the callback data dispatched. The first asynchronous task is obtained through the first identifier, and therefore consistency of calling and callback can be guaranteed.
Drawings
In order to more clearly illustrate the technical solutions in the embodiments of the present application, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present application, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.
FIG. 1 is a flow diagram illustrating a method for processing an asynchronous task in accordance with an illustrative embodiment;
FIG. 2 is a flow diagram illustrating a method for processing an asynchronous task in accordance with another illustrative embodiment;
FIG. 3 is a block diagram illustrating a processing device for asynchronous tasks in accordance with an illustrative embodiment;
fig. 4 is a schematic structural diagram of an electronic device according to another exemplary embodiment.
Detailed Description
To make the objects, technical solutions and advantages of the present application more clear, embodiments of the present application will be described in further detail below with reference to the accompanying drawings.
It should be understood that reference to "a plurality" in this application means two or more. In the description of the present application, "/" indicates an OR meaning, for example, A/B may indicate A or B; "and/or" herein is merely an association describing an associated object, and means that there may be three relationships, e.g., a and/or B, which may mean: a exists alone, A and B exist simultaneously, and B exists alone. In addition, for the convenience of clearly describing the technical solutions of the present application, the terms "first", "second", and the like are used to distinguish the same items or similar items having substantially the same functions and actions. Those skilled in the art will appreciate that the terms "first," "second," etc. do not denote any order or quantity, nor do the terms "first," "second," etc. denote any order or importance.
Before describing the processing method of the asynchronous task provided in the embodiment of the present application in detail, an execution main body related to the embodiment of the present application is described first.
As an example, the processing method of the asynchronous task provided in the embodiment of the present application may be executed by an electronic device. An RPC (Remote Procedure Call) agent (Proxy) framework may be provided in the electronic device, and may be, for example, a Java component framework developed based on Java (e.g., Java8) language. The RPC proxy framework can also be understood as an API (Application Programming Interface) component package that facilitates integration, such as may be used for integrating proxy components, so that the electronic device can perform proxy operations such as Interface calls through the proxy components. As an example, the electronic device may include, but is not limited to, a Mobile phone, a tablet Computer, an AR (Augmented Reality)/VR (Virtual Reality) device, a notebook Computer, a UMPC (Ultra-Mobile Personal Computer), a netbook, and a PDA (Personal Digital Assistant), which are not limited thereto.
After the execution bodies related to the embodiments of the present application are described, the following describes in detail a processing method for an asynchronous task provided by the embodiments of the present application with reference to the drawings. Referring to fig. 1, fig. 1 is a flowchart illustrating a processing method of an asynchronous task according to an exemplary embodiment, which is described herein as an example of an interaction between a client and a server, where the client may be the electronic device, and the client may execute the processing method of the asynchronous task through a proxy component, and the method may include the following steps:
step 101: and if the interface calling triggering event is detected, determining whether the interface belongs to the asynchronous interface according to the interface type of the interface to be called.
As an example, the interface invocation triggering event may be triggered by a user through a client, or may also be triggered automatically by the client, which is not limited in this embodiment of the application.
When an interface call triggering event of the interface is detected, it indicates that the client needs to call the interface, and the interface is, for example, a remote interface of the server. In this case, the interface type of the interface to be called may be queried, and then, according to the interface type of the interface to be called, it may be determined whether the interface to be called belongs to an asynchronous interface, so as to determine whether the asynchronous service needs to be executed.
For example, different interfaces may each be correspondingly provided with an annotation type (eventeapi), which may be used to indicate whether the corresponding interface belongs to an asynchronous interface or a synchronous interface. Therefore, whether the interface to be called belongs to the asynchronous interface can be determined according to the annotation type of the interface to be called.
In some embodiments, the interface called by the write operation is generally an asynchronous interface, the interface called by the read operation is generally a synchronous interface, illustratively, the asynchronous interface generally includes a write execution interface and the like, and the synchronous interface includes an authentication interface, a rollback interface, a read execution interface and the like.
As an example, if the interface to be called does not belong to an asynchronous interface, i.e. the interface to be called belongs to a synchronous interface, the client may call the interface directly through the proxy component. Illustratively, if the interface is a remote interface of the server, the client may invoke the remote interface through the proxy component, thereby implementing remote invocation of the server. As another example, if the interface to be called belongs to an asynchronous interface, the client performs the following operation of step 102.
In the embodiment of the present application, if the interface call fails, the proxy component in the client may perform a rollback operation, that is, the proxy component attempts to call the interface again until the call is successful or the number of attempts reaches a certain number of thresholds, so as to ensure that the interface is successfully called as much as possible, that is, the success rate of the interface call may be ensured as much as possible by the proxy component in the embodiment of the present application.
The number threshold may be set by a user according to actual needs, or may be set by a default of the client, which is not limited in the embodiment of the present application.
Step 102: and if the interface belongs to the asynchronous interface, generating a first identifier and a first asynchronous task.
For example, if the interface belongs to an asynchronous interface, it means that the client does not get feedback immediately after calling the interface, that is, the server does not call back the client immediately. In this case, the client may generate the first identifier and the first asynchronous task, where the first asynchronous task is used to execute the service processing logic during callback, that is, the first asynchronous task may be used by the client to execute corresponding service processing after the server has called back the client.
Step 103: and storing the first identification corresponding to the first asynchronous task.
The client correspondingly stores the first identifier and the first asynchronous task, so that a subsequent client can inquire the first asynchronous task based on the first identifier after receiving the callback of the server and realize the callback of the service based on the first asynchronous task.
In addition, the client generates an asynchronous call request to call the interface through the asynchronous call request, namely, the call to the server is realized through the asynchronous call request.
In one embodiment, the client may call an afterInvoke method of the RPCCommonClientproxy class, which may decide whether to generate the job and task according to the annotation type of the interface, such as when the annotation type of the interface indicates that the interface is an asynchronous interface. Wherein jobs and task are parent-child relationships, as shown in FIG. 2, jobs can generate task. As an example, the joba may be determined to be an asynchronous call request, that is, the jobb includes the first identifier, and the task is the first asynchronous task.
Further, after generating the task, the state of the task may be set to a suspended state, and for example, the client may set the state of the task to the suspended state by calling the produceTaskToQueue method.
As an example, the job includes a first identifier, and the task includes a second identifier, such as the job id of the first identifier and the task id of the second identifier. In this case, the implementation manner of correspondingly storing the first identifier and the first asynchronous task may be: and storing the jobs and the task, and establishing a mapping relation between the first identifier and the second identifier.
As an example, the job and the task may be stored in a cache, and the job and the task may be stored in a database, and exemplarily, the Map may be used as the cache. Therefore, when the job and the task need to be acquired, the job and the task in the database can be preferentially acquired from the cache, and when the job and the task are not read in the cache, the job and the task in the database are stored in the cache and are read from the cache again. Therefore, the jobs and the tasks are stored in the cache and the database, the effectiveness of data storage can be guaranteed, the data can be preferentially read from the cache in the reading process, and the reading speed of the jobs and the tasks can be improved.
In addition, when the task and the job are updated, the cache is firstly cleared, then the database is updated, and the cache is cleared for the second time. That is, the data in the cache is cleared first, then the data in the database is updated, and in order to ensure that the old data in the cache is indeed cleared, the data in the cache can be cleared again.
It should be noted that the storage manner of the data can be configured by the configuration file, that is, several copies of the data need to be stored and stored in the data can be configured by the configuration file. Illustratively, the configuration file may be a file in xml format.
In addition, after the client generates the first identifier and the first asynchronous task, in addition to storing the first identifier corresponding to the first asynchronous task, an asynchronous call request may be sent to the server to execute the interface call, which may be implemented by an execute method. As an example, the asynchronous call request may carry a first identifier, and may also carry interface information of an interface to be called, where the interface information may be, for example, an interface identifier of the interface to be called, so that the server may know which interface the client calls. Further, the asynchronous call request may also carry other parameters, for example, when the account reporting interface is called, some data in the document may also be carried, for example, a credit amount that needs to be reported, and the like.
In some embodiments, some interfaces may need to be verified before being called, and in implementation, if the interface to be called corresponds to the verification tag, the verification interface information in the verification tag is obtained, and the verification tag is used to indicate that the interface needs to be verified. And calling the verification interface indicated by the verification interface information, and if the verification interface determines that the interface can be called currently, sending an asynchronous calling request to the interface.
The authentication interface information may be used to uniquely indicate the corresponding authentication interface, and may be, for example, an interface identifier of the authentication interface.
If the interface to be called corresponds to the verification tag, it is indicated that whether the interface can be called currently needs to be verified before the interface is called, so the client can obtain the verification interface information of the verification tag and then call the verification interface indicated by the verification interface information, thereby inquiring whether the interface can be called currently. Generally, the calling of the verification interface is a synchronous interface, that is, after calling the verification interface, the client can obtain a verification result, and the verification result is used for indicating whether the interface needing to be verified can be called currently.
In one embodiment, the proxy component in the client may generate a proxy object through a create method of the RPCCommonClientProxy class, and the invoke method of the proxy object may implement the interface verification, interface call, and rollback processes of the embodiment of the present application.
So far, the operations executed before the client sends the asynchronous call request to the server and sends the asynchronous call request have been introduced in the embodiment of the present application, that is, in the asynchronous service, when determining that the interface to be called is an asynchronous interface, the client generates and correspondingly stores the first identifier and the first asynchronous task, and when calling the interface, the client transmits the first identifier to the server. Then, the server needs to transmit the first identifier back when calling back the client, so that the client can search for the corresponding first asynchronous task according to the first identifier, and implement service call-back processing, for which, please refer to the following text.
Step 104: and obtaining callback data carried in the callback request.
The server side sends a callback request to the client side in the process of calling back the client side, and the client side receives the callback request through the proxy component. The callback request usually carries the first identifier and callback data, and for example, in an accounting system, the callback data may include indication information for indicating whether accounting is possible.
In order to implement callback logic for the service, the broker component obtains callback data in the callback request. As an example, the client may parse the received callback request, and obtain the carried first identifier and callback data therefrom.
As another example, the server may call back multiple times for an asynchronous call request, in which case the client receives the callback request corresponding to the asynchronous call request multiple times. As an example, when a client receives a callback request corresponding to an asynchronous call request, if a queue corresponding to a first identifier exists, the client encapsulates callback data carried in the callback request currently received to obtain encapsulated data, and adds the encapsulated data to the queue corresponding to the first identifier.
The queue corresponding to the first identifier may be created after the callback request corresponding to the asynchronous call request is received for the first time. When the client receives the callback request corresponding to the asynchronous call request, the client can encapsulate the callback parameter carried in the callback request currently received, for example, to encapsulate the callback parameter into a callback task. And if the queue corresponding to the first identifier exists, storing the callbacktask obtained after encapsulation into the queue corresponding to the first identifier, such as the queue corresponding to the jobID.
Certainly, if the queue corresponding to the first identifier does not exist, the client creates the queue corresponding to the first identifier, and then stores the callback task obtained after encapsulation into the queue corresponding to the first identifier.
As an example, in the process of storing the callback task to the queue corresponding to the first identifier, the callback task may be stored in the cache and the database, that is, a queue corresponding to the first identifier may be stored in the cache, and a queue corresponding to the first identifier may also be stored in the database.
If the client has the queue corresponding to the first identifier, the specific implementation of obtaining the callback data carried in the callback request may include: and acquiring the encapsulated data from the queue corresponding to the first identifier to obtain the callback data. For example, a callback task is obtained from the queue corresponding to the jobID, thereby obtaining callback data.
It should be noted that, since there may be multiple callback tasks for the same jobID, there may also be callbacks after the first received callback task is executed, so that the queue corresponding to the first identifier may last for a period of time, and if no callback request is received within the last period of time, the queue corresponding to the first identifier may be destroyed.
It is worth mentioning that, in the embodiment of the present application, by setting a corresponding queue for an asynchronous call request, adding callback data of multiple callbacks for the asynchronous call request to the queue, and then obtaining a group of callback data from the queue to perform subsequent service callback processing, it is possible to avoid repeatedly performing multiple service callback processing on the same callback, so as to achieve the purpose of deduplication, thereby saving the operation power consumption of the client.
Step 105: and acquiring a corresponding first asynchronous task according to the first identifier, wherein the first asynchronous task is generated before an asynchronous call request corresponding to the callback request is sent.
As an example, the first identifier and the second identifier have a mapping relationship, in which case, the corresponding second identifier may be determined according to the first identifier and the mapping relationship, and then the first asynchronous task may be determined according to the second identifier. Since the first identifier exists in the joba and the second identifier exists in the task, acquiring the first asynchronous task according to the first identifier can also be understood as acquiring the task according to the joba.
In implementation, when the client receives a callback request of the server, the first asynchronous task corresponding to the first identifier may not be warehoused. That is, the client may or may not acquire the corresponding first asynchronous task according to the first identifier.
If the corresponding first asynchronous task is not acquired according to the first identifier, it is stated that the jobs and the task are not stored in the warehouse yet, in this case, the client may start a waiting mechanism, exemplarily, when the jobs or the task is not acquired, the client may wait for a preset duration and then try to acquire again, and if the jobs or the task is not acquired, the client may continue to wait for the preset duration and then try to acquire again, and so on, the preset number of times may be tried according to this manner. If the job and task are acquired during the waiting for retry, the client performs the following operation of step 106. If the job and the task are not obtained in the process of waiting for retry again, possibly resulting in that the service logic called back by the server cannot be processed, an exception log can be recorded for the task so as to facilitate subsequent manual exception query. As an example, the process may be performed by the callacktaskqueue. configjobandtastkask isready thermoexecute method in the RPC proxy framework.
The preset time duration may be set by a user according to an actual requirement, or may also be set by a default of the client, for example, the preset time duration may be 2s, which is not limited in the embodiment of the present application.
The preset number of times may be set by a user according to actual needs, or may also be set by a default of the client, for example, the preset number of times may be 7, which is not limited in the embodiment of the present application.
In addition, after the client successfully acquires the first asynchronous task, the client can modify the state of the first asynchronous task, and update the first asynchronous task from the suspended state to the completed state, that is, update the task state from the suspended state to the completed state, so that whether the first asynchronous task is executed or not can be determined through the state.
Step 106: and if the corresponding first asynchronous task is obtained according to the first identifier, transferring callback data into the first asynchronous task to obtain a second asynchronous task.
As an example, the callback data may include a task result executed by the server in response to the call of the client, and for example, if the server is an accounting system, the callback data may include indication information indicating whether accounting is possible. Further, the callback data may also include parameters carried by the client when sending the asynchronous call request, such as a quota in the document, creator information, and the like.
If the corresponding first asynchronous task can be acquired according to the first identifier, it is stated that the callback logic can be executed, so that the proxy component in the client may transmit the callback data into the first asynchronous task after acquiring the first asynchronous task, illustratively, transmit the callback data in the callback task into the task.
In some embodiments, after the waiting mechanism is started, the server may call back many times in some cases, for example, for an account-reporting system, when the process node may skip directly when the approvers are the same, the server may call back twice in a short time. If the job and the task cannot be normally acquired after the callback of the first server returns, if the job and the task are successfully stored in the waiting time period, the job and the task can be normally acquired after the callback of the second server returns, then the client can dispatch the second asynchronous task according to the method. Therefore, the method can avoid dispatching for the same asynchronous task for multiple times, and saves the power consumption of the client.
Step 107: and dispatching the second asynchronous task.
As an example, the client may trigger the dispatch of the second asynchronous task via the updatejob method of the callback class. Illustratively, the client may wake up the RPCTaskScheduler thread by this, notifyal () trigger, and the RPCTaskScheduler thread may dispatch the second asynchronous task through an EventBus (event bus) after acquiring the second asynchronous task to be dispatched according to a first-in first-out logic.
As an example, event information is included in the first asynchronous task, from which it can be determined to whom the second asynchronous task needs to be served, i.e. to which listening object. Correspondingly, a listener is preset in the service code to monitor the second asynchronous task dispatched by the agent component through a monitoring object in the listener, and corresponding service callback logic is executed according to the dispatched second asynchronous task. For example, an event that submits a document is intercepted by the intercepting object WorkFlowStartListenerServer. When the dispatched second asynchronous task is detected, the client executes a listen method, and the listen method can start the service processing logic based on the second asynchronous task.
In the embodiment of the present application, for the same service data (such as an account statement or a contract), the interaction operations between the client and the server are ordered, so that the client is required to control that one interaction is completed before the next interaction is allowed to be initiated, for example, the client initiates the next interaction after receiving a callback and dispatching a second asynchronous task, so as to ensure the accuracy of the service data.
In an example of the present application, the proxy component provided in the embodiment of the present application may record a proxy log for each proxy interface, where the proxy log includes an asynchronous interface proxy log and/or a synchronous interface proxy log, in addition to performing the above method. For example, the proxy log may include a request log, a response log, a callback log, an error log, and the like, and each operation from the beginning to the end of the service may be recorded through the proxy log, that is, the operation of the whole life cycle of the service may be recorded, for example, the number of calls of each proxy interface may be recorded.
Illustratively, referring to fig. 2, after sending the asynchronous call request, the client generates a corresponding log, and in addition, after dispatching the second asynchronous task, the client may also generate a corresponding log.
As an example, the proxy log generated in the embodiment of the present application may be stored in a database, and the proxy log may be written in mongoDB, for example. That is, mongoDB can be deployed and started in a database in advance, and the mongoDB storage proxy log can be configured and used through a configuration file, so that when the proxy log is generated, a client stores the proxy log into the mongoDB. As an example, the proxy log may be written using the AsynServicelmpl method, by which the proxy log may be asynchronously written.
It should be noted that, because there are many proxy log writes, for example, many writes may be made in one call of the proxy interface, if the mongoDB is not deployed or started, and the configuration file configures the storage of the proxy log using the mongoDB, a timeout may be waited for during the process of writing the proxy log, and if the number of the proxy logs is increased, the task of writing the proxy log may be increased. In this case, the system may not generate an exception, but may store the proxy log in the cache, and may generate a log of "work queue is full, add work to cache queue", that is, the log queue is full, and add the log to the cache queue.
In the embodiment of the application, a proxy component is arranged in the electronic device, callback data carried in the callback request is obtained through the proxy component, and the first asynchronous task is described to be successfully warehoused under the condition that the first asynchronous task is obtained according to a first identifier in the callback request, wherein the first asynchronous task is generated before an asynchronous call request corresponding to the callback request is sent, and can be used for executing service processing logic during callback. At this point, the callback data may be passed into the first asynchronous task and the first asynchronous task with the callback data dispatched. The first asynchronous task is obtained through the first identifier, and therefore consistency of calling and callback can be guaranteed.
It should be understood that, the sequence numbers of the steps in the foregoing embodiments do not imply an execution sequence, and the execution sequence of each process should be determined by its function and inherent logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.
Fig. 3 is a schematic diagram illustrating a structure of an asynchronous task processing device according to an exemplary embodiment, where the asynchronous task processing device may be implemented by software, hardware, or a combination of the two. The device is applied to electronic equipment, a proxy component is arranged in the electronic equipment, and the method is executed by the processing device through the proxy component and comprises the following steps:
an obtaining module 310, configured to obtain callback data carried in the callback request;
an import module 320, configured to, if a corresponding first asynchronous task is obtained according to a first identifier carried in the callback request, import the callback data into the first asynchronous task to obtain a second asynchronous task, where the first asynchronous task is generated before sending an asynchronous call request corresponding to the callback request, and the first asynchronous task is used to execute a service processing logic during callback;
a dispatching module 330, configured to dispatch the second asynchronous task.
In one possible implementation manner of the present application, the obtaining module 310 is further configured to:
if the interface calling triggering event is detected, determining whether the interface belongs to an asynchronous interface according to the interface type of the interface to be called;
if the interface belongs to an asynchronous interface, generating the first identifier and the first asynchronous task;
and correspondingly storing the first identification and the first asynchronous task.
In one possible implementation manner of the present application, the obtaining module 310 is further configured to:
if the interface to be called corresponds to a verification label, obtaining verification interface information in the verification label, wherein the verification label is used for indicating that the interface needs to be verified;
calling the verification interface indicated by the verification interface information;
and if the interface can be called currently through the verification interface, sending the asynchronous calling request to the interface.
In a possible implementation manner of the present application, before the obtaining module 310 obtains the callback data carried in the callback request, the obtaining module is further configured to:
when a callback request corresponding to the asynchronous call request is received, if a queue corresponding to the first identifier exists, packaging callback data carried in the currently received callback request to obtain packaged data;
adding the obtained encapsulated data to a queue corresponding to the first identifier;
the obtaining module 310 is configured to:
and acquiring the encapsulated data from the queue corresponding to the first identifier to obtain the callback data.
In one possible implementation manner of the present application, before the transferring module transfers the callback data into the first asynchronous task, the transferring module is further configured to:
detecting whether the first asynchronous task has been executed;
the inbound module 320 is to:
and if the first asynchronous task is not executed, executing the operation of transmitting the callback data into the first asynchronous task.
In the embodiment of the application, a proxy component is arranged in the electronic device, callback data carried in the callback request is obtained through the proxy component, and the first asynchronous task is described to be successfully warehoused under the condition that the first asynchronous task is obtained according to a first identifier in the callback request, wherein the first asynchronous task is generated before an asynchronous call request corresponding to the callback request is sent, and can be used for executing service processing logic during callback. At this point, the callback data may be passed into the first asynchronous task and the first asynchronous task with the callback data dispatched. The first asynchronous task is obtained through the first identifier, and therefore consistency of calling and callback can be guaranteed.
Fig. 4 is a schematic structural diagram of an electronic device according to an embodiment of the present application. As shown in fig. 4, the electronic apparatus 4 of this embodiment includes: at least one processor 40 (only one shown in fig. 4), a memory 41, and a computer program 42 stored in the memory 41 and executable on the at least one processor 40, the steps of any of the various method embodiments described above being implemented when the computer program 42 is executed by the processor 40.
The electronic device 4 may be a desktop computer, a notebook, a palm computer, a cloud server, or other computing devices. The electronic device may include, but is not limited to, a processor 40, a memory 41. Those skilled in the art will appreciate that fig. 4 is merely an example of the electronic device 4, and does not constitute a limitation of the electronic device 4, and may include more or less components than those shown, or combine some of the components, or different components, such as an input-output device, a network access device, etc.
The Processor 40 may be a Central Processing Unit (CPU), and the Processor 40 may be other general-purpose Processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA) or other Programmable logic device, a discrete Gate or transistor logic device, a discrete hardware component, or the like. A general purpose processor may be a microprocessor or the processor may be any conventional processor or the like.
The memory 41 may in some embodiments be an internal storage unit of the electronic device 4, such as a hard disk or a memory of the electronic device 4. In other embodiments, the memory 41 may also be an external storage device of the electronic device 4, such as a plug-in hard disk, an SMC (Smart Media Card), an SD (Secure Digital) Card, a Flash memory Card (Flash Card), or the like, provided on the electronic device 4. Further, the memory 41 may also include both an internal storage unit and an external storage device of the electronic device 4. The memory 41 is used for storing an operating system, an application program, a BootLoader (BootLoader), data, and other programs, such as program codes of the computer program. The memory 41 may also be used to temporarily store data that has been output or is to be output.
It should be noted that, for the information interaction, execution process, and other contents between the above-mentioned devices/units, the specific functions and technical effects thereof are based on the same concept as those of the embodiment of the method of the present application, and specific reference may be made to the part of the embodiment of the method, which is not described herein again.
It will be apparent to those skilled in the art that, for convenience and brevity of description, only the above-mentioned division of the functional units and modules is illustrated, and in practical applications, the above-mentioned function distribution may be performed by different functional units and modules according to needs, that is, the internal structure of the apparatus is divided into different functional units or modules to perform all or part of the above-mentioned functions. Each functional unit and module in the embodiments may be integrated in one processing unit, or each unit may exist alone physically, or two or more units are integrated in one unit, and the integrated unit may be implemented in a form of hardware, or in a form of software functional unit. In addition, specific names of the functional units and modules are only for convenience of distinguishing from each other, and are not used for limiting the protection scope of the present application. The specific working processes of the units and modules in the system may refer to the corresponding processes in the foregoing method embodiments, and are not described herein again.
The above-mentioned embodiments are only used for illustrating the technical solutions of the present application, and not for limiting the same; although the present application has been described in detail with reference to the foregoing embodiments, it should be understood by those of ordinary skill in the art that: the technical solutions described in the foregoing embodiments may still be modified, or some technical features may be equivalently replaced; such modifications and substitutions do not substantially depart from the spirit and scope of the embodiments of the present application and are intended to be included within the scope of the present application.
Claims (10)
1. The method for processing the asynchronous task is applied to an electronic device, wherein an agent component is arranged in the electronic device, and the method is executed by the electronic device through the agent component and comprises the following steps:
obtaining callback data carried in the callback request;
if a corresponding first asynchronous task is obtained according to a first identifier carried in the callback request, transmitting the callback data into the first asynchronous task to obtain a second asynchronous task, wherein the first asynchronous task is generated before an asynchronous call request corresponding to the callback request is sent, and the first asynchronous task is used for executing service processing logic during callback;
dispatching the second asynchronous task.
2. The method of claim 1, wherein the method further comprises:
if the interface calling triggering event is detected, determining whether the interface belongs to an asynchronous interface according to the interface type of the interface to be called;
if the interface belongs to an asynchronous interface, generating the first identifier and the first asynchronous task;
and correspondingly storing the first identification and the first asynchronous task.
3. The method of claim 1 or 2, wherein the method further comprises:
if the interface to be called corresponds to a verification label, obtaining verification interface information in the verification label, wherein the verification label is used for indicating that the interface needs to be verified;
calling the verification interface indicated by the verification interface information;
and if the interface can be called currently through the verification interface, sending the asynchronous calling request to the interface.
4. The method of claim 1, wherein before obtaining the callback data carried in the callback request, further comprising:
when a callback request corresponding to the asynchronous call request is received, if a queue corresponding to the first identifier exists, packaging callback data carried in the currently received callback request to obtain packaged data;
adding the obtained encapsulated data to a queue corresponding to the first identifier;
the obtaining callback data carried in the callback request includes:
and acquiring the encapsulated data from the queue corresponding to the first identifier to obtain the callback data.
5. The method of claim 4, wherein prior to said passing said callback data into said first asynchronous task, further comprising:
detecting whether the first asynchronous task has been executed;
said passing said callback data into said first asynchronous task, comprising:
and if the first asynchronous task is not executed, executing the operation of transmitting the callback data into the first asynchronous task.
6. An asynchronous task processing device applied to an electronic device, wherein an agent component is arranged in the electronic device, and the method is executed by the processing device through the agent component, and comprises:
the obtaining module is used for obtaining callback data carried in the callback request;
the transfer-in module is configured to transfer the callback data into a first asynchronous task to obtain a second asynchronous task if the corresponding first asynchronous task is obtained according to a first identifier carried in the callback request, where the first asynchronous task is generated before an asynchronous call request corresponding to the callback request is sent, and the first asynchronous task is used for executing a service processing logic during callback;
and the dispatching module is used for dispatching the second asynchronous task.
7. The apparatus of claim 6, wherein the acquisition module is further to:
if the interface calling triggering event is detected, determining whether the interface belongs to an asynchronous interface according to the interface type of the interface to be called;
if the interface belongs to an asynchronous interface, generating the first identifier and the first asynchronous task;
and correspondingly storing the first identification and the first asynchronous task.
8. The apparatus of claim 6 or 7, wherein the acquisition module is further configured to:
if the interface to be called corresponds to a verification label, obtaining verification interface information in the verification label, wherein the verification label is used for indicating that the interface needs to be verified;
calling the verification interface indicated by the verification interface information;
and if the interface can be called currently through the verification interface, sending the asynchronous calling request to the interface.
9. An electronic device comprising a memory, a processor and a computer program stored in the memory and executable on the processor, characterized in that the steps of the method according to any of claims 1 to 5 are implemented when the computer program is executed by the processor.
10. A computer readable storage medium having instructions stored thereon, wherein the instructions, when executed by a processor, implement the steps of the method of any of claims 1 to 5.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011421418.1A CN112667371A (en) | 2020-12-07 | 2020-12-07 | Asynchronous task processing method, device, equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202011421418.1A CN112667371A (en) | 2020-12-07 | 2020-12-07 | Asynchronous task processing method, device, equipment and storage medium |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN112667371A true CN112667371A (en) | 2021-04-16 |
Family
ID=75401479
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202011421418.1A Pending CN112667371A (en) | 2020-12-07 | 2020-12-07 | Asynchronous task processing method, device, equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN112667371A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113535439A (en) * | 2021-09-15 | 2021-10-22 | 北京奇虎科技有限公司 | Service request processing method, device, equipment and storage medium |
| WO2024037553A1 (en) * | 2022-08-16 | 2024-02-22 | 华为技术有限公司 | Lifecycle scheduling method and apparatus, and electronic device |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120260261A1 (en) * | 2011-04-07 | 2012-10-11 | Microsoft Corporation | Asynchronous callback driven messaging request completion notification |
| US20140053157A1 (en) * | 2012-08-16 | 2014-02-20 | Microsoft Corporation | Asynchronous execution flow |
| CN104866383A (en) * | 2015-05-29 | 2015-08-26 | 北京金山安全软件有限公司 | Interface calling method and device and terminal |
| US20160260040A1 (en) * | 2013-11-14 | 2016-09-08 | Huawei Technologies Co., Ltd. | Computer Device, Method, and Apparatus for Scheduling Business Flow |
| CN110287037A (en) * | 2019-05-20 | 2019-09-27 | 平安科技（深圳）有限公司 | Distributed intelligence API asynchronism callback method and device |
| CN110889075A (en) * | 2019-11-29 | 2020-03-17 | 苏州浪潮智能科技有限公司 | Data subscription implementation method and device |
-
2020
- 2020-12-07 CN CN202011421418.1A patent/CN112667371A/en active Pending
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20120260261A1 (en) * | 2011-04-07 | 2012-10-11 | Microsoft Corporation | Asynchronous callback driven messaging request completion notification |
| US20140053157A1 (en) * | 2012-08-16 | 2014-02-20 | Microsoft Corporation | Asynchronous execution flow |
| US20160260040A1 (en) * | 2013-11-14 | 2016-09-08 | Huawei Technologies Co., Ltd. | Computer Device, Method, and Apparatus for Scheduling Business Flow |
| CN104866383A (en) * | 2015-05-29 | 2015-08-26 | 北京金山安全软件有限公司 | Interface calling method and device and terminal |
| CN110287037A (en) * | 2019-05-20 | 2019-09-27 | 平安科技（深圳）有限公司 | Distributed intelligence API asynchronism callback method and device |
| CN110889075A (en) * | 2019-11-29 | 2020-03-17 | 苏州浪潮智能科技有限公司 | Data subscription implementation method and device |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113535439A (en) * | 2021-09-15 | 2021-10-22 | 北京奇虎科技有限公司 | Service request processing method, device, equipment and storage medium |
| WO2024037553A1 (en) * | 2022-08-16 | 2024-02-22 | 华为技术有限公司 | Lifecycle scheduling method and apparatus, and electronic device |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN107729139B (en) | Method and device for concurrently acquiring resources | |
| US20200133750A1 (en) | Methods, apparatus and computer programs for managing persistence | |
| CN112667414A (en) | Message queue-based message consumption method and device, computer equipment and medium | |
| CN110457556B (en) | Distributed crawler system architecture, method for crawling data and computer equipment | |
| CN112667371A (en) | Asynchronous task processing method, device, equipment and storage medium | |
| US10848595B2 (en) | Method and device for message sending and receiving based on a communication interface framework | |
| CN112596931B (en) | Cross-process communication method and device, electronic equipment and storage medium | |
| CN111405130B (en) | Voice interaction system and method | |
| CN110659104B (en) | Service monitoring method and related equipment | |
| CN112559476A (en) | Log storage method for improving performance of target system and related equipment thereof | |
| WO2022206253A1 (en) | Exception handling method and apparatus, device, and storage medium | |
| WO2023134247A1 (en) | Container management method and container management system | |
| CN113778714B (en) | Shared shear plate method and device compatible with Android for Linux | |
| CN112559290B (en) | Service call monitoring method, device, computer equipment and storage medium | |
| CN107102901B (en) | Task processing method and device | |
| CN114327404A (en) | File processing method and device, electronic equipment and computer readable medium | |
| CN115170152A (en) | Data distribution method, device, equipment and storage medium | |
| CN114764324A (en) | Enterprise resource planning system and integration method thereof | |
| CN113849287A (en) | Processing method and device of algorithm service, electronic equipment and storage medium | |
| CN109034768B (en) | Financial reconciliation method, apparatus, computer device and storage medium | |
| CN113779021A (en) | Data processing method, device, computer system and readable storage medium | |
| WO2022237570A1 (en) | Deadlock detection method, apparatus, and related device | |
| CN116302850B (en) | Linux socket connection event monitoring method and device | |
| CN114006927B (en) | Service message processing method and processing device thereof, electronic equipment and storage medium | |
| CN115774521A (en) | Data migration method, system, device and storage medium of PCIE SSD |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination |