CN102929698A - Task re-judgment method and system - Google Patents

Abstract

The present invention provides a method for judging the weight of a task, which includes: when the back end executes the task corresponding to the command identifier in the service request sent by the intermediate processor, recording the corresponding relationship between the execution status of the task and the serial number in the service request; When the backend judges that the execution state of the task corresponding to the command identifier in the service request is in execution or has been executed according to the sequence number in the service request sent by the intermediate processor, it refuses to execute the task again; the present invention also provides A task weight judgment system. According to the technical solution provided by the invention, the problem of repeated execution of the same task at the back end can be solved, and processing resources at the back end can be saved.

Description

A method and system for judging the weight of a task

【Technical field】

The invention relates to website development technology in the Internet field, in particular to a method and system for judging the weight of a task.

【Background technique】

At present, during the website development process, the front-end will send a service request to the intermediate processor, and the intermediate processor will forward the service request to the back-end. After receiving the service request, the back-end will directly process the service request and perform corresponding operations.

If the backend does not return a response to the service request to the intermediate processor in time, or the intermediate processor does not receive a response, for example, due to fluctuations or interruptions in the network, the intermediate server fails to send the service request to the backend, and the backend does not receive it. No response will be returned when the service request is received; or the task execution process corresponding to the service request is relatively complicated, the backend takes a long time to execute the task, and the response is not returned in time, or when the backend returns the response, the network fluctuates or is interrupted, and the backend does not A response is returned successfully. If the above situation occurs, the intermediate processor will consider that the service request has not been submitted successfully because it has not received the response returned by the backend, and will repeatedly submit the service request to the backend; if the backend is processing the same service request received before Or if the service request has been processed and the same service request is received at this time, the corresponding operation will be repeated, which will bring redundant processing burden to the back end and waste the processing resources of the back end. Moreover, for different services, the repeated execution of tasks by the backend will cause many problems. For example, if the service request for deducting money is submitted repeatedly, the backend will repeatedly perform the deduction of money, which will bring economic losses to users; For message service requests, the backend will repeatedly send messages to users, which will bring poor user experience to users.

【Content of invention】

The invention provides a method and system for judging the weight of a task, which can solve the problem of repeated execution of the same task at the back end and save processing resources at the back end.

Concrete technical scheme of the present invention is as follows:

According to a preferred embodiment of the present invention, a task weight judgment method, when the backend executes the task corresponding to the command identifier in the service request sent by the intermediate processor, records the corresponding relationship between the execution status of the task and the sequence number in the service request ;Also includes:

When the backend judges according to the serial number in the service request sent by the intermediate processor that the execution state of the task corresponding to the command identifier in the service request is in progress or completed, it refuses to execute the task again.

In the above method, the serial number is: after receiving the service request sent by the front end, the intermediate processor allocates a unique serial number for the command identifier carried in the received service request according to the order in which the service request is received.

In the above method, the method also includes:

When it is judged that the execution state of the task corresponding to the command identifier in the service request is not executed, the backend finds the corresponding task of the module name from the mapping relationship between the command identifier, the module name, and the executed task in the configuration file according to the command identifier. a processing module; the processing module finds the task to be executed according to the mapping relationship, and executes the found task;

When the task execution is successful, the backend returns the prompt information of task execution success to the front end through the intermediate processor; when the task execution fails, the backend returns the prompt information of task execution failure to the front end through the intermediate processor.

In the above method, if there is no serial number in the service request in the corresponding relationship between the execution status of the task recorded in the backend and the serial number in the service request, then it is determined that the command identifier in the service request corresponds to The execution status of the task is not executed;

When the execution of the task fails, the method further includes: deleting the recorded correspondence between the execution status of the task and the serial number in the service request.

In the above method, when it is judged that the execution status of the task corresponding to the command identifier in the service request is in execution, the backend returns the prompt information of the task execution error to the intermediate processor;

When it is determined that the execution state of the task corresponding to the command identifier in the service request is completed, the backend returns a prompt message indicating that the task is successfully executed to the intermediate processor.

In the above method, when the front-end sends the service request carrying the command identifier to the intermediate processor, or when the intermediate processor does not receive the response returned by the back-end, the intermediate processor sends the service request carrying the command identifier and the serial number to the back-end ; The response includes: task execution failure prompt information, task execution success prompt information or task execution error prompt information.

A task judgment system, comprising: an intermediate processor, a backend; the backend further includes a scheduling module; wherein,

The scheduling module is used to record the corresponding relationship between the execution state of the task and the serial number in the service request when executing the corresponding task in the service request sent by the intermediate processor; The serial number in the request, when it is judged that the execution state of the task corresponding to the command identifier in the service request is in execution or completed, refuse to execute the task again.

