CN111078442A - Fault-tolerant retry method and device and terminal - Google Patents
Fault-tolerant retry method and device and terminal Download PDFInfo
- Publication number
- CN111078442A CN111078442A CN201811233323.XA CN201811233323A CN111078442A CN 111078442 A CN111078442 A CN 111078442A CN 201811233323 A CN201811233323 A CN 201811233323A CN 111078442 A CN111078442 A CN 111078442A
- Authority
- CN
- China
- Prior art keywords
- retry
- fault
- tolerant
- data
- result
- 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
- 238000000034 method Methods 0.000 title claims abstract description 62
- 238000004519 manufacturing process Methods 0.000 claims description 16
- 238000004590 computer program Methods 0.000 claims description 12
- 230000008569 process Effects 0.000 claims description 8
- 239000000284 extract Substances 0.000 claims description 3
- 230000009545 invasion Effects 0.000 abstract description 8
- 230000007246 mechanism Effects 0.000 description 11
- 238000010586 diagram Methods 0.000 description 8
- 238000004891 communication Methods 0.000 description 6
- 238000007726 management method Methods 0.000 description 5
- 238000013461 design Methods 0.000 description 4
- 230000008878 coupling Effects 0.000 description 3
- 238000010168 coupling process Methods 0.000 description 3
- 238000005859 coupling reaction Methods 0.000 description 3
- 238000013500 data storage Methods 0.000 description 3
- 238000003780 insertion Methods 0.000 description 3
- 230000037431 insertion Effects 0.000 description 3
- 230000004048 modification Effects 0.000 description 3
- 238000012986 modification Methods 0.000 description 3
- 238000007796 conventional method Methods 0.000 description 2
- 230000007547 defect Effects 0.000 description 2
- 238000012545 processing Methods 0.000 description 2
- 238000006467 substitution reaction Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 1
- 230000007115 recruitment Effects 0.000 description 1
- 230000004044 response Effects 0.000 description 1
- 230000026676 system process Effects 0.000 description 1
- 230000007704 transition Effects 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
- G06F11/0793—Remedial or corrective actions
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Retry When Errors Occur (AREA)
Abstract
The invention is suitable for the technical field of computers, and provides a fault-tolerant retry method, a fault-tolerant retry terminal and a fault-tolerant retry system, wherein the fault-tolerant retry method comprises the following steps: calling a creating notification method of the fault-tolerant server; reading retry data pre-stored in a database; retrying according to the retrying data to obtain a retrying result; and recording and saving the retry result. In the invention, access retry is carried out by calling a creation notification method of the fault-tolerant server, retry data pre-stored in a database is read for retry, the retry data is isolated from service logic, and no invasion is caused to an access system.
Description
Technical Field
The invention belongs to the technical field of computers, and particularly relates to a fault-tolerant retry method, a fault-tolerant retry device and a fault-tolerant retry terminal.
Background
The fault-tolerant retry mechanism is a self-regulation of the system, is one of important indexes of the robustness of the system, and the abnormity of the system can not always be recovered by a human, so that the system has fault-tolerant capability, and the fundamental solution is achieved. The JOB scheduling method is frequently involved in many service scenes, for example, the talent recruitment (JOB) system has many things to process, long completion time, high possibility of error occurrence and low requirement on response time; such as network temporary unavailability; and remote calling depending on a third party, such as calling a third party interface by personal authentication, does not need to specially write a program (job), and can be completely carried out by using a retry system. The purpose is to process more things without manual intervention.
In a service scenario, if the third party identity authentication interface is called unsuccessfully, retry is required, wherein one conventional method is to embed a retry code in a service code, and retry the retry code once immediately if a service request fails. The defect of the scheme is obvious, if a third-party service interface has a problem, double-time flow is brought, a service system per se is impacted, and the service of the third-party service interface can be directly broken down. In the conventional method, a job is written to specially process data which fails to call an interface, and the method has the defects that the job system processes a lot of things and processes failed data in batches, and the batches generate requests for a third-party system. Based on the above points, it is necessary to develop an independent fault-tolerant retry system, separate from the main flow, and add retry mechanisms such as retry number control, timeout control, idempotent and call log management.
Spring-retry mechanisms are commonly used today. Spring-retry tools enable graceful implementation of retries, but there are two unfriendly designs: one is that the retry entity is limited to the Throwable subclass, which is a design premise that the retry is directed to a functional exception that can be caught, but we want to rely on some data object entity as the retry entity, but the string-retry framework must force a transition to the Throwable subclass. The other is that the assertion object of the retry root uses an Exception instance (Exception) of doWithRetry, which does not conform to the return design of normal internal assertions. Spring Retry calls for a Retry to be done in an annotated way, the Retry logic is executed synchronously, the Retry "fails" for Throwable, and if you want to decide whether Retry is needed with some state of the return value, you can only decide the return value by themselves and then explicitly throw the exception. It can be seen that the existing and retry mechanisms are coupled with the service code, which is intrusive to the access system and does not support dynamic configuration of retry times and retry strategies.
Disclosure of Invention
The embodiment of the invention provides a fault-tolerant retry method, a fault-tolerant retry terminal and a fault-tolerant retry system, and aims to solve the problem that a retry mechanism and a service code coupling in the prior art are invasive to an access system.
A fault tolerant retry method, comprising:
calling a creating notification method of the fault-tolerant server;
reading retry data pre-stored in a database;
retrying according to the retrying data to obtain a retrying result;
and recording and saving the retry result.
Preferably, before the reading the retry data pre-stored in the database, the method further comprises:
receiving the retry data generated by a production end;
storing the retry data to the database.
Preferably, the retry data comprises: retry parameters, retry number, and retry execution time.
Preferably, the reading retry data pre-stored in the database includes:
obtaining a list of retry management to be processed;
acquiring a load balance value list to be processed;
acquiring the maximum retry times of each scheduled process;
a list of retry tasks to be processed is extracted.
Preferably, the retrying according to the retrying data, and obtaining a retrying result includes:
if the retry is successful, marking the retry result as the retry success and storing the retry result in the database;
if the retry fails, the retry result is marked as the retry failure, and the failure reason is recorded.
Preferably, the retrying according to the retrying data, and obtaining a retrying result further includes:
if the retry fails, obtaining the number of retries and the last execution time, and returning the result of the retry strategy according to the retry strategy class;
and judging whether the retry is needed to be continued, if so, adding 1 to the retry number, and calculating the time of the next retry.
The present invention also provides a fault-tolerant retry terminal, comprising:
a retry calling unit, which is used for calling the creating notification method of the fault-tolerant server;
the data reading unit is connected with the retry calling unit and used for reading retry data prestored in a database;
the retry unit is connected with the data reading unit and used for retrying according to the retry data and obtaining a retry result;
and the result recording unit is connected with the retry unit and is used for recording and storing the retry result.
The present invention also provides a fault tolerant retry system, comprising: the system comprises a production end, a fault-tolerant retry terminal and a database connected with the production end and the fault-tolerant retry terminal; the application program of the production end stores retry data needing retry in the database, and the fault-tolerant retry terminal extracts the retry data from the database and retries the retry data; the fault-tolerant retry terminal comprises:
retry calling unit for calling the creating notification method of the fault-tolerant server
The data reading unit is connected with the retry calling unit and used for reading retry data prestored in a database;
the retry unit is connected with the data reading unit and used for retrying according to the retry data and obtaining a retry result;
and the result recording unit is connected with the retry unit and is used for recording and storing the retry result.
The present invention also provides a memory storing a computer program, wherein the computer program is executed by a processor to perform the steps of:
calling a creating notification method of the fault-tolerant server;
reading retry data pre-stored in a database;
retrying according to the retrying data to obtain a retrying result;
and recording and saving the retry result.
The invention also provides a service terminal, which comprises a memory, a processor and a computer program which is stored in the memory and can run on the processor, wherein the processor executes the computer program to realize the following steps:
calling a creating notification method of the fault-tolerant server;
reading retry data pre-stored in a database;
retrying according to the retrying data to obtain a retrying result;
and recording and saving the retry result.
In the embodiment of the invention, the access retry is realized by calling the creation notification method of the fault-tolerant server, the retry data pre-stored in the database is read for retry, the retry data is isolated from the service logic, and the access system is not invasive.
Drawings
Fig. 1 is a flowchart of a fault-tolerant retry method according to a first embodiment of the present invention;
FIG. 2 is a schematic diagram of the class of fault-tolerant retry mechanisms of the present invention;
FIG. 3 is a flowchart of a preferred embodiment of a fault-tolerant retry method according to the first embodiment of the present invention;
fig. 4 is a block diagram of a fault-tolerant retry terminal according to a second embodiment of the present invention;
fig. 5 is a block diagram of a preferred embodiment of a fault-tolerant retry terminal according to a second embodiment of the present invention;
FIG. 6 is a block diagram of a fault-tolerant retry system according to a third embodiment of the present invention;
FIG. 7 is a diagram illustrating the operation of a fault-tolerant retry system according to a third embodiment of the present invention;
fig. 8 is a structural diagram of a service terminal according to a fifth embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, the present invention is described in further detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.
In an embodiment of the present invention, a fault-tolerant retry method includes: calling a creating notification method of the fault-tolerant server; reading retry data pre-stored in a database; retrying according to the retrying data to obtain a retrying result; and recording and saving the retry result.
In order to explain the technical means of the present invention, the following description will be given by way of specific examples.
The first embodiment is as follows:
fig. 1 is a flowchart illustrating a fault-tolerant retry method according to a first embodiment of the present invention, where the method includes:
step S1, calling a creating notification method of the fault-tolerant server;
specifically, a two-party library is introduced, retry data and business logic are isolated, and retry entering is started by calling a creation notification method of a fault-tolerant server.
Step S2, reading the retry data pre-stored in the database;
specifically, a createNotify method provided by retryService is called in a method requiring fault tolerance, so as to conveniently insert a fault-tolerant data entity, including a retry strategy. And writing a retry processing class, inheriting a RetryHandlerStrength interface, and accessing fault-tolerant retry. The fault-tolerant retry mechanism class is shown in fig. 2, wherein the retryscheduleeexecutor includes subsequent classes for the retry directory frame class. RetryHandlerStrategy is a retry management policy class, RetryBalancEnNumStrategy is a load balancing value class, RetryIdCacheStrategy is a retry data storage address class, and RetryMaxNuMStrategy is a maximum retry number class, and are all stored in the database. The task execution module is used for executing the task by the task execution module, the Retryservice is used for RetryService class, and the RetryHandler is used for retrycontrol class so as to call the RetryService for retrying; RetryDao is an insertion retry database table class, RetryDO is an acquisition or modification retry database table class, RetryHistoryDao is an insertion history retry database table class, retryhistorydo is an acquisition or modification history retry database table class, RetryHandler is a retry control class, and when retry failure is smaller than retry times, an Invoker is continuously selected to initiate a call. Retryidcachestream is a retry buffer address class, and retryhandlerreresult is a retry result class, and includes a mark of retry success or failure, a retry failure reason, and the like.
The retry data includes: the retry parameter, the retry number and the retry execution time are specifically two tables of the current retry data retry and the historical retry data retry _ history, and the fields of the two tables are the same. See below
Table 1:
| field(s) | Type (B) | Description of the invention |
| Id | bigint | Self-increment of ID, PK |
| handle_time | date | Next execution time |
| handle_time_interval | int(11) | The next execution time interval, unit of second |
| handle_type | varchar(2) | Type of processor |
| load_balance_num | int(11) | Load balancing value |
| retry_param | varchar(1024) | Retry data and parameters, json format |
| retry_count | int(11) | Number of retries |
| retry_max_count | int(11) | Maximum number of retries |
| retry_reason | varchar(1024) | Reason for retry |
| comment | varchar(1024) | Remarks for note |
| gmt_create | date | Data insertion time |
| gmt_modify | date | Data modification time |
In step S2, a list of retry management to be processed is acquired; acquiring a load balance value list to be processed; acquiring the maximum retry times of each scheduled process; a polling statement is then executed to extract a list of retry tasks to be processed. The method comprises the following specific steps:
step S3, retrying according to the retrying data to obtain the retrying result;
specifically, if the retry is successful, marking the retry result as the retry success and saving the retry result in the database; if the retry fails, the retry result is marked as the retry failure, and the failure reason is recorded. If the retry fails, the number of retries and the last execution time are also obtained, and the result of the retry strategy is returned according to the retry strategy class; and judging whether the retry is needed to be continued, if so, adding 1 to the retry number, and calculating the time of the next retry. The method comprises the following specific steps:
in the embodiment of the invention, if the fast failure occurs, only one call is initiated. The retry number is set in support, and the parameter retries is used to indicate that the retry is performed 3 times by default, but the retry number can also be set according to the needs of the user. And calling the invoke again, returning after success, and continuing if failure. And when the call failure is less than the retry times, continuing to select the explorer to initiate the call, and when the call times are more than or equal to the retry times, throwing out the call failure exception and giving an alarm through the message. A timeout time limit may also be applied, and if the retry execution time exceeds a preset time, the message alarm is stopped. And tracking and recording each call log and call result.
And step S4, recording and saving the retry result.
Specifically, two tables of current retry data and historical retry data are updated and saved to the database for subsequent retry needs.
In the embodiment, access retry is performed by calling a creation notification method of the fault-tolerant server, retry data pre-stored in a database is read for retry, the retry data is isolated from service logic, and no invasion is caused to an access system.
In a preferable embodiment of this embodiment (see fig. 3), the step S1 further includes:
step S10, receiving the retry data generated by the production end;
in particular, each accessed application is responsible for placing retry data that needs to be retried into a database in memory.
Step S11, storing the retry data in the database;
when the retry is needed, the retry data can be directly read from the database for retry, so that the retry data is isolated from service logic, low coupling is realized, and the access system is not invasive.
In the embodiment, access retry is performed by calling a creation notification method of the fault-tolerant server, retry data pre-stored in a database is read for retry, the retry data is isolated from service logic, and no invasion is caused to an access system.
Secondly, retry times, overtime time, idempotent and other retry mechanisms are added, and resources are saved.
Example two:
as shown in fig. 4, a structure of a fault-tolerant retry terminal according to a second embodiment of the present invention includes: a retry calling unit 1, a data reading unit 2 connected to the retry calling unit 1, a retry unit 3 connected to the data reading unit 2, and a result recording unit 4 connected to the retry unit 3, wherein:
a retry calling unit 1, configured to call a creation notification method of a fault-tolerant server;
specifically, a two-party library is introduced, retry data and business logic are isolated, and retry entering is started by calling a creation notification method of a fault-tolerant server.
A data reading unit 2 for reading retry data pre-stored in the database;
specifically, a createNotify method provided by retryService is called in a method requiring fault tolerance, so as to conveniently insert a fault-tolerant data entity, including a retry strategy. And writing a retry processing class, inheriting a RetryHandlerStrength interface, and accessing fault-tolerant retry. The fault-tolerant retry mechanism is shown in fig. 2 and will not be described herein. The retry data includes: the retry parameter, the retry number and the retry execution time are specifically two tables of the current retry data retry and the historical retry data retry _ history, and the fields of the two tables are the same. See in particular table 1, supra.
In the embodiment of the present invention, the data reading unit 2 acquires a list of retry management to be processed; acquiring a load balance value list to be processed; acquiring the maximum retry times of each scheduled process; a polling statement is then executed to extract a list of retry tasks to be processed.
A retry unit 3, configured to perform a retry according to the retry data to obtain a retry result;
specifically, if the retry is successful, marking the retry result as the retry success and saving the retry result in the database; if the retry fails, the retry result is marked as the retry failure, and the failure reason is recorded. If the retry fails, the number of retries and the last execution time are also obtained, and the result of the retry strategy is returned according to the retry strategy class; and judging whether the retry is needed to be continued, if so, adding 1 to the retry number, and calculating the time of the next retry.
In the embodiment of the invention, if the fast failure occurs, only one call is initiated. The retry number is set in support, and the parameter retries is used to indicate that the retry is performed 3 times by default, but the retry number can also be set according to the needs of the user. And calling the invoke again, returning after success, and continuing if failure. And when the call failure is less than the retry times, continuing to select the explorer to initiate the call, and when the call times are more than or equal to the retry times, throwing out the call failure exception and giving an alarm through the message. A timeout time limit may also be applied, and if the retry execution time exceeds a preset time, the message alarm is stopped. And tracking and recording each call log and call result.
A result recording unit 4 for recording and saving the retry result;
specifically, two tables of current retry data and historical retry data are updated and saved to the database for subsequent retry needs.
In the embodiment, access retry is performed by calling a creation notification method of the fault-tolerant server, retry data pre-stored in a database is read for retry, the retry data is isolated from service logic, and no invasion is caused to an access system.
In a preferred embodiment of this embodiment, as shown in fig. 5, the fault-tolerant retry terminal further includes: a data receiving unit 5 and a data storage unit 6 connected to the data receiving unit 5 and the retry call unit 1, wherein:
a data receiving unit 5 for receiving the retry data generated by the production end;
in particular, each accessed application is responsible for placing retry data that needs to be retried into a database in memory.
The data storage unit 6 is used for: storing the retry data to the database;
when the retry is needed, the retry data can be directly read from the database for retry, so that the retry data is isolated from service logic, low coupling is realized, and the access system is not invasive.
In the embodiment, access retry is performed by calling a creation notification method of the fault-tolerant server, retry data pre-stored in a database is read for retry, the retry data is isolated from service logic, and no invasion is caused to an access system.
Secondly, retry times, overtime time, idempotent and other retry mechanisms are added, and resources are saved.
Example three:
based on the second embodiment, as shown in fig. 6, a structure diagram of a fault-tolerant retry system according to a third embodiment of the present invention is provided, where the fault-tolerant retry system includes: a production end 41, a fault-tolerant retry terminal 42, and a database 43 connected to the production end 41 and the fault-tolerant retry terminal 42, where the specific structure and operation principle of the fault-tolerant retry terminal 42 are substantially the same as those described in the above second embodiment, and are not described herein again;
the application program of the production end 41 stores retry data that needs to be retried in the database 43, and the fault-tolerant retry terminal 42 extracts the retry data from the database 43 and retries the retry data. The specific workpiece flow is shown in fig. 7:
step 1: the production side 41 generates retry data. Retry data is generated for each application of the production side 41 in particular.
Step 2: the fault tolerant retry terminal 42 requests to store data.
And step 3: the data is stored in a database 43.
And 4, step 4: returns the result to the fault-tolerant retry terminal 42.
And 5: the fault-tolerant retry terminal 42 transmits the result to the production end 41.
By doing so, the retry data is stored, and the retry data can be directly obtained from the database 43 for retry.
Step 6: the fault tolerant retry terminal 42 reads the retry data as needed.
And 7: retry data is extracted from the database 43.
And 8: and returning the result. The retry data is returned to the fault-tolerant retry terminal 42.
And step 9: the fault tolerant retry terminal 42 retries based on the retry data.
Step 10: and recording the call log. Such as recording the number of call retries and retry execution times.
Step 11: and recording a call result log.
Step 12: if the retry is successful, the retry data is modified to be retry successful.
Step 13: if the retry fails, the retry time is modified by increasing the retry number.
In step 13, the retry data is also modified to retry failure and the reason for the failure is recorded. If the retry times reach the maximum retry times or the retry execution time is overtime, a message alarm is sent
In the embodiment, access retry is performed by calling a creation notification method of the fault-tolerant server, retry data pre-stored in a database is read for retry, the retry data is isolated from service logic, and no invasion is caused to an access system.
Example four:
fig. 8 is a structural diagram of a service terminal according to a fourth embodiment of the present invention, where the service terminal includes: a memory (memory)51, a processor (processor)52, a communication Interface (communication Interface)53 and a bus 54, wherein the processor 52, the memory 51 and the communication Interface 53 complete mutual communication through the bus 54.
A memory 51 for storing various data;
specifically, the memory 51 is used for storing various data, such as retry data, received data, and the like, and is not limited thereto, and includes a plurality of computer programs.
A communication interface 53 for information transmission between communication devices of the service terminal;
the processor 52 is used to call various computer programs in the memory 51 to execute a fault-tolerant retry method provided in the first embodiment, for example:
calling a creating notification method of the fault-tolerant server;
reading retry data pre-stored in a database;
retrying according to the retrying data to obtain a retrying result;
and recording and saving the retry result.
In the embodiment, access retry is performed by calling a creation notification method of the fault-tolerant server, retry data pre-stored in a database is read for retry, the retry data is isolated from service logic, and no invasion is caused to an access system.
The present invention also provides a memory, which stores a plurality of computer programs, and the computer programs are called by a processor to execute a fault-tolerant retry method according to the first embodiment.
In the invention, access retry is carried out by calling a creation notification method of the fault-tolerant server, retry data pre-stored in a database is read for retry, the retry data is isolated from service logic, and no invasion is caused to an access system.
Secondly, retry times, overtime time, idempotent and other retry mechanisms are added, and resources are saved.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the implementation.
Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present invention. The above description is only for the specific embodiments of the present invention, but the scope of the present invention is not limited thereto, and any person skilled in the art can easily conceive of the changes or substitutions within the technical scope of the present invention, and all the changes or substitutions should be covered within the scope of the present invention. Therefore, the protection scope of the present invention shall be subject to the protection scope of the claims.
Claims (10)
1. A fault tolerant retry method, comprising:
calling a creating notification method of the fault-tolerant server;
reading retry data pre-stored in a database;
retrying according to the retrying data to obtain a retrying result;
and recording and saving the retry result.
2. The fault-tolerant retry method of claim 1, wherein reading the retry data pre-stored in the database is preceded by:
receiving the retry data generated by a production end;
storing the retry data to the database.
3. The fault-tolerant retry method of claim 1, wherein the retry data comprises: retry parameters, retry number, and retry execution time.
4. The fault-tolerant retry method of claim 1, wherein reading retry data pre-stored in a database comprises:
obtaining a list of retry management to be processed;
acquiring a load balance value list to be processed;
acquiring the maximum retry times of each scheduled process;
a list of retry tasks to be processed is extracted.
5. The fault-tolerant retry method of claim 4, wherein the retrying according to the retry data and obtaining the retry result comprises:
if the retry is successful, marking the retry result as the retry success and storing the retry result in the database;
if the retry fails, the retry result is marked as the retry failure, and the failure reason is recorded.
6. The fault-tolerant retry method of claim 5, wherein the retrying according to the retry data and obtaining the retry result further comprises:
if the retry fails, obtaining the number of retries and the last execution time, and returning the result of the retry strategy according to the retry strategy class;
and judging whether the retry is needed to be continued, if so, adding 1 to the retry number, and calculating the time of the next retry.
7. A fault tolerant retry terminal, comprising:
a retry calling unit, which is used for calling the creating notification method of the fault-tolerant server;
the data reading unit is connected with the retry calling unit and used for reading retry data prestored in a database;
the retry unit is connected with the data reading unit and used for retrying according to the retry data and obtaining a retry result;
and the result recording unit is connected with the retry unit and is used for recording and storing the retry result.
8. A fault-tolerant retry system, comprising a production side, a fault-tolerant retry terminal according to claim 7, and a database connected to the production side and the fault-tolerant retry terminal; the application program of the production end stores retry data needing retry in the database, and the fault-tolerant retry terminal extracts the retry data from the database and conducts retry.
9. A memory storing a computer program, the computer program being executable by a processor to perform the steps of:
calling a creating notification method of the fault-tolerant server;
reading retry data pre-stored in a database;
retrying according to the retrying data to obtain a retrying result;
and recording and saving the retry result.
10. A terminal comprising a memory, a processor and a computer program stored in said memory and executable on said processor, characterized in that said processor when executing said computer program implements the steps of the fault tolerant retry method according to any of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811233323.XA CN111078442A (en) | 2018-10-22 | 2018-10-22 | Fault-tolerant retry method and device and terminal |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811233323.XA CN111078442A (en) | 2018-10-22 | 2018-10-22 | Fault-tolerant retry method and device and terminal |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111078442A true CN111078442A (en) | 2020-04-28 |
Family
ID=70309986
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811233323.XA Pending CN111078442A (en) | 2018-10-22 | 2018-10-22 | Fault-tolerant retry method and device and terminal |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111078442A (en) |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112667439A (en) * | 2020-12-26 | 2021-04-16 | 北京奇艺世纪科技有限公司 | Data processing method and device and electronic equipment |
| CN114237748A (en) * | 2021-12-17 | 2022-03-25 | 广州华多网络科技有限公司 | Service retry configuration method, device, equipment, medium and product thereof |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107908494A (en) * | 2017-11-10 | 2018-04-13 | 泰康保险集团股份有限公司 | Processing method, device, electronic equipment and the storage medium of anomalous event |
-
2018
- 2018-10-22 CN CN201811233323.XA patent/CN111078442A/en active Pending
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107908494A (en) * | 2017-11-10 | 2018-04-13 | 泰康保险集团股份有限公司 | Processing method, device, electronic equipment and the storage medium of anomalous event |
Non-Patent Citations (1)
| Title |
|---|
| 唐益鹏;: "基于Spring的异步任务处理系统" * |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112667439A (en) * | 2020-12-26 | 2021-04-16 | 北京奇艺世纪科技有限公司 | Data processing method and device and electronic equipment |
| CN114237748A (en) * | 2021-12-17 | 2022-03-25 | 广州华多网络科技有限公司 | Service retry configuration method, device, equipment, medium and product thereof |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8250543B2 (en) | Software tracing | |
| US6944796B2 (en) | Method and system to implement a system event log for system manageability | |
| US8621282B1 (en) | Crash data handling | |
| CN109815291B (en) | Data synchronization method and device, electronic equipment and storage medium | |
| US8676635B2 (en) | Method and system for managing transactions | |
| CN114925084B (en) | Distributed transaction processing method, system, equipment and readable storage medium | |
| CN111782669B (en) | Method and device for realizing distributed lock and electronic equipment | |
| CN110196759B (en) | Distributed transaction processing method and device, storage medium and electronic device | |
| CN111078442A (en) | Fault-tolerant retry method and device and terminal | |
| CN110599305A (en) | Service processing method, device and storage medium | |
| CN105930226A (en) | Data processing method and apparatus | |
| CN108121774B (en) | Data table backup method and terminal equipment | |
| CN112667439A (en) | Data processing method and device and electronic equipment | |
| WO2020253045A1 (en) | Configured supplementary processing method and device for data of which forwarding has abnormality, and readable storage medium | |
| CN110727523B (en) | Service request processing method, service request processing device and readable storage medium | |
| CN110855658B (en) | Service login method, device, equipment and storage medium | |
| CN110347659B (en) | Data processing method and device and transaction data processing method and device | |
| CN109034668B (en) | ETL task scheduling method, ETL task scheduling device, computer equipment and storage medium | |
| CN111124370A (en) | Data processing method and related equipment | |
| CN106776052B (en) | Shared resource access method and device | |
| US10146644B2 (en) | Integrity of transactional memory of card computing devices in case of card tear events | |
| CN113051008A (en) | Interface request processing method and device, computer equipment and storage medium | |
| CN109034768B (en) | Financial reconciliation method, apparatus, computer device and storage medium | |
| CN113111077A (en) | Consistency control method, consistency control device, electronic equipment, consistency control medium and program product | |
| US10303513B2 (en) | Durable program execution |
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 | ||
| CB02 | Change of applicant information | ||
| CB02 | Change of applicant information |
Address after: 200438 9 / F, 10 / F, 11 / F, 12 / F, 38 Lane 1688, Guoquan North Road, Yangpu District, Shanghai Applicant after: QIANXUN SPATIAL INTELLIGENCE Inc. Address before: Room j165, 1st floor, building 64, 1436 Jungong Road, Yangpu District, Shanghai, 200433 Applicant before: QIANXUN SPATIAL INTELLIGENCE Inc. |
|
| WD01 | Invention patent application deemed withdrawn after publication | ||
| WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20200428 |