CN110764881A

CN110764881A - Distributed system background retry method and device

Info

Publication number: CN110764881A
Application number: CN201911011837.5A
Authority: CN
Inventors: 罗宗凯; 巫春梅; 刘圣杰; 李燊
Original assignee: Industrial and Commercial Bank of China Ltd ICBC
Current assignee: Industrial and Commercial Bank of China Ltd ICBC
Priority date: 2019-10-23
Filing date: 2019-10-23
Publication date: 2020-02-07

Abstract

The application provides a distributed system background retry method and a device, wherein the method comprises the following steps: determining a corresponding scheduler in a preset task scheduling frame based on pre-stored job information; sending a request instruction to the scheduler so that the scheduler applies the corresponding scheduler parameter to obtain the corresponding retry task set, and calling the corresponding executor to perform retry processing according to the retry task set; and receiving the processing result correspondingly obtained by the scheduler after the actuator performs the retry processing, and outputting and displaying the processing result. According to the method and the device, the effectiveness and the real-time performance of the distributed system for dealing with asynchronous execution failure can be improved, and the robustness of the distributed system is further improved.

Description

Distributed system background retry method and device

Technical Field

The present application relates to the field of distributed system technologies, and in particular, to a method and an apparatus for background retry in a distributed system.

Background

A distributed system is a system of computer nodes that communicate over a network and that work in concert to accomplish a common task. The distributed system can complete the calculation and storage tasks which cannot be completed by a single computer by using cheap and ordinary machines so as to process more data by using more machines.

The existing internet bank interconnection system (also called an internet bank cross-bank clearing system or an online payment cross-bank clearing system) is a distributed internet bank interconnection system constructed based on an open platform, is an important application system of a modern payment system, is mainly used for supporting the processing of online cross-bank retail payment service, and sends service instructions one by one, and carries out real-time reconciliation and timed clearing. The client can submit the payment service in an online mode and can obtain a service processing result in real time. Service calls currently provided to the peripheral channels and inter-calls to internal subsystems are made by asynchronous processing.

The service call of the peripheral channel and the mutual call of the internal subsystems are realized in the distributed system in an asynchronous processing mode, the problem of global transaction consistency exists, and a mechanism is needed to ensure the transaction consistency of different systems in an abnormal scene.

Disclosure of Invention

Aiming at the problems in the prior art, the application provides a distributed system background retry method and a distributed system background retry device, which can improve the effectiveness and the real-time performance of a distributed system for dealing with asynchronous execution failure, and further improve the robustness of the distributed system.

In order to solve the technical problem, the present application provides the following technical solutions:

in a first aspect, the present application provides a distributed system background retry method, including:

determining a corresponding scheduler in a preset task scheduling frame based on pre-stored job information;

sending a request instruction to the scheduler so that the scheduler applies the corresponding scheduler parameter to obtain the corresponding retry task set, and calling the corresponding executor to perform retry processing according to the retry task set;

and receiving the processing result correspondingly obtained by the scheduler after the actuator performs the retry processing, and outputting and displaying the processing result.

Further, the job information includes: scheduler program name and routing policy; correspondingly, the determining the corresponding scheduler based on the pre-stored job information includes: judging whether an available scheduler exists according to the scheduler program name; and if so, determining a corresponding scheduler according to the routing strategy.

Further, the scheduler applies the corresponding scheduler parameter to obtain the corresponding retry task set, including: and the scheduler applies the corresponding scheduler parameter to acquire a corresponding retry task set from a prestored retry service registration table.

Further, before the invoking the corresponding executor according to the retry task set to perform retry processing, the method further includes: the scheduler uses the corresponding scheduler parameter to obtain a corresponding retry transaction class from a pre-stored access queue list; correspondingly, the invoking the corresponding executor according to the retry task set to perform retry processing includes: and the executor applies the retry transaction class to carry out retry processing.

Further, before the invoking the corresponding executor according to the retry task set to perform retry processing, the method further includes: the scheduler uses the corresponding scheduler parameter to obtain the corresponding maximum retry times from a prestored access queue list; correspondingly, the executor is configured to add 1 to the actual retry number of the retry task in the pre-stored retry service registration table, and update the status of the retry task to be in processing; applying the retry transaction class to perform retry processing; and if the retry processing is successful, updating the state of the retry task in the prestored retry service registration table to be successful.