In the above system, the serial number is: after receiving the service request sent by the front end, the intermediate processor allocates a unique serial number for the command identifier carried in the received service request according to the order in which the service request is received.

In the above system, the backend further includes: a processing module;

The scheduling module is further configured to, when it is determined that the execution state of the task corresponding to the command identifier in the service request is not executed, according to the command identifier, from the mapping relationship between the command identifier, the module name, and the executed task in the configuration file Find the processing module corresponding to the module name;

The processing module is used to find the task that needs to be executed according to the mapping relationship, and execute the found task; when the task execution is successful, return the prompt information of the task execution success to the scheduling module; when the task execution fails, the task execution fails The prompt information is returned to the scheduling module;

The scheduling module is also used to return the prompt information of task execution success or task execution failure to the front end through the intermediate processor.

In the above system, the scheduling module is further configured to determine if the sequence number in the service request does not exist in the corresponding relationship between the execution status of the task recorded in the backend and the sequence number in the service request. The execution status of the task corresponding to the command identifier in the above service request is not executed;

When the execution of the task fails, the scheduling module is further configured to delete the recorded correspondence between the execution status of the task and the sequence number in the service request.

In the above system, the scheduling module is further configured to return a prompt message of a task execution error to the intermediate processor when it is determined that the execution status of the task corresponding to the command identifier in the service request is in execution; When the execution state of the task corresponding to the command identifier in the service request is completed, the prompt information of successful task execution is returned to the intermediate processor.

In the above system, the intermediate processor is also used to send a service request carrying a command identifier and a serial number to the backend when the front end sends a service request carrying a command identifier to itself, or when it does not receive a response returned by the backend. Service request; the response includes: prompt information of task execution failure, task execution success or task execution error prompt information.

As can be seen from the above technical solutions, the present invention has the following beneficial effects:

For the service request received from the intermediate processor, the backend will judge the weight of the task, and decide whether to execute the task according to the weight judgment result; in this way, the backend can avoid repeated processing of the task corresponding to the service request, reduce the processing burden of the backend, and save Backend processing resources.

【Description of drawings】

Fig. 1 is the structural representation of the preferred embodiment that the present invention realizes task judging system;

Fig. 2 is a flow diagram of a preferred embodiment of the method for realizing task weight judgment in the present invention.

【Detailed ways】

The basic idea of the present invention is: when the backend executes the task corresponding to the command identifier in the service request sent by the intermediate processor, record the corresponding relationship between the execution state of the task and the serial number in the service request; The serial number in the sent service request, when it is determined that the execution state of the task corresponding to the command identifier in the service request is in execution or completed, refuse to execute the task again.

In order to make the object, technical solution and advantages of the present invention clearer, the present invention will be described in detail below in conjunction with the accompanying drawings and specific embodiments.

The present invention provides a task judgment system. Fig. 1 is a schematic structural view of a preferred embodiment of the task judgment system in the present invention. As shown in Fig. 1, the system includes: a front end 10, an intermediate processor 20, and a back end 30; The backend 30 further includes a scheduling module 301 and more than one processing module 302-30n, where n is a positive integer greater than or equal to 3.

Based on the above-mentioned system, the present invention also provides a method for judging the weight of a task. Fig. 2 is a schematic flow diagram of a preferred embodiment of the method for judging the weight of a task in the present invention. As shown in Fig. 2, the preferred embodiment includes the following steps:

Step 201, the front end sends a service request carrying a command identifier to the intermediate processor.

Specifically, the front-end and back-end developers pre-negotiate the mapping relationship between the command identifier key, module name, and executed tasks. The front-end receives the command identifier key input by the front-end developer, and then carries the command identifier key in the service request and sends it to the middle Processor; where, the command identification key can be any string, such as abc, or the command identification key can be composed of the module name, the executed task or the module name + the executed task, and the backend can obtain the corresponding command identification key according to the command identification key The module and the task to be executed; for example, the command identifier key can be msg-insertWebBroadcastMsg, where msg is the message, and insertWebBroadcastMsg is the task to be executed.

Step 202: After receiving the service request sent by the front end, the intermediate processor assigns a unique serial number to the command identifier carried in the received service request according to the order in which the service request is received, and passes the assigned serial number and command identifier through The service request is sent to the backend.

