CN116166552A - Versioned retry processing method and device, electronic equipment and readable storage medium - Google Patents

Versioned retry processing method and device, electronic equipment and readable storage medium Download PDF

Info

Publication number
CN116166552A
CN116166552A CN202310166014.XA CN202310166014A CN116166552A CN 116166552 A CN116166552 A CN 116166552A CN 202310166014 A CN202310166014 A CN 202310166014A CN 116166552 A CN116166552 A CN 116166552A
Authority
CN
China
Prior art keywords
retry
version number
request
retry request
current version
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
Application number
CN202310166014.XA
Other languages
Chinese (zh)
Inventor
张苏磊
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Beijing Ziroom Information Technology Co Ltd
Original Assignee
Beijing Ziroom Information Technology Co Ltd
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Beijing Ziroom Information Technology Co Ltd filed Critical Beijing Ziroom Information Technology Co Ltd
Priority to CN202310166014.XA priority Critical patent/CN116166552A/en
Publication of CN116166552A publication Critical patent/CN116166552A/en
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/368—Test management for test version control, e.g. updating test cases to a new software version
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
    • Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
    • Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Retry When Errors Occur (AREA)

Abstract

The invention relates to the technical field of computers and discloses a versioned retry processing method, a device, electronic equipment and a readable storage medium. Wherein the method comprises the following steps: obtaining a retry request and a target version number corresponding to the retry request; when the retry execution time is reached, acquiring a current version number corresponding to the retry request; judging whether the current version number is consistent with the target version number; when the current version number is consistent with the target version number, a retry request is performed. By implementing the technical scheme of the invention, whether other request operation service data exist in the retry request waiting time can be monitored, thereby avoiding retry errors, ensuring the test accuracy of the service data and ensuring the retry effect of the service data.

Description