Further, the actuator is further configured to: if the retry processing fails, judging whether the actual retry times reach the maximum updating times, if so, updating the state of the retry task in the prestored retry service registration table to be failure; if not, updating the state of the retry task in the pre-stored retry service registration table to be retried, so that the scheduler receives the information of the state to be retried.

Further, the updating the status of the retry task in the retry service registry is to be retried, so that the scheduler receives the information of the status to be retried, including: and updating the state of the retry task in the pre-stored retry service registration table to be retried, so that the scheduler acquires a corresponding retry task set from the pre-stored retry service registration table again according to the scheduler parameter.

In a second aspect, the present application provides a distributed system background retry apparatus, including:

the determining module is used for determining a corresponding scheduler in a preset task scheduling frame based on pre-stored job information;

a retry processing module, configured to send a request instruction to the scheduler, so that the scheduler applies a corresponding scheduler parameter to obtain a corresponding retry task set, and invokes a corresponding executor to perform retry processing according to the retry task set;

and the receiving module is used for receiving the processing result correspondingly obtained by the scheduler after the actuator performs the retry processing and outputting and displaying the processing result.

In a third aspect, the present application provides an electronic device, which includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor implements the steps of the distributed system background retry method when executing the program.

In a fourth aspect, the present application provides a computer readable storage medium having stored thereon computer instructions that, when executed, implement the steps of the distributed system background retry method.

According to the technical scheme, the application provides a distributed system background retry method and device. Wherein, the method comprises the following steps: determining a corresponding scheduler in a preset task scheduling frame based on pre-stored job information; sending a request instruction to the scheduler so that the scheduler applies the corresponding scheduler parameter to obtain the corresponding retry task set, and calling the corresponding executor to perform retry processing according to the retry task set; and receiving and outputting and displaying a processing result correspondingly obtained by the scheduler after the actuator performs the retry processing, so that the automation degree and the configurable degree of asynchronous execution failure and unknown transaction retry processing can be improved, the efficiency and the accuracy of a background retry process of the distributed system are improved, the consistency of global transactions in an abnormal scene is ensured, and the real-time performance of fault processing and the robustness of the distributed system are further improved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 is a flow chart illustrating a background retry method of a distributed system in an embodiment of the present application;

fig. 2 is a schematic structural diagram of a distributed system background retry apparatus in an embodiment of the present application;

FIG. 3 is a schematic structural diagram of a distributed system background retry system in an embodiment of the present application;

FIG. 4 is a logic diagram of a distributed system background retry system in an embodiment of the present application;

FIG. 5 is a flowchart illustrating a background retry method of a distributed system in an exemplary embodiment of the present application;

FIG. 6 is a flow chart illustrating a distributed system background retry method according to another embodiment of the present application;

fig. 7 is a schematic block diagram of a system configuration of an electronic device 9600 according to an embodiment of the present application.

Detailed Description

In order to make those skilled in the art better understand the technical solutions in the present specification, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

In order to guarantee the consistency of global transactions in an abnormal scene and further improve the timeliness of fault processing and the robustness of a distributed system, the application provides the distributed system background retry method and the distributed system background retry device. The job scheduling center starts a retry task scanning scheduler at regular time, and the scheduler scans the task to be retried and calls a retry executor to retry the failed service, so that the stability and the efficiency of the distributed system are improved.

According to the foregoing, the distributed system background retry apparatus provided in this embodiment of the present application may be a server or a client device, where the client device may include a smart phone, a tablet electronic device, a network set-top box, a portable computer, a desktop computer, a Personal Digital Assistant (PDA), an in-vehicle device, and an intelligent wearable device. Wherein, intelligence wearing equipment can include intelligent glasses, intelligent wrist-watch and intelligent bracelet etc..

In practical applications, the portion of performing the background retry of the distributed system may be performed on the server side as described in the above, or all operations may be performed in the client device. The selection may be specifically performed according to the processing capability of the client device, the limitation of the user usage scenario, and the like. This is not a limitation of the present application. The client device may further include a processor if all operations are performed in the client device.

The client device may have a communication module (i.e., a communication unit), and may be communicatively connected to a remote server to implement data transmission with the server. The server may include a server on the side of the task scheduling center, and in other implementation scenarios, the server may also include a server on an intermediate platform, for example, a server on a third-party server platform that is communicatively linked to the task scheduling center server. The server may include a single computer device, or may include a server cluster formed by a plurality of servers, or a server structure of a distributed apparatus.