Specifically, after the intermediate processor receives the service request sent by the front end, it extracts the carried command identification key from the service request, and then assigns a unique serial number to the command identification key in the service request according to the order in which the service requests are received , and carry the assigned serial number and command identifier key in the service request and send it to the backend; at the same time, the intermediate processor needs to store the assigned serial number and the corresponding command identifier key, so that the intermediate processor does not have any When receiving the backend's response to the service request, send the service request to the backend again.

Wherein, the intermediate processor can assign a unique serial number to the command identification key therein according to the order in which the service requests are received, for example, after receiving the first service request, assign the serial number 001 to the command identification key therein, and After receiving the second service request, assign the sequence number 002 to the command identifier key, and so on; for example, if the command identifier key is msg-insertWebBroadcastMsg, the service request sent by the intermediate processor to the backend carries the command identifier key and Serial number, that is, msg-insertWebBroadcastMsg-001 is carried in the service request, where insertWebBroadcastMsg is the command identification key, and 001 is the serial number allocated by the intermediate processor for the command identification key.

Step 203, when the backend executes the task corresponding to the command identifier in the service request sent by the intermediate processor, record the corresponding relationship between the execution status of the task and the serial number in the service request; when the backend executes the corresponding task according to the service request sent by the intermediate processor If it is determined that the execution status of the task corresponding to the command identifier in the service request is in progress or has been executed, the task is refused to be executed again.

Specifically, after the front-end and back-end developers negotiate the mapping relationship between the command identifier key, module name, and executed tasks, write the mapping of the command identifier key, module name, and executed tasks into the configuration file stored in the back-end memory Relationships, for example, the following fields representing mapping relationships can be written in the configuration file:

[.msg-insertWebBroadcastMsg]

[..param]

webid:int

msgtype:int

magdetail: string

[..self]

class:Service_RpcPage_Broadcast

method:insertWebBroadcastMsg

Among them, in the above mapping relationship, msg-insertWebBroadcastMsg represents the command identification key, the assignment Service_RpcPage_Broadcast of the class field name indicates the module name corresponding to the command identification key, and the assignment insertWebBroadcastMsg of the method field name indicates that the command identification key corresponds to the task to be executed.

When the scheduling module triggers the processing module to execute the task corresponding to the command identifier in the service request sent by the intermediate processor, it records the corresponding relationship between the execution status of the task and the sequence number in the service request; After the service request is sent, the command identification key and serial number are extracted from the service request, and according to the serial number, the corresponding relationship between the execution status of the task stored in the back-end memory and the serial number is read. In the relationship, find the serial number and the execution status of the corresponding task;

If the scheduling module does not find the serial number in the received service request in the corresponding relationship between the execution status of the task and the serial number, it means that the locked state of the serial number is unlocked, and it determines the command identifier key in the service request If the execution status of the corresponding task is unexecuted, the scheduling module first adds the serial number and the execution status of the corresponding task to the corresponding relationship, then locks the serial number, and sets the execution status of the corresponding task as being executed , and set the lock timer of the serial number. After the lock timer expires, the execution status of the corresponding task is set to completed, and the serial number is unlocked; then the scheduling module needs to extract it from the service request Command identifier key, find the corresponding module name in the mapping relationship between the command identifier key, module name, and executed task in the configuration file, and then send the extracted command identifier key to the corresponding processing module; the processing module receives the command identifier After the key, read the configuration file, find the task to be executed in the mapping relationship between the command identifier key, the module name, and the executed task in the configuration file, and execute the task; if the task is executed successfully, return the task execution to the scheduling module For successful prompt information, the scheduling module returns the prompt information of successful task execution to the intermediate processor, and the intermediate processor forwards it to the front end. After the lock timer expires, it automatically unlocks the serial number corresponding to the command identification key, and the The lock state of the serial number is set as locked and has been executed, so the scheduling module does not need to modify the lock state of the serial number in the mapping relationship table between the serial number and the locked state; if the task execution of the processing module fails, the processing module sends The scheduling module returns the prompt information of task execution failure. The scheduling module returns the prompt information of task execution failure to the intermediate processor, and the intermediate processor forwards it to the front end. At the same time, the scheduling module deletes the serial number and the execution status of the corresponding task in the corresponding relationship. In this way, if a service request containing the serial number is received from the intermediate processor, the processing module can re-execute the corresponding task.

If the scheduling module finds the serial number in the corresponding relationship between the execution state of the task and the serial number, and the locking status of the serial number is locked and is being executed, it determines that the command in the service request carrying the serial number The task corresponding to the identification key is already being executed by the processing module, so it refuses to execute the task again, and the scheduling module returns the prompt information of task execution error to the intermediate processor, and the intermediate processor will not receive the prompt information returned by the backend , send the same service request to the backend again within the sending cycle.