Versioned retry processing method and device, electronic equipment and readable storage medium
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a method and apparatus for processing a retry in versioning, an electronic device, and a readable storage medium.
Background
Currently, some business requirements in the development process inevitably require multiple retries to ensure compliance with the business requirements. Some commonly used retry tools exist, often identified in an annotated manner on the method. Such annotations typically provide additional functions such as retrying several times, retrying when which exceptions are thrown, and the time interval for each retry.
The method for retrying the request is repeatedly called only after a certain time interval depending on the traditional retrying operation, so as to achieve the purpose of retrying. Many times, however, the method is business-oriented, and it is difficult to meet the modification requirements for certain businesses by the method. For example, when an order modification operation is completed, if the modification fails, a retry is performed for more than one minute. However, if there is another request to modify the order within a retry period of one minute, the operation is successful. Then, after one minute, it is not desirable that the retry succeed because the order data is no longer the order data at the time of the modification. At this time, the retry by the above method may lead to a traffic error.
Disclosure of Invention
In view of the above, embodiments of the present invention provide a method, an apparatus, an electronic device, and a readable storage medium for performing a retry process, so as to solve the problem that it is difficult to satisfy the retry effect depending on the retry time interval.
According to a first aspect, an embodiment of the present invention provides a method for processing a retry of versioning, including: obtaining a retry request and a target version number corresponding to the retry request; when the retry execution time is reached, acquiring a current version number corresponding to the retry request; judging whether the current version number is consistent with the target version number; and executing the retry request when the current version number is consistent with the target version number.
The versioning retry processing method provided by the embodiment of the invention compares the target version number of the retry request with the current version number to determine whether the target version number and the current version number are consistent. When the current version number is consistent with the target version number, indicating that there are no other request operations during the retry wait, the retry request may be executed for a safe retry. According to the method, whether other request operation service data exist in the time waiting for retry is monitored, so that retry errors can be avoided, the test accuracy of the service data is ensured, and the retry effect of the service data is ensured.
With reference to the first aspect, in a first implementation manner of the first aspect, after the retry execution time is reached, obtaining a current version number corresponding to the retry request includes: inquiring retry execution time corresponding to the retry request based on the identification information of the retry request; and when the retry execution time is reached, inquiring the current version number corresponding to the retry request based on the identification information.
According to the versioning retry processing method provided by the embodiment of the invention, the corresponding retry execution time is queried through the identification information of the retry request, and the current version number is acquired after the retry execution time is reached, so that whether other requests modify service data in the retry execution time can be determined by pulling the latest version number, the retry processing method is not limited by the retry time interval any more, and accurate retry according to the retry request is facilitated.
With reference to the first implementation manner of the first aspect, in a second implementation manner of the first aspect, when the retry execution time is reached, querying a current version number corresponding to the retry request based on the identification information includes: acquiring the retry times corresponding to the retry request; judging whether the retry times reach preset times or not; and inquiring the current version number corresponding to the retry request based on the identification information when the retry number does not reach the preset number.
With reference to the second implementation manner of the first aspect, in a third implementation manner of the first aspect, the method further includes: and when the retry times reach the preset times, judging that the retry request fails to be executed, and sending out alarm information.
According to the versioned retry processing method provided by the embodiment of the invention, the retry request is prevented from being repeatedly executed by monitoring the retry times of the retry request, the execution is stopped after the retry times reach the preset times, and the alarm information is sent out so as to remind technicians of repairing, so that the test efficiency is ensured.
With reference to the first aspect, in a fourth implementation manner of the first aspect, when the current version number is consistent with the target version number, executing the retry request includes: when the current version number is consistent with the target version number, inquiring a corresponding method name and a corresponding method parameter based on identification information corresponding to the retry request; calling a target method corresponding to the method name and the method parameter; and executing the retry request through the target method.
According to the versioned retry processing method provided by the embodiment of the invention, when the fact that the current version number is consistent with the target version number is detected, the corresponding target method is called to execute the retry request, so that safe execution and accurate execution of the retry request are ensured, and business data errors caused by retry are avoided to the greatest extent.
With reference to the fourth implementation manner of the first aspect, in a fifth implementation manner of the first aspect, the method further includes: and updating the next retry execution time and the number of retries of the retry request.
According to the versioned retry processing method provided by the embodiment of the invention, before the target method is executed, the updated next retry execution time and retry times are convenient for entering retry waiting in time after the retry request fails to execute, so that the execution efficiency of the next retry request is ensured.
With reference to the first aspect, in a sixth implementation manner of the first aspect, the method further includes: and when the current version number is inconsistent with the target version number, generating alarm information aiming at the retry request.
According to the versioning retry processing method provided by the embodiment of the invention, when the fact that the current version number is inconsistent with the target version number is detected, the fact that other requests exist for modifying service data in the period of waiting for retry is indicated, at the moment, the retry request cannot be executed, and alarm information is sent out so that technicians can adjust the retry and retry the retry, and therefore service execution errors can be avoided.
According to a second aspect, an embodiment of the present invention provides a versioned retry processing apparatus, including: the request acquisition module is used for acquiring a retry request and a target version number corresponding to the retry request; the version acquisition module is used for acquiring the current version number corresponding to the retry request after the retry execution time is reached; the judging module is used for judging whether the current version number is consistent with the target version number; and the execution module is used for executing the retry request when the current version number is consistent with the target version number.
According to a third aspect, an embodiment of the present invention provides an electronic device, including: the device comprises a memory and a processor, wherein the memory and the processor are in communication connection, the memory stores computer instructions, and the processor executes the computer instructions, so as to execute the versioned retry processing method according to the first aspect or any implementation manner of the first aspect.
According to a fourth aspect, an embodiment of the present invention provides a computer readable storage medium storing computer instructions for causing a computer to perform the method of the first aspect or any implementation of the first aspect.
It should be noted that, the embodiments of the present invention provide corresponding beneficial effects of the versioned retry processing apparatus, the electronic device, and the computer readable storage medium, please refer to the description of the corresponding content in the versioned retry processing method, which is not repeated herein.
Drawings
In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings that are needed in the description of the embodiments or the prior art will be briefly described, and it is obvious that the drawings in the description below are some embodiments of the present invention, and other drawings can be obtained according to the drawings without inventive effort for a person skilled in the art.
FIG. 1 is a flow chart of a versioned retry processing method in accordance with an embodiment of the present invention;
FIG. 2 is another flow diagram of a versioned retry processing method in accordance with an embodiment of the present invention;
FIG. 3 is yet another flow chart of a versioned retry processing method in accordance with an embodiment of the present invention;
FIG. 4 is a block diagram of a versioned retry processing apparatus according to an embodiment of the present invention;
fig. 5 is a schematic diagram of a hardware structure of an electronic device according to an embodiment of the present invention.
Detailed Description
For the purpose of making the objects, technical solutions and advantages of the embodiments of the present invention more apparent, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings in the embodiments of the present invention, and it is apparent that the described embodiments are some embodiments of the present invention, but not all embodiments of the present invention. All other embodiments, which can be made by those skilled in the art based on the embodiments of the invention without making any inventive effort, are intended to be within the scope of the invention.
Currently, some business requirements in the development process inevitably require multiple retries to ensure compliance with the business requirements. Some commonly used retry tools exist, often identified in an annotated manner on the method. Such annotations typically provide additional functions such as retrying several times, retrying when which exceptions are thrown, and the time interval for each retry.
However, such retry tools do not meet all business requirements, taking order business data as an example: when a modification operation is needed for a certain order amount (the order amount is changed from 100 yuan to 200 yuan), if the setting of the current request fails, the retry can be performed after one minute. However, during this minute, if there is another request to make a modification to the order (e.g., the shipping address of the order is modified), and the request is successfully executed. Then, after one minute, when the first request begins a retry, the order data is no longer the order data at the time of the modification. Even if the retry is successful at this time, it is not meaningful to embody a modification test for the order amount.
Based on the above, the technical scheme of the invention introduces the version number, applies a new version number for each request, carries the applied target version number for retry, and can perform safe retry if the target version number is consistent with the latest version number, which means that no other request modifies service data during the retry waiting period; otherwise, no retry can be performed.
In accordance with an embodiment of the present invention, there is provided an embodiment of a versioned retry processing method, it being noted that the steps illustrated in the flowchart of the figures may be performed in a computer system, such as a set of computer executable instructions, and, although a logical order is illustrated in the flowchart, in some cases, the steps illustrated or described may be performed in an order other than that illustrated herein.
In this embodiment, a method for performing versioning retry processing is provided, which may be used in an electronic device, such as a mobile phone, a computer, a tablet computer, etc., fig. 1 is a flowchart of the method for performing versioning retry processing according to an embodiment of the present invention, and as shown in fig. 1, the flowchart includes the following steps:
s11, obtaining the retry request and the target version number corresponding to the retry request.
The retry request is a request to wait for a retry after a failure to request modification of the service data, each retry request corresponding to a respective independent thread. The target version number is the service version number when the modification of the service data is requested for the first time.
The electronic device maintains a version number table, and the version number table maintains the version number according to a preset dimension, for example, according to the dimension of the order number. When the electronic equipment receives a retry request for modifying service data, determining the dimension corresponding to the retry request, and then determining the target version number corresponding to the dimension by querying the version number table.
And S12, after the retry execution time is reached, acquiring the current version number corresponding to the retry request.
The current version number is the latest version number corresponding to the retry request, and the version number is updated once every time the service method is called for each request. The retry execution time is the time interval for waiting for a retry after the request execution fails. When the retry request fails to execute, the electronic device may re-query the version number table to determine a current version number corresponding to the retry request when the retry execution time is reached.
S13, judging whether the current version number is consistent with the target version number.
The current version number is compared with the target version number to determine if the two are consistent. If the current version number is consistent with the target version number, step S14 is executed, otherwise, other operations are executed. The other operations may be to pull the current version number again to compare with the target version number again, or determine that the retry request is not executable, which is not limited herein, and may be determined by those skilled in the art according to actual needs.
And S14, when the current version number is consistent with the target version number, executing a retry request.
When the current version number is consistent with the target version number, the retry request is indicated that no other requests modify the service data in the process of waiting for the retry, and at this time, the electronic device can call a corresponding method to execute the retry request to operate on the service data.
The versioning retry processing method provided in this embodiment compares the target version number of the retry request with the current version number to determine whether the target version number and the current version number are consistent. When the current version number is consistent with the target version number, indicating that there are no other request operations during the retry wait, the retry request may be executed for a safe retry. According to the method, whether other request operation service data exist in the time waiting for retry is monitored, so that retry errors can be avoided, the test accuracy of the service data is ensured, and the retry effect of the service data is ensured.
In this embodiment, a method for performing versioning retry processing is provided, which may be used in an electronic device, such as a mobile phone, a computer, a tablet computer, etc., fig. 2 is a flowchart of the method for performing versioning retry processing according to an embodiment of the present invention, and as shown in fig. 2, the flowchart includes the following steps:
s21, obtaining a retry request and a target version number corresponding to the retry request.
The detailed description refers to the corresponding related descriptions of the above embodiments, and will not be repeated here.
S22, when the retry execution time is reached, the current version number corresponding to the retry request is obtained.
The electronic equipment is maintained with a version number table, the version number table stores the latest version number corresponding to the service data, and after any one of the version number tables requests to modify the service data and the modification is successful, a new version number is generated. The version number table can be maintained according to the dimension of the service data, so that whether the version number corresponding to the retry request is modified or not is determined. For example, the version number table includes a field "dimension" and a "latest version number", if the "dimension" is a001, when the retry request is to modify the service data of the dimension a001, the latest version number corresponding to the dimension a001 is first searched from the version number table, and if not, a piece of data is inserted from 1, i.e. in the version number table: dimension = a001, latest version number = 1; if so, the latest version number is incremented by 1 and the incremented value is returned.
Meanwhile, a retry table is maintained in the electronic device, and the retry table contains fields of 'request id', 'method name to be executed', 'method parameter', 'next retry execution time', 'retry times', 'execution result (no result, success, failure)', 'dimension', 'version number'. Specifically, each time a request is executed, a globally unique request id is allocated to the request, and, taking the dimension a001 as an example, a piece of data is inserted into the retry table: request id=globally unique id, method name to be executed=test, method parameter=xxx, next retry execution time=time of year, month, day, minute, number of retries=1, execution result=no result, dimension=a001, version number=1.
Accordingly, the step S22 may include:
s221, inquiring the retry execution time corresponding to the retry request based on the identification information of the retry request.
The identification information is a unique identification of the retry request, and the identification information is a global unique identification. And inquiring the retry table according to the identification information to determine the next retry execution time corresponding to the retry table.
S222, inquiring the current version number corresponding to the retry request based on the identification information when the retry execution time is reached.
When the retry execution time is reached, the dimension corresponding to the retry request can be determined by querying the retry table according to the identification information, and then the latest version number corresponding to the retry request can be determined by querying the version number table according to the dimension, wherein the latest version number is the current version number corresponding to the retry request.
When the retry execution time is reached, the electronic device may determine the corresponding current version number by querying the version number table, and if the current version number is consistent with the target version number, execute the retry request. If the retry request fails to execute, no operation is needed, and the retry request is executed again as long as the next execution time is reached. However, for the service test efficiency, it is not possible to perform infinite retry, and at this time, the number of retries needs to be detected to determine whether to continue the retry. Accordingly, the step S222 may include:
(1) And obtaining the retry times corresponding to the retry request.
(2) And judging whether the retry times reach the preset times.
(3) And inquiring the current version number corresponding to the retry request based on the identification information when the retry number does not reach the preset number.
(4) When the retry number reaches the preset number, judging that the execution of the retry request fails and sending out alarm information.
The retry times are the times of repeated execution of the same request, and each time the execution record aiming at the retry request is queried, the retry times are accumulated for 1 time. The retry times are recorded in a retry table, and the corresponding retry times can be determined by querying the retry table through the identification information of the retry request.
The preset number of times is a preset maximum allowed number of retries. Comparing the inquired retry times with preset times to determine whether the retry times reach the preset times.
If the retry number does not reach the preset number, it means that the retry can be performed, and then the retry table can be queried according to the identification information to determine the dimension corresponding to the retry request, and then the version number table is queried according to the dimension to determine the corresponding current version number.
If the retry number reaches the preset number, the maximum retry number is reached, and the retry is not possible. At this time, the "execution result" corresponding to the retry request may be set as failed directly. And simultaneously, alarm information is sent out to remind corresponding technicians of the failure of executing the request, so that the technicians can conveniently take corresponding measures according to the alarm information.
S23, judging whether the current version number is consistent with the target version number.
The detailed description refers to the corresponding related descriptions of the above embodiments, and will not be repeated here.
And S24, when the current version number is consistent with the target version number, executing a retry request.
The detailed description refers to the corresponding related descriptions of the above embodiments, and will not be repeated here.
It should be noted that, the electronic device is provided with a corresponding independent thread for each retry request, and the independent thread can continuously scan the retry list, take out the retry request record that the execution time of the next retry is less than or equal to the current time and the execution result=no result, and then compare whether the retry times reach the preset times. If the preset times are reached, setting the execution result as failure; if the number of times of the retry request does not reach the preset number of times, the retry table is queried to determine a target version number corresponding to the retry request, and if the target version number of the retry request is consistent with the corresponding current version number in the version number table, the retry request is indicated to have no other requests for modifying service data in the process of waiting for the retry, so that the retry request can be safely retried; otherwise, it is indicated that the service data is modified and no retry can be performed.
According to the versioned retry processing method provided by the embodiment, the corresponding retry execution time is queried through the identification information of the retry request, and the current version number of the retry request is acquired after the retry execution time is reached, so that whether other requests modify service data in the retry execution time can be determined by pulling the latest version number, the retry request is not limited by the retry time interval any more, and accurate retry according to the retry request is facilitated. The retry request is prevented from being repeatedly executed by monitoring the retry number of the retry request, execution is stopped after the retry number reaches the preset number, and alarm information is sent out so as to remind technicians of repairing, so that the test efficiency is ensured.
In this embodiment, a method for performing versioning retry processing is provided, which may be used in an electronic device, such as a mobile phone, a computer, a tablet computer, etc., fig. 3 is a flowchart of the method for performing versioning retry processing according to an embodiment of the present invention, and as shown in fig. 3, the flowchart includes the following steps:
s31, obtaining a retry request and a target version number corresponding to the retry request.
The detailed description refers to the corresponding related descriptions of the above embodiments, and will not be repeated here.
S32, when the retry execution time is reached, the current version number corresponding to the retry request is obtained.
The detailed description refers to the corresponding related descriptions of the above embodiments, and will not be repeated here.
S33, judging whether the current version number is consistent with the target version number.
The current version number is compared with the target version number to determine if the two are consistent. If the current version number is consistent with the target version number, step S34 is executed, otherwise step S35 is executed.
And S34, executing a retry request when the current version number is consistent with the target version number.
When the current version number is consistent with the target version number, the condition that no other request for modifying the service data exists in the retry waiting period is indicated, and then the safe retry can be performed. Specifically, the step S34 may include:
s341, when the current version number is consistent with the target version number, inquiring the corresponding method name and the corresponding method parameter based on the identification information corresponding to the retry request.
When the current version number is consistent with the target version number, the retry request can be executed again, and at this time, a retry table can be queried according to the identification information corresponding to the retry request, and a method name and a method parameter required for executing the retry request can be extracted from the retry table. For example, the "method name to be executed" is a test method, and a parameter of the test method is an orderId attribute value of an order object. For the explanation of the retry list, reference is made to the above embodiments, and the details are not repeated here.
S342, calling a target method corresponding to the method name and the method parameter, and executing the retry request through the target method.
And calling a corresponding target method according to the method name and the method parameters, and executing the retry request through the target method to finish the modification of the retry request on the service data. If the retry request is successfully executed, modifying the execution result to be successful; otherwise, retry or alarm is performed.
As an optional implementation manner, in order to ensure that the next retry waiting can be timely entered after the execution failure of the retry request, the execution efficiency of the next retry request is ensured. The method may further include, before determining that the retry request can be performed: the next retry execution time and the number of retries of the retry request are updated.
The next retry execution time is generated according to the retry time interval, the current time of executing the retry request is used as the starting time of determining the next retry execution time, and the retry time interval is added on the basis of the starting time to obtain the next retry execution time. The retry number is the number of times the current retry request is repeatedly executed, and the retry number is accumulated for 1 time each time the retry request is executed.
When it is determined that the current version number of the retry request is identical to the target version number, the corresponding next retry execution time and number of retries are updated in the retry table to determine the time at which the retry request is executed again and the number of times the retry request is executed.
And S35, when the current version number is inconsistent with the target version number, generating alarm information aiming at the retry request.
When the current version number is inconsistent with the target version number, the service data is modified by other requests during the period that the retry request waits for retry, at this time, for the test accuracy of the service data, the retry is not performed, the execution result is set as failure, and meanwhile, alarm information is generated to remind technicians to intervene, so that the technicians can conveniently adjust retry parameters or retry strategies in time, and the re-execution of the retry request is ensured.
The above method is described here by way of specific example as follows:
(1) Receiving a first request for modifying service data with dimension A001, and inserting a piece of data into a version number table: dimension=a001, latest version number=1.
(2) The first request calls a test method to modify the service data, and if the request fails to execute, a retry waiting process is entered. When the first request is retried again, the request is a retry request.
(3) If the first request calls the test method in the process of waiting for retry, the first request searches the latest version number of the current A001 from the version number table, finds that the latest version number is 1, if the first request executes 2, the first request is accumulated by 1 on the basis of the current version number, and returns the latest version number to be 2.
(4) The other request continues with the following flow.
(5) At this point the first request is up to the retry execution time, but its target version number in the retry record is 1, at which point the version number table is queried again. When the latest version number corresponding to A001 is determined to be 2, which indicates that the service data is modified during the period of waiting for retry, the first request for retry failure can be determined, and alarm information is sent to remind technicians of intervention.
According to the versioned retry processing method provided by the embodiment, when the fact that the current version number is consistent with the target version number is detected, the corresponding target method is called to execute the retry request, so that safe execution and accurate execution of the retry request are guaranteed, and business data errors caused by retry are avoided to the greatest extent. When the fact that the current version number is inconsistent with the target version number is detected, the fact that other requests exist during the period of waiting for retry to modify service data is indicated, at the moment, the retry request cannot be executed, alarm information is sent out so that technicians can adjust the retry request and then retry the retry request, and therefore errors in service execution can be avoided.
In this embodiment, a retry processing apparatus for version is further provided, and this apparatus is used to implement the foregoing embodiments and preferred embodiments, and will not be described in detail. As used below, the term "module" may be a combination of software and/or hardware that implements a predetermined function. While the means described in the following embodiments are preferably implemented in software, implementation in hardware, or a combination of software and hardware, is also possible and contemplated.
The present embodiment provides a versioned retry processing apparatus, as shown in fig. 4, including:
the request acquisition module 41 is configured to acquire a retry request and a target version number corresponding to the retry request.
The version obtaining module 42 is configured to obtain a current version number corresponding to the retry request when the retry execution time is reached.
And a judging module 43, configured to judge whether the current version number is consistent with the target version number.
An execution module 44 for executing a retry request when the current version number matches the target version number.
Alternatively, the version acquisition module 42 may include:
and the first inquiring sub-module is used for inquiring the retry execution time corresponding to the retry request based on the identification information of the retry request.
And the second inquiry sub-module is used for inquiring the current version number corresponding to the retry request based on the identification information when the retry execution time is reached.
Optionally, the second query sub-module is specifically configured to: obtaining the retry times corresponding to the retry request; judging whether the retry number reaches a preset number; inquiring the current version number corresponding to the retry request based on the identification information when the retry number does not reach the preset number; when the retry number reaches the preset number, judging that the execution of the retry request fails and sending out alarm information.
Alternatively, the execution module 44 may include:
and the third inquiry sub-module is used for inquiring the corresponding method name and the method parameter based on the identification information corresponding to the retry request when the current version number is consistent with the target version number.
And the calling execution sub-module is used for calling a target method corresponding to the method name and the method parameter, and executing the retry request through the target method.
Optionally, the execution module 44 may further include:
and the updating sub-module is used for updating the next retry execution time and the retry times of the retry request.
Optionally, the above versioned retry processing apparatus may further include:
and the alarm module is used for generating alarm information aiming at the retry request when the current version number is inconsistent with the target version number.
The versioned retry processing apparatus in this embodiment is presented in the form of functional units, where units refer to ASIC circuits, processors and memories executing one or more software or firmware programs, and/or other devices that can provide the functionality described above.
Further functional descriptions of the above modules and sub-modules are the same as those of the above corresponding embodiments, and are not repeated here.
The versioned retry processing apparatus provided in this embodiment determines whether the target version number of the retry request is identical to the current version number by comparing the target version number with the current version number. When the current version number is consistent with the target version number, indicating that there are no other request operations during the retry wait, the retry request may be executed for a safe retry. The device monitors whether other request operation service data exist in the time waiting for retry by the retry request, thereby avoiding retry errors, ensuring the test accuracy of the service data and ensuring the retry effect of the service data.
The embodiment of the invention also provides electronic equipment, which is provided with the versioning retry processing device shown in the figure 4.
Referring to fig. 5, fig. 5 is a schematic structural diagram of an electronic device according to an alternative embodiment of the present invention, and as shown in fig. 5, the electronic device may include: at least one processor 501, such as a central processing unit (Central Processing Unit, CPU), at least one communication interface 503, a memory 504, at least one communication bus 502. Wherein a communication bus 502 is used to enable connected communications between these components. The communication interface 503 may include a Display screen (Display), a Keyboard (Keyboard), and the optional communication interface 503 may further include a standard wired interface, and a wireless interface. The memory 504 may be a high-speed volatile random access memory (Random Access Memory, RAM) or a non-volatile memory (non-volatile memory), such as at least one disk memory. The memory 504 may also optionally be at least one storage device located remotely from the aforementioned processor 501. Wherein the processor 501 may have stored in the memory 504 an application program in the apparatus described in connection with fig. 4 and the processor 501 invokes the program code stored in the memory 504 for performing any of the above-mentioned method steps.
The communication bus 502 may be, among other things, a peripheral component interconnect standard (peripheral component interconnect, PCI) bus or an extended industry standard architecture (extended industry standard architecture, EISA) bus, etc. The communication bus 502 may be divided into an address bus, a data bus, a control bus, and the like. For ease of illustration, only one thick line is shown in fig. 5, but not only one bus or one type of bus.
Wherein the memory 504 may include volatile memory (RAM), such as random-access memory (RAM); the memory may also include a nonvolatile memory (non-volatile memory), such as a flash memory (flash memory), a hard disk (HDD) or a Solid State Drive (SSD); memory 504 may also include a combination of the types of memory described above.
The processor 501 may be a central processing unit (central processing unit, CPU), a network processor (network processor, NP) or a combination of CPU and NP, among others.
The processor 501 may further include a hardware chip, among others. The hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (programmable logic device, PLD), or a combination thereof. The PLD may be a complex programmable logic device (complex programmable logic device, CPLD), a field-programmable gate array (field-programmable gate array, FPGA), general-purpose array logic (generic array logic, GAL), or any combination thereof.
Optionally, the memory 504 is also used for storing program instructions. The processor 501 may invoke program instructions to implement the versioned retry processing method as shown in the above-described embodiments of the present application.
The embodiment of the invention also provides a non-transitory computer storage medium, which stores computer executable instructions that can execute the versioned retry processing method in any of the above method embodiments. The storage medium may be a magnetic Disk, an optical disc, a Read-Only Memory (ROM), a random access Memory (Random Access Memory, RAM), a Flash Memory (Flash Memory), a Hard Disk (HDD), a Solid State Drive (SSD), or the like; the storage medium may also comprise a combination of memories of the kind described above.
Although embodiments of the present invention have been described in connection with the accompanying drawings, various modifications and variations may be made by those skilled in the art without departing from the spirit and scope of the invention, and such modifications and variations fall within the scope of the invention as defined by the appended claims.