The server and the client device may communicate using any suitable network protocol, including network protocols not yet developed at the filing date of this application. The network protocol may include, for example, a TCP/IP protocol, a UDP/IP protocol, an HTTP protocol, an HTTPS protocol, or the like. Of course, the network Protocol may also include, for example, an RPC Protocol (Remote Procedure Call Protocol), a REST Protocol (Representational State Transfer Protocol), and the like used above the above Protocol.

The following examples are intended to illustrate the details.

In order to ensure consistency of global transactions in an abnormal scenario and further improve real-time performance of fault handling and robustness of a distributed system, the present application provides an embodiment of a distributed system background retry method in which an execution subject is a distributed system background retry apparatus, and referring to fig. 1, the method specifically includes:

step 100: and determining a corresponding scheduler in a preset task scheduling frame based on the pre-stored job information.

Specifically, the preset task calling framework may be a task scheduling framework Quartz, which is a lightweight open-source task scheduling framework. Specifically, the pre-stored job information is written into a scheduling database in advance through a database script, and the scheduling database may be deployed in an independent server.

Step 200: and sending a request instruction to the scheduler so that the scheduler applies the corresponding scheduler parameter to obtain the corresponding retry task set, and calling the corresponding executor to perform retry processing according to the retry task set.

Specifically, the job information includes a trigger mode and a trigger condition, and it can be understood that if the current system time satisfies the trigger mode and the trigger condition, a request instruction is sent to the scheduler.

The scheduler parameter comprises a retry queue set, and the scheduler queries a pre-stored retry service registration table according to a retry queue type in the retry queue set to obtain a retry task set; further, the executor includes two functions of retry service and retry transaction class. Physically, a scheduler corresponds to retry service of a service cluster, and the retry service calls different retry transaction classes according to different queue classes, so that the corresponding relationship between the scheduler and the executor should be one-to-one; there is no dependency between the retry tasks and no particular order is required.

Step 300: and receiving the processing result correspondingly obtained by the scheduler after the actuator performs the retry processing, and outputting and displaying the processing result.

Specifically, the scheduler applies a result notification callback service of the distributed background retry device to receive a processing result which is obtained correspondingly after retry processing, and sends the processing result to the distributed background retry device, and the distributed background retry device controls the page to display the processing result.

In order to improve the accuracy and efficiency of configuring an executor and further improve the efficiency and accuracy of background retry of a distributed system, in one or more embodiments of the present application, the job information includes: scheduler program name and routing policy. Correspondingly, step 100 includes:

step 101: and judging whether an available scheduler exists according to the scheduler program name.

Step 102: and if so, determining a corresponding scheduler according to the routing strategy.

Specifically, the pre-stored job information includes: scheduler program name, trigger mode, trigger condition and routing strategy; determining the time for triggering the scheduler according to the triggering mode and the triggering condition, determining whether a callable scheduler exists according to the program name, and calling the corresponding scheduler according to the routing strategy, wherein the routing strategy and the scheduler are in a one-to-one correspondence relationship; if the job information includes a plurality of routing policies, the scheduler corresponding to each routing policy may be determined according to the plurality of routing policies. The trigger mode is a timing mode or a fixed point mode; for example, the trigger condition is every day, HH: SS, or every one minute; the routing policy, i.e., the scanning cluster, may be a paid cluster, a non-paid cluster, or a full cluster. And if the triggering condition is 11:00:00 every day, the triggering mode is a fixed point mode, and the current system time is 11:00:00, sending a request instruction to a corresponding scheduler.

It will be appreciated that any scheduler is not required in all clusters and that the selection of which clusters to use for that scheduler is required in accordance with the configured routing policy. Say the routing policy of the dispatcher configures the non-payment cluster, the dispatcher is triggered only at the non-payment cluster.

In order to further improve the consistency of the global transaction in the abnormal scenario and further improve the timeliness of the fault processing and the robustness of the distributed system, the scheduler in step 200 applies the corresponding scheduler parameter to obtain the retry task set corresponding to the scheduler, which includes:

step 201: and the scheduler applies the corresponding scheduler parameter to acquire a corresponding retry task set from a prestored retry service registration table.

Specifically, the pre-stored retry service registration table includes a retry task name, a record status, and an actual retry number. And acquiring a record state and an actual retry number corresponding to the retry task name in the retry service registry according to the retry task name in the scheduler parameter, and extracting the record state as the information of the task in processing and waiting for retry to generate a corresponding retry task set. The retry service registry is stored in a service database, which may be deployed in a separate server.

In one or more embodiments of the present application, in order to further improve the robustness of the distributed system, before the invoking the corresponding executor according to the retry task set to perform the retry process in step 200, the method further includes:

step 020: and the scheduler acquires the corresponding retry transaction class from a pre-stored access queue list by applying the corresponding scheduler parameter.

Correspondingly, step 300 includes:

step 301: and the executor applies the retry transaction class to carry out retry processing.

In order to further improve the efficiency and real-time performance of processing the abnormal state of the distributed system, in one or more embodiments of the present application, before step 200, the method further includes:

step 021: and the scheduler acquires the corresponding maximum retry times from a prestored access queue list by applying the corresponding scheduler parameter.

Correspondingly, the actuator is used for: adding 1 to the actual retry times of the retry tasks in the pre-stored retry service registration table, and updating the status of the retry tasks to be in processing; applying the retry transaction class to perform retry processing; and if the retry processing is successful, updating the state of the retry task in the prestored retry service registration table to be successful.

The actuator is further configured to: if the retry processing fails, determining whether the actual retry number has reached the maximum update number, if so, updating the status of the retry task in the pre-stored retry service registry to fail. If not, updating the state of the retry task in the pre-stored retry service registration table to be retried, so that the scheduler receives the information of the state to be retried.

In order to further improve the effectiveness and accuracy of the background retry of the distributed system, and further improve the real-time performance of the fault handling and the robustness of the distributed system, in one or more embodiments of the present application, step 035 further includes:

step 351: and updating the state of the retry task in the pre-stored retry service registration table to be retried, so that the scheduler acquires a corresponding retry task set from the pre-stored retry service registration table again according to the scheduler parameter.

Specifically, if the retry failure determination does not reach the retry number upper limit, the status is reset to be retried, so that the task can be scanned by the scheduler again until the statuses corresponding to all the retry tasks in the retry service registry are success or failure. By reading the pre-stored retry service registration table for multiple times and executing retry processes for multiple times, the transaction consistency of different clusters of the distributed system can be finally maintained, and each cluster is kept in a normal operation state.

In one or more embodiments of the present application, the distributed background retry method further includes: and receiving a scheduler registration instruction, and storing the newly added scheduler information in a scheduling database.

In terms of software, in order to improve the effectiveness and the real-time performance of the distributed system in dealing with asynchronous execution failure and further improve the robustness of the distributed system, the present application provides an embodiment of a distributed system background retry apparatus for all or part of the contents in a distributed system background retry method, and referring to fig. 2, the distributed system background retry apparatus specifically includes the following contents:

and the determining module 10 is configured to determine a corresponding scheduler in a preset task scheduling framework based on pre-stored job information.

A retry processing module 20, configured to send a request instruction to the scheduler, so that the scheduler applies the corresponding scheduler parameter to obtain a retry task set corresponding to the request instruction, and call a corresponding executor to perform retry processing according to the retry task set.

And a receiving module 30, configured to receive, output and display a processing result that is correspondingly obtained by the scheduler after the executor performs the retry processing.

In order to further improve the effectiveness and the real-time performance of the distributed system for responding to asynchronous execution failure and further improve the robustness of the distributed system, the application provides a specific application example of the distributed system background retry system and method.

Referring to fig. 3, the system mainly includes a job scheduling center 1, a scheduling database 2, a scheduler 3, a service database 4, and an executor 5. The function realized by the job scheduling center is equivalent to the function realized by the background retry device of the distributed system. The specific contents are as follows:

the job scheduling center 1 is used for triggering the scheduler according to the job information, wherein the job information comprises a task name, a program name (scheduler program name), a triggering mode (timing or fixed point), a triggering condition (such as HH: MM: SS execution or execution once every one minute) and a scanning cluster (a payment cluster, a non-payment cluster or a whole cluster).

Specifically, the job scheduling center is responsible for managing scheduling information based on a task scheduling framework Quartz (Quartz is a lightweight open source task scheduling framework), and sends out a scheduling request according to scheduling configuration without bearing service codes. The scheduling system is decoupled from the tasks, so that the availability and stability of the system can be improved, and meanwhile, the performance of the scheduling system is not limited by the task module any more, wherein the scheduling system comprises an operation scheduling center, a scheduling database and a scheduler; the method supports visual, simple and dynamic maintenance and management of scheduling information, comprises task creation, updating, deletion, task alarming and the like, all the operations can take effect in real time, and simultaneously supports monitoring of scheduling results and execution of logs.

And the scheduling database 2 is used for storing the job information, the dependency relationship and the scheduler registration information, the job information and the dependency relationship are written in through a database script, and the scheduler registration information is registered when the scheduler is started.

And the scheduler 3 is used for inquiring the retry queue parameters and the scanning retry tasks of the corresponding retry queues according to the scheduler parameters, and calling the executor to execute the retry tasks, wherein the scheduler parameters comprise a retry queue set and the maximum number of the single processing of the job, and the retry queue parameters comprise a retry number upper limit, a retry interval and a retry transaction class.

It can be understood that the scheduler is responsible for configuring the scheduler parameters (the background queue set and the maximum number of times of single processing of the job), acquiring the relevant retry queue parameters (the upper limit of retry times, the retry interval and the retry transaction class), scanning the retry service register to acquire the retry service which has reached the retry execution time, and calling the service layer retry executor to perform the retry processing, wherein the retry service register corresponds to the retry service register table.

And the service database 4 is used for saving and updating the retry service register, and the retry task data is written when all the retry processes in the background are required.

It is understood that the service database stores retry queue parameters, retry task data, and service data required for use in the retry procedure.

And the executor 5 is used for executing a retry task, inquiring the service table according to the service elements recorded in the retry service register to obtain retry service information, and calling respective retry transaction classes according to different retry queues to perform retry processing, wherein the service information in the service table is used for the retry transaction classes to execute specific retry service logic.

It can be understood that the service layer retry executor, i.e. the executor, includes two functions of retry service and retry transaction class, the retry service sets the retry service state as processing, adds 1 to the retry number, and invokes the incoming retry transaction class name reflection to instantiate the transaction class for retry processing. And judging whether the retry times reach the upper limit or not by the retry failure, if so, updating the retry service state to be retry failure, and if not, updating the retry service state to be retried. If the retry is successful, the status of the retry service is updated to retry success. And the service logic of the retry service is encapsulated in a specific retry transaction class, a corresponding service register is inquired according to an incoming retry service key value to obtain service data, and retry processing is carried out according to the service logic of a retry scene.

In order to further improve the effectiveness and the real-time performance of the distributed system in dealing with asynchronous execution failure and further improve the robustness of the distributed system, in combination with the distributed system background retry system, the present application provides a specific application example of a distributed system background retry method, and in summary, referring to fig. 4, in the specific application example, the following steps are included:

step S201: the scheduler is triggered.

Specifically, the job scheduling center triggers the scheduler according to a trigger mode and a trigger condition of job information, wherein the job information comprises a task name, a program name (scheduler program name), a trigger mode (timing or fixed point), a trigger condition (for example, every day HH: MM: SS execution or once every one minute execution), and a scanning cluster (payment cluster, non-payment cluster or all clusters).

Step S202: the retry task is scanned.

Specifically, the scheduler queries and acquires a background queue parameter according to the processed retry queue set, and then scans a retry task which has reached the retry time according to the retry queue set, wherein the background queue parameter includes a retry number upper limit, a retry interval and a retry transaction class.

Step S203: and calling the executor one by one to execute the retry task.

Specifically, the scheduler calls the service cluster executor one by one according to the retry tasks obtained by scanning to perform retry processing, and the executor calls respective retry transaction classes according to the retry queue where each retry task is located to perform retry processing.

Referring to fig. 5 in conjunction with the above steps, the present application provides another specific application example, which specifically includes:

step S301: the scheduler registers for service with the dispatch center.

Specifically, the scheduler starts to call a registration service (provided by a task scheduling framework Quartz) of the job scheduling center for registration, and an available scheduler is newly added in the scheduler registration information of the scheduling database.

Step S302: the task scheduling framework triggers job invocation.

Specifically, the job scheduling center reads the program name (scheduler program name) of job information in the scheduling database, the trigger mode (timing or fixed point) and the trigger condition (such as HH: MM: SS execution every day or execution every x minutes), and the task scheduling framework Quartz triggers the scheduler at regular time.