If the scheduling module finds the sequence number in the corresponding relationship between the execution state of the task and the sequence number, and the lock state of the sequence number is locked and has been executed, it determines the command identifier key in the service request of the sequence number The corresponding task has been executed by the processing module, and the task execution is successful, so it refuses to execute the task again, then the scheduling module returns the prompt information of task execution success to the intermediate processor, and the intermediate processor returns the prompt information of task execution success to front end.

In the process of the above method, if the intermediate processor receives the message of successful task execution, the message of task execution failure or the message of task execution error returned by the back end and returns it to the front end, if it does not receive the message carrying the same The service request of the command identification key will not repeatedly send the service request carrying the same command identification key to the backend. That is to say, the intermediate processor will repeatedly send service requests carrying the same command identification key to the backend only when it does not receive a response from the backend within a set time.

In practical applications, there is a situation where a task needs to be executed multiple times. At this time, the front end will repeatedly send service requests carrying the same command identification key to the intermediate processor to instruct the back end to repeatedly execute the same task. Using the preferred embodiment of the present invention , even if the intermediate processor receives service requests carrying the same command ID successively from the front end, it will assign different serial numbers to the command ID key according to the order of receipt, and the backend judges the lock status of the serial number according to the serial number in the service request , and further judge whether to execute the corresponding task based on the locking state, rather than judging whether to execute the corresponding task based on the command identification key. Different serial numbers are assigned to command identifiers, and the serial numbers saved in the backend will not include newly received serial numbers, so even if the command identifier keys are the same, the corresponding tasks can be repeated; For the submitted service request, the backend will perform corresponding processing. For the service request repeatedly submitted by the intermediate processor because it has not received a response, the backend will enter into the weight judgment of the task, and decide whether to execute the processing according to the weight judgment result; thus, both It does not affect the front-end instructing the back-end to repeatedly execute the same task, and can avoid the repeated execution of tasks caused by the repeated sending of service requests by the intermediate processor, solve the problem of repeated processing of tasks corresponding to service requests at the back-end, reduce the processing burden of the back-end, and save back-end resources Processing resources; at the same time, it can reduce the number of times the intermediate processor repeatedly sends service requests, reduce the processing burden of the intermediate processor, and save the processing resources of the intermediate processor; when the above technical solution is applied to various business websites such as payment websites, it can avoid the Users repeatedly submit service requests, causing economic losses to users and improving user experience.

In order to realize the above method, the system shown in Figure 1:

The scheduling module 301 is used to record the corresponding relationship between the execution state of the task and the serial number in the service request when executing the corresponding task in the service request sent by the intermediate processor 20; When it is determined that the execution status of the task corresponding to the command identifier in the service request is in progress or has been executed, the task is refused to be executed again.

Wherein, the serial number is: after receiving the service request sent by the front end 10, the intermediate processor 20 allocates a unique serial number for the command identifier carried in the received service request according to the order in which the service request is received.

Wherein, the scheduling module 301 is further configured to, when it is judged that the execution state of the task corresponding to the command identifier in the service request is not executed, according to the command identifier, from the configuration file the command identifier, the module name, the executed task Find the processing module 302~30n corresponding to the module name in the mapping relationship;

The processing modules 302~30n are used to find the tasks that need to be executed according to the mapping relationship, and execute the found tasks; when the task execution is successful, return the prompt information of the task execution success to the scheduling module 301; when the task execution fails, Return the prompt information of task execution failure to the scheduling module 301;

The scheduling module 301 is further configured to return the prompt information of task execution success or task execution failure to the front end 10 through the intermediate processor 20 .

Wherein, the scheduling module 301 is further configured to determine if the sequence number in the service request does not exist in the corresponding relationship between the execution status of the task recorded by the backend 30 and the sequence number in the service request. The execution status of the task corresponding to the command identifier in the above service request is not executed;

When the execution of the task fails, the scheduling module 301 is further configured to delete the recorded correspondence between the execution state of the task and the sequence number in the service request.

Wherein, the scheduling module 301 is further configured to return a prompt message of a task execution error to the intermediate processor 20 when judging that the execution state of the task corresponding to the command identifier in the service request is in execution; When the execution state of the task corresponding to the command identifier in the service request is completed, a prompt message indicating that the task is successfully executed is returned to the intermediate processor 20.

Wherein, the intermediate processor 20 is also used for sending a service request carrying a command identifier and a serial number to the backend 30 when the front end 10 sends a service request carrying a command identifier to itself, or when the response returned by the backend is not received by itself. The service request; the response includes: task execution failure prompt information, task execution success prompt information or task execution error prompt information.