Claims (10)

1. A method of versioning retry processing, comprising:
obtaining a retry request and a target version number corresponding to the retry request;
when the retry execution time is reached, acquiring a current version number corresponding to the retry request;
judging whether the current version number is consistent with the target version number;
and executing the retry request when the current version number is consistent with the target version number.
2. The method of claim 1, wherein the obtaining the current version number corresponding to the retry request after the retry execution time is reached comprises:
inquiring retry execution time corresponding to the retry request based on the identification information of the retry request;
and when the retry execution time is reached, inquiring the current version number corresponding to the retry request based on the identification information.
3. The method according to claim 2, wherein the querying the current version number corresponding to the retry request based on the identification information when the retry execution time is reached comprises:
acquiring the retry times corresponding to the retry request;
judging whether the retry times reach preset times or not;
and inquiring the current version number corresponding to the retry request based on the identification information when the retry number does not reach the preset number.
4. A method according to claim 3, further comprising:
and when the retry times reach the preset times, judging that the retry request fails to be executed, and sending out alarm information.
5. The method of claim 1, wherein the executing the retry request when the current version number matches the target version number comprises:
when the current version number is consistent with the target version number, inquiring a corresponding method name and a corresponding method parameter based on identification information corresponding to the retry request;
and calling a target method corresponding to the method name and the method parameter, and executing the retry request through the target method.
6. The method as recited in claim 5, further comprising:
and updating the next retry execution time and the number of retries of the retry request.
7. The method as recited in claim 1, further comprising:
and when the current version number is inconsistent with the target version number, generating alarm information aiming at the retry request.
8. A versioned retry processing apparatus, comprising:
the request acquisition module is used for acquiring a retry request and a target version number corresponding to the retry request;
the version acquisition module is used for acquiring the current version number corresponding to the retry request after the retry execution time is reached;
the judging module is used for judging whether the current version number is consistent with the target version number;
and the execution module is used for executing the retry request when the current version number is consistent with the target version number.
9. An electronic device, comprising:
a memory and a processor, the memory and the processor being communicatively coupled to each other, the memory having stored therein computer instructions, the processor executing the computer instructions to perform the versioned retry processing method of any of claims 1-7.
10. A computer readable storage medium storing computer instructions for causing a computer to perform the versioned retry processing method of any of claims 1-7.
CN202310166014.XA 2023-02-15 2023-02-15 Versioned retry processing method and device, electronic equipment and readable storage medium Pending CN116166552A (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202310166014.XA CN116166552A (en) 2023-02-15 2023-02-15 Versioned retry processing method and device, electronic equipment and readable storage medium

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202310166014.XA CN116166552A (en) 2023-02-15 2023-02-15 Versioned retry processing method and device, electronic equipment and readable storage medium

Publications (1)

Publication Number Publication Date
CN116166552A true CN116166552A (en) 2023-05-26

Family

ID=86411114

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202310166014.XA Pending CN116166552A (en) 2023-02-15 2023-02-15 Versioned retry processing method and device, electronic equipment and readable storage medium

Country Status (1)

Country Link
CN (1) CN116166552A (en)

Similar Documents

Publication Publication Date Title
CN110069572B (en) HIVE task scheduling method, device, equipment and storage medium based on big data platform
CN113127347B (en) Interface testing method, device, equipment and readable storage medium
CN110515795B (en) Big data component monitoring method and device and electronic equipment
CN108255620B (en) Service logic processing method, device, service server and system
CN108959067B (en) Method and device for testing search engine and computer readable storage medium
CN110716878B (en) Automatic interface testing method, device and system
CN110647562B (en) Data query method and device, electronic equipment and storage medium
CN110737594A (en) Database standard conformance testing method and device for automatically generating test cases
CN108121774B (en) Data table backup method and terminal equipment
CN110063042A (en) A kind of response method and its terminal of database failure
WO2019148657A1 (en) Method for testing associated environments, electronic device and computer readable storage medium
CN114528201A (en) Abnormal code positioning method, device, equipment and medium
CN117234781A (en) Method, device, equipment and medium for correcting option value of setting option
CN116166552A (en) Versioned retry processing method and device, electronic equipment and readable storage medium
CN112416648A (en) Data verification method and device
CN108399196B (en) Automatic sql execution method and system of database sql statement automatic generation tool
CN110647463A (en) Method and device for restoring test breakpoint and electronic equipment
CN110807037B (en) Data modification method and device, electronic equipment and storage medium
CN113761005A (en) Metadata configuration method and device, electronic equipment and storage medium
CN109446462B (en) Page-based data monitoring processing method, device, equipment and storage medium
CN113238901A (en) Multi-device automatic testing method and device, storage medium and computer device
CN114968753A (en) Equipment upgrading test method, medium, electronic equipment and test system
CN112612773A (en) Database synchronization test method and device, computer equipment and storage medium
CN112631929A (en) Test case generation method and device, storage medium and electronic equipment
CN115129355B (en) Page repair method, system and computer equipment thereof

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