Step S303: the job scheduling center checks the scheduler status.

Specifically, the job scheduling center checks whether there is an available scheduler in the scheduling database based on the job information (scheduler program). If yes, go to step S304; if not, step S313 is executed.

Step S304: and the job scheduling center selects a scheduler according to the routing strategy.

Specifically, the job scheduling center selects a corresponding background scheduler according to a routing policy (a scanning cluster (a payment cluster, a non-payment cluster, or all clusters) in the job information).

Step S305: the job scheduling center transmits a scheduling request to a scheduler (scheduler program of job information).

Step S306: the scheduler receives a dispatch center call.

Specifically, the scheduler starts processing the request after receiving the request from the job scheduling center.

Step S307: the scheduler accesses the scheduler parameter table to obtain the scheduler parameters.

Specifically, the scheduler obtains scheduler parameters, which include a retry queue set and a maximum number of single-time processing strokes of the job.

Step S308: and the scheduler accesses the queue parameter table to acquire the queue parameters according to the retry queue set.

Specifically, the scheduler accesses the queue parameter table according to the retry queue set to acquire the switch of the queue, the retry interval, the upper limit of the retry times and the retry transaction class. The switch of the queue is mainly used for controlling whether the queue tasks need to be scanned or not, and when a certain queue has a problem, all retry tasks of the queue can be isolated through the switch.

Step S309: and the scheduler queries a retry service register according to the retry queue set to obtain a retry task set.

Step S310: the dispatcher calls the executor one by one to execute the retry task.

Step S311: and the dispatcher calls the callback service to return an execution result.

Specifically, the scheduler calls a result notification callback service (provided by the task scheduling framework Quartz) of the job scheduling center to return an execution result.

Step S312: and the job scheduling center callback service receives an execution result returned by the scheduler.

Step S313: and displaying the execution result on a control console page of the job scheduling center.

Specifically, the job scheduling center console page presents the execution result of the scheduler.

In this application example, the job scheduling center triggers the scheduler to scan the service to be retried in the corresponding service cluster database on each background jobserver according to the set time interval, and sends the service to the service cluster retry executor for retry processing, referring to fig. 6, the specific implementation steps are as follows:

step S401: the scheduler invokes the executor to perform the retry task.

Specifically, the scheduler scans the task to be retried and calls the executor to execute the task to be retried.

Step S402: and the executor calls the corresponding retry transaction class according to the queue to perform retry processing.

Specifically, the executor acquires the retry transaction class name in the retry queue parameter according to the retry queue to which the retry task belongs, and calls the corresponding retry transaction class to perform retry processing.

Step S403: and if the actuator retries successfully, the updating state is successful, the retrial times is added with 1, the updating state which reaches the upper limit of the retrial times is judged to be failed, and if not, the updating state is in processing.

Specifically, the executor determines, according to the retry transaction class execution result, that the retry successfully updates the retry service register record state to be successful, and determines that the retry fails by adding 1 to the retry number, if the retry number upper limit update state is reached to be failed, otherwise, the update state is in process.

Step S404: the executor returns an execution success.

Specifically, the executor returns an execution success after the execution is completed.

From the above description, the distributed system background retry method and the distributed system background retry device provided by the application can achieve decoupling of scheduling configuration and executing task, the scheduling configuration is not limited any more and the task executing process is not limited any more, availability and stability of asynchronous processing of the distributed system are improved, efficiency and accuracy of the distributed system background retry process are improved, consistency of global transactions in an abnormal scene is guaranteed, and instantaneity of fault processing and robustness of the distributed system are further improved. Meanwhile, the monitoring and scheduling result can be monitored in real time.

In terms of hardware, in order to improve the effectiveness and real-time performance of a distributed system in dealing with asynchronous execution failure and further improve the robustness of the distributed system, the present application provides an embodiment of an electronic device for implementing all or part of contents in a background retry method of the distributed system, where the electronic device specifically includes the following contents:

a processor (processor), a memory (memory), a communication Interface (Communications Interface), and a bus; the processor, the memory and the communication interface complete mutual communication through the bus; the communication interface is used for realizing information transmission between the distributed system background retry device and the related equipment such as the user terminal; the electronic device may be a desktop computer, a tablet computer, a mobile terminal, and the like, but the embodiment is not limited thereto. In this embodiment, the electronic device may be implemented with reference to the embodiment for implementing the distributed system background retry method and the embodiment for implementing the distributed system background retry apparatus in the embodiment, and the contents of the electronic device are incorporated herein, and repeated descriptions are omitted.

Fig. 7 is a schematic block diagram of a system configuration of an electronic device 9600 according to an embodiment of the present application. As shown in fig. 7, the electronic device 9600 can include a central processor 9100 and a memory 9140; the memory 9140 is coupled to the central processor 9100. Notably, this fig. 7 is exemplary; other types of structures may also be used in addition to or in place of the structure to implement telecommunications or other functions.

In one or more embodiments of the present application, the distributed system background retry functionality can be integrated into the central processor 9100. The central processor 9100 may be configured to control as follows:

As can be seen from the foregoing description, the electronic device provided in the embodiment of the present application can improve the effectiveness and the real-time performance of the distributed system in responding to the asynchronous execution failure, thereby improving the robustness of the distributed system.

In another embodiment, the distributed system background retry apparatus may be configured separately from the central processor 9100, for example, the distributed system background retry apparatus may be configured as a chip connected to the central processor 9100, and the distributed system background retry function is implemented by the control of the central processor.

As shown in fig. 7, the electronic device 9600 may further include: a communication module 9110, an input unit 9120, an audio processor 9130, a display 9160, and a power supply 9170. It is noted that the electronic device 9600 also does not necessarily include all of the components shown in fig. 7; further, the electronic device 9600 may further include components not shown in fig. 7, which may be referred to in the art.

As shown in fig. 7, a central processor 9100, sometimes referred to as a controller or operational control, can include a microprocessor or other processor device and/or logic device, which central processor 9100 receives input and controls the operation of the various components of the electronic device 9600.

The memory 9140 can be, for example, one or more of a buffer, a flash memory, a hard drive, a removable media, a volatile memory, a non-volatile memory, or other suitable device. The information relating to the failure may be stored, and a program for executing the information may be stored. And the central processing unit 9100 can execute the program stored in the memory 9140 to realize information storage or processing, or the like.

The input unit 9120 provides input to the central processor 9100. The input unit 9120 is, for example, a key or a touch input device. Power supply 9170 is used to provide power to electronic device 9600. The display 9160 is used for displaying display objects such as images and characters. The display may be, for example, an LCD display, but is not limited thereto.

The memory 9140 can be a solid state memory, e.g., Read Only Memory (ROM), Random Access Memory (RAM), a SIM card, or the like. There may also be a memory that holds information even when power is off, can be selectively erased, and is provided with more data, an example of which is sometimes called an EPROM or the like. The memory 9140 could also be some other type of device. Memory 9140 includes a buffer memory 9141 (sometimes referred to as a buffer). The memory 9140 may include an application/function storage portion 9142, the application/function storage portion 9142 being used for storing application programs and function programs or for executing a flow of operations of the electronic device 9600 by the central processor 9100.

The memory 9140 can also include a data store 9143, the data store 9143 being used to store data, such as contacts, digital data, pictures, sounds, and/or any other data used by an electronic device. The driver storage portion 9144 of the memory 9140 may include various drivers for the electronic device for communication functions and/or for performing other functions of the electronic device (e.g., messaging applications, contact book applications, etc.).

The communication module 9110 is a transmitter/receiver 9110 that transmits and receives signals via an antenna 9111. The communication module (transmitter/receiver) 9110 is coupled to the central processor 9100 to provide input signals and receive output signals, which may be the same as in the case of a conventional mobile communication terminal.

Based on different communication technologies, a plurality of communication modules 9110, such as a cellular network module, a bluetooth module, and/or a wireless local area network module, may be provided in the same electronic device. The communication module (transmitter/receiver) 9110 is also coupled to a speaker 9131 and a microphone 9132 via an audio processor 9130 to provide audio output via the speaker 9131 and receive audio input from the microphone 9132, thereby implementing ordinary telecommunications functions. The audio processor 9130 may include any suitable buffers, decoders, amplifiers and so forth. In addition, the audio processor 9130 is also coupled to the central processor 9100, thereby enabling recording locally through the microphone 9132 and enabling locally stored sounds to be played through the speaker 9131.

As can be seen from the above description, the electronic device provided in the embodiment of the present application can improve the effectiveness and the real-time performance of the distributed system in responding to the asynchronous execution failure, thereby improving the robustness of the distributed system.