The above descriptions are only preferred embodiments of the present invention, and are not intended to limit the present invention. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of the present invention shall be included in the present invention. within the scope of protection.

Claims (12)

1. A method for judging the weight of a task is characterized in that, when the back-end executes the task corresponding to the command identifier in the service request sent by the intermediate processor, it records the correspondence between the execution state of the task and the serial number in the service request; Methods also include: When the backend judges according to the serial number in the service request sent by the intermediate processor that the execution state of the task corresponding to the command identifier in the service request is in progress or completed, it refuses to execute the task again. 2. The method of claim 1, wherein, The serial number is: after receiving the service request sent by the front end, the intermediate processor allocates a unique serial number for the command identifier carried in the received service request according to the order in which the service request is received. 3. The method according to claim 1, characterized in that the method further comprises: When it is judged that the execution state of the task corresponding to the command identifier in the service request is not executed, the backend finds the corresponding task of the module name from the mapping relationship between the command identifier, the module name, and the executed task in the configuration file according to the command identifier. a processing module; the processing module finds the task to be executed according to the mapping relationship, and executes the found task; When the task execution is successful, the backend returns the prompt information of task execution success to the front end through the intermediate processor; when the task execution fails, the backend returns the prompt information of task execution failure to the front end through the intermediate processor. 4. The method according to claim 3, wherein if there is no serial number in the service request in the corresponding relationship between the execution status of the task recorded in the backend and the serial number in the service request, Then it is determined that the execution state of the task corresponding to the command identifier in the service request is not executed; When the execution of the task fails, the method further includes: deleting the recorded correspondence between the execution status of the task and the serial number in the service request. 5. The method of claim 1, wherein, When it is judged that the execution state of the task corresponding to the command identifier in the service request is in execution, the backend returns the prompt information of the task execution error to the intermediate processor; When it is determined that the execution state of the task corresponding to the command identifier in the service request is completed, the backend returns a prompt message indicating that the task is successfully executed to the intermediate processor. 6. according to the described method of claim 1, it is characterized in that, When the front end sends the service request carrying the command identification to the intermediate processor, or when the intermediate processor does not receive the response returned by the back end, the intermediate processor sends the service request carrying the command identification and the serial number to the back end; the response Including: the prompt information of task execution failure, the prompt information of successful task execution or the prompt information of task execution error. 7. A task weight judgment system, characterized in that the system includes: an intermediate processor, a back end; the back end further includes a scheduling module; wherein, The scheduling module is used to record the corresponding relationship between the execution state of the task and the serial number in the service request when executing the corresponding task in the service request sent by the intermediate processor; The serial number in the request, when it is judged that the execution state of the task corresponding to the command identifier in the service request is in execution or completed, refuse to execute the task again. 8. The system according to claim 7, wherein the serial number is: after the intermediate processor receives the service request sent by the front end, according to the order in which the service request is received, it is The unique serial number assigned by the carried command identifier. 9. The system according to claim 7, wherein the backend further comprises: a processing module; The scheduling module is further configured to, when it is determined that the execution state of the task corresponding to the command identifier in the service request is not executed, according to the command identifier, from the mapping relationship between the command identifier, the module name, and the executed task in the configuration file Find the processing module corresponding to the module name; The processing module is used to find the task that needs to be executed according to the mapping relationship, and execute the found task; when the task execution is successful, return the prompt information of the task execution success to the scheduling module; when the task execution fails, the task execution fails The prompt information is returned to the scheduling module; The scheduling module is also used to return the prompt information of task execution success or task execution failure to the front end through the intermediate processor. 10. The system according to claim 9, wherein the scheduling module is further configured to if there is no corresponding relationship between the execution status of the task recorded by the backend and the sequence number in the service request. According to the sequence number in the service request, it is determined that the execution status of the task corresponding to the command identifier in the service request is not executed; When the execution of the task fails, the scheduling module is further configured to delete the recorded correspondence between the execution status of the task and the sequence number in the service request. 11. The system according to claim 7, wherein the scheduling module is further configured to, when it is determined that the execution state of the task corresponding to the command identifier in the service request is in execution, prompt the task execution error The information is returned to the intermediate processor; when it is judged that the execution status of the task corresponding to the command identifier in the service request is completed, the prompt information of successful task execution is returned to the intermediate processor. 12. The system according to claim 7, wherein the intermediate processor is further configured to: when the front end sends a service request carrying a command identifier to itself, or when it does not receive a response returned by the back end, A service request carrying a command identifier and a serial number is sent to the backend; the response includes: prompt information of task execution failure, task execution success or task execution error prompt information.

Images