Embodiments of the present application further provide a computer-readable storage medium capable of implementing all steps in the distributed system background retry method in the foregoing embodiments, where the computer-readable storage medium stores thereon a computer program, and when the computer program is executed by a processor, the computer program implements all steps of the distributed system background retry method in the foregoing embodiments, for example, when the processor executes the computer program, the processor implements the following steps:

As can be seen from the foregoing description, the computer-readable storage medium provided in the embodiments of the present application can improve the effectiveness and real-time performance of the distributed system in dealing with asynchronous execution failure, thereby improving the robustness of the distributed system.

In the present application, each embodiment of the method is described in a progressive manner, and the same and similar parts among the embodiments are referred to each other, and each embodiment focuses on the differences from the other embodiments. Reference is made to the description of the method embodiments.

As will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.

The present application is described with reference to flowchart illustrations and/or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the application. It will be understood that each flow and/or block of the flow diagrams and/or block diagrams, and combinations of flows and/or blocks in the flow diagrams and/or block diagrams, can be implemented by computer program instructions. These computer program instructions may be provided to a processor of a general purpose computer, special purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be stored in a computer-readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instruction means which implement the function specified in the flowchart flow or flows and/or block diagram block or blocks.

These computer program instructions may also be loaded onto a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart flow or flows and/or block diagram block or blocks.

The principle and the implementation mode of the present application are explained by applying specific embodiments in the present application, and the description of the above embodiments is only used to help understanding the method and the core idea of the present application; meanwhile, for a person skilled in the art, according to the idea of the present application, there may be variations in the specific embodiments and the application scope, and in summary, the content of the present specification should not be construed as a limitation to the present application.

Claims

1. A distributed system background retry method, comprising:

2. The distributed system background retry method of claim 1, wherein the job information comprises: scheduler program name and routing policy;

correspondingly, the determining a corresponding scheduler in a preset task scheduling framework based on the pre-stored job information includes:

judging whether an available scheduler exists according to the scheduler program name;

and if so, determining a corresponding scheduler according to the routing strategy.

3. The distributed system background retry method of claim 1, wherein the scheduler applies its corresponding scheduler parameters to obtain its corresponding set of retry tasks, comprising:

and the scheduler applies the corresponding scheduler parameter to acquire a corresponding retry task set from a prestored retry service registration table.

4. The distributed system background retry method according to claim 1, wherein before the invoking the corresponding executor according to the retry task set for retry processing, the method further comprises:

the scheduler uses the corresponding scheduler parameter to obtain a corresponding retry transaction class from a pre-stored access queue list;

correspondingly, the invoking the corresponding executor according to the retry task set to perform retry processing includes:

and the executor applies the retry transaction class to carry out retry processing.

5. The distributed system background retry method according to claim 1, wherein before the invoking the corresponding executor according to the retry task set for retry processing, the method further comprises:

the scheduler uses the corresponding scheduler parameter to obtain the corresponding maximum retry times from a prestored access queue list;

correspondingly, the executor is configured to add 1 to the actual retry number of the retry task in the pre-stored retry service registration table, and update the status of the retry task to be in processing; applying the retry transaction class to perform retry processing; and if the retry processing is successful, updating the state of the retry task in the prestored retry service registration table to be successful.

6. The distributed system background retry method of claim 5, wherein the executor is further configured to: if the retry processing fails, judging whether the actual retry times reach the maximum updating times, if so, updating the state of the retry task in the prestored retry service registration table to be failure; if not, updating the state of the retry task in the pre-stored retry service registration table to be retried, so that the scheduler receives the information of the state to be retried.

7. The distributed system background retry method as claimed in claim 6, wherein the updating the status of the retry task in the retry service registry is to be retried, so that the scheduler receives the information of the status to be retried, comprising:

and updating the state of the retry task in the pre-stored retry service registration table to be retried, so that the scheduler acquires a corresponding retry task set from the pre-stored retry service registration table again according to the scheduler parameter.

8. A distributed system background retry apparatus, comprising:

9. An electronic device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, wherein the processor implements the steps of the distributed system background retry method of any of claims 1 to 7 when executing the program.

10. A computer readable storage medium having stored thereon computer instructions, wherein the instructions, when executed, implement the steps of the distributed system background retry method of any of claims 1 to 7.