阅读说明：本技术 一种实现业务幂等的方法、装置、设备和介质 (Method, device, equipment and medium for realizing service idempotency ) 是由 刘鹏 于 2021-08-10 设计创作，主要内容包括：本申请提供了一种实现业务幂等的方法、装置、设备和介质,其中,方法包括：扫描业务代码,从业务代码中确定目标对象,为目标对象加锁,并执行目标对象,在目标对象执行完后,将加在目标对象上的锁释放。由此可见,本申请提供的实现业务幂等的方法使得在实现业务幂等的过程中,开发人员仅在业务代码中的目标对象上增加注解即可,无需针对各目标对象额外编写代码,对开发人员更友好,并且使用成本较低。(The application provides a method, a device, equipment and a medium for realizing service idempotent, wherein the method comprises the following steps: scanning the service code, determining a target object from the service code, locking the target object, executing the target object, and releasing the lock added to the target object after the target object is executed. Therefore, the method for realizing the business idempotent provided by the application enables developers to add annotations only on the target objects in the business codes in the process of realizing the business idempotent, does not need to write codes additionally for all the target objects, is more friendly to the developers, and has lower use cost.)

1. A method for implementing idempotent services, comprising:

scanning business codes, and determining a target object from the business codes, wherein the target object is an object to be subjected to idempotent operation, and the target object is marked with annotations;

locking the target object and executing the target object;

and releasing the lock added on the target object after the target object is executed.

2. The method for implementing idempotent services according to claim 1, wherein the locking the target object comprises:

generating a tangent plane AOP corresponding to the target object;

locking the target object based on the tangent plane AOP;

the releasing of the lock added on the target object comprises:

releasing a lock applied to the target object based on the tangent plane AOP.

3. The method for implementing idempotent services according to claim 1 or 2, further comprising:

if the business exception occurs in the process of executing the target object, intercepting the target object and releasing the lock added on the target object.

4. The method for implementing idempotent of business according to any of claims 1-3, wherein releasing the lock added to the target object after the target object has executed comprises:

if the target object is successfully executed, determining whether the thread where the target object is located is in a locked state;

and if so, releasing the lock added on the target object.

5. The method for implementing idempotent of business as claimed in claim 4, wherein the added lock on the target object is set with a timeout;

the method for realizing the service idempotent further comprises the following steps:

periodically scanning locks added on the target object based on asynchronous timing tasks inside the locks added on the target object;

and if the lock on the target object is released within the overtime time and the release fails, automatically releasing the lock added on the target object.

6. The method for implementing idempotent services according to claim 5, wherein the method for implementing idempotent services further comprises:

and if the lock releasing operation is not executed on the lock on the target object within the overtime time, prolonging the overtime time.

7. The method for implementing idempotent of business as claimed in claim 1 wherein the lock added on the target object is an optimistic lock or a Redis-based distributed lock.

8. An apparatus for implementing idempotent services, comprising: the device comprises a code scanning module, a locking module and a lock releasing module;

the code scanning module is used for scanning the business codes and determining a target object from the business codes, wherein the target object is an object to be subjected to idempotent operation, and the target object is marked with an annotation;

the locking module is used for locking the target object and executing the target object;

and the lock releasing module is used for releasing the lock added on the target object after the target object is executed.

9. An apparatus for implementing idempotent services, comprising a memory and a processor;

the memory is used for storing programs;

the processor is used for executing the program to realize the steps of the method for realizing the idempotent of business according to any one of claims 1 to 7.

10. A computer-readable storage medium, on which a computer program is stored which, when being executed by a processor, carries out the steps of the method for idempotent of business as claimed in any of claims 1 to 7.

Technical Field

The present application relates to the field of computer technologies, and in particular, to a method, an apparatus, a device, and a medium for implementing idempotent services.

Background

In a complex distributed system, idempotent of interfaces is a fundamental requirement. For example, when a shopping cart is submitted, the user may request the order interface many times due to network jitter or frequent clicks, and the order interface should be idempotent with respect to the shopping cart flow number.

The target object can be locked and released based on the distributed lock, namely the object to be subjected to idempotent operation is locked and released based on the distributed lock, so that the target object is prevented from being repeatedly executed, and the service idempotent is ensured, for example, the target object is locked and released based on the distributed lock uniquely indexed by the database; locking and releasing a lock for a target object based on the database optimistic lock; locking and releasing a lock for a target object based on a pessimistic lock of a database; locking and releasing a lock for a target object based on a distributed lock realized by redis; locking and releasing a lock for a target object based on a zookeeper lock; and so on.

Currently, developers are generally required to write codes additionally for each target object to lock and release locks for the target object based on a distributed lock, for example, when a distributed lock based on a unique database index locks and releases locks for a target object in business codes, the developers are required to write codes for locking, releasing locks, compensating, exception handling and the like in the business codes. However, writing additional code is not developer friendly and the use of existing distributed locks is typically costly.

Disclosure of Invention

In view of this, the present application provides a method and an apparatus for implementing business idempotent, so as to solve the problems in the prior art that extra written codes are not friendly to developers and the use cost of a distributed lock is high, and the technical scheme is as follows:

a method of implementing idempotent services, comprising:

scanning the service code, and determining a target object from the service code, wherein the target object is an object to be subjected to idempotent operation, and the target object is marked with notes;

locking the target object and executing the target object;

and releasing the lock added on the target object after the target object is executed.

Optionally, locking the target object includes:

generating a tangent plane AOP corresponding to the target object;

locking the target object based on the section AOP;

releasing a lock applied to a target object, comprising:

and releasing the lock added on the target object based on the section AOP.

Optionally, the method further includes:

if the business exception occurs in the process of executing the target object, the target object is intercepted, and the lock added on the target object is released.

Optionally, after the target object is executed, releasing the lock added to the target object includes:

if the target object is successfully executed, determining whether the thread where the target object is located is in a locked state;

if yes, releasing the lock added on the target object.

Optionally, the lock added to the target object is set to have a timeout;

the method for realizing the service idempotent further comprises the following steps:

periodically scanning the locks added on the target object based on asynchronous timing tasks inside the locks added on the target object;

if the lock on the target object is released within the overtime and the release fails, the lock added on the target object is automatically released.

Optionally, the method for implementing service idempotency, further includes:

and if the lock releasing operation is not executed on the lock on the target object within the timeout time, prolonging the timeout time.

Optionally, the lock added on the target object is an optimistic lock or a Redis-based distributed lock.

An apparatus for implementing idempotent services, comprising: the device comprises a code scanning module, a locking module and a lock releasing module;

the code scanning module is used for scanning the business codes and determining a target object from the business codes, wherein the target object is an object to be subjected to idempotent operation, and the target object is marked with notes;

the locking module is used for locking the target object and executing the target object;

and the lock releasing module is used for releasing the lock added on the target object after the target object is executed.

An apparatus for implementing idempotent of traffic, comprising a memory and a processor;

the memory is used for storing programs;

the processor is configured to execute the program to implement the steps of any one of the above-mentioned methods for implementing idempotent services.

A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the steps of the method for idempotent realization as claimed in any of the preceding claims.

According to the technical scheme, the method for realizing the service power and the like, provided by the application, comprises the steps of scanning the service code, determining the target object from the service code, locking the target object, executing the target object, and releasing the lock added to the target object after the target object is executed. Therefore, the method for realizing the business idempotent provided by the application enables developers to add annotations only on the target objects in the business codes in the process of realizing the business idempotent, does not need to write codes additionally for all the target objects, is more friendly to the developers, and has lower use cost.

Drawings

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

Fig. 1 is a schematic flowchart of a method for implementing idempotent services according to an embodiment of the present disclosure;

fig. 2 is a schematic structural diagram of an apparatus for implementing idempotent services according to an embodiment of the present disclosure;

fig. 3 is a block diagram of a hardware structure of a device for implementing idempotent services according to an embodiment of the present application.

Detailed Description

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.

An idempotent operation is characterized in that the influence of any multiple execution is the same as that of one execution, and the idempotent method means that the operation can be repeatedly executed by using the same parameters and the same result can be obtained. As introduced in the background art, when locking and releasing a lock for a target object based on a distributed lock, developers are required to write codes for locking, releasing the lock, compensating, exception handling, and the like in service codes, which is not friendly to developers. In addition, the use cost of the existing distributed lock is generally high, for example, when the zookeeper lock is used, zookeeper middleware needs to be introduced, and the operation and maintenance cost is increased.

In order to solve the problems of the prior art, the inventors of the present invention thought, after intensive research: an annotation @ Lock may be added to a target object in the business code by a developer, and then the business code may be scanned to determine the target object from the business code based on the scanned annotation, and Lock and release the Lock for the target object. Based on this, the inventor proposes a method for implementing a business idempotent, and the following embodiments will describe the method for implementing a business idempotent provided in the present application in detail.

Referring to fig. 1, a schematic flowchart of a method for implementing business idempotent provided in an embodiment of the present application is shown, where the method for implementing business idempotent may include:

step S101, scanning the service code, and determining the target object from the service code.

Wherein the target object is annotated.

When business exponentiation and the like need to be realized, a developer can add an annotation @ Lock to a target object in the business code, wherein the annotation is used for indicating that the target object is an object to be subjected to idempotent operation.

This step may scan the business code to determine the target object from the business code based on the scanned annotations for subsequent steps to lock and release the lock for the target object.

Optionally, in this step, the adding of annotations to the target object by the developer includes two ways:

first, annotations are added across the target object.

In this embodiment, if the annotation is added to the entire target object, the subsequent locking operation is performed on the entire target object, that is, after the target object is executed once, the target object may be executed again after the lock added to the target object is released.

In the second mode, when adding annotation to the target object, the business key needing to be locked is manually specified.

Here, the service key may be identification information of the user, such as a user ID, a mobile phone number, and the like.

In this embodiment, if a service key that needs to be locked is manually specified when adding an annotation to a target object, the subsequent locking operation is directed to the target object corresponding to the service key.

Taking a scene that the shopping cart creates an order as an example, when the shopping cart submits, due to network jitter or frequent clicking of a user, the user may request the order creation interface for multiple times, the order creation interface should be idempotent for the serial number of the shopping cart, at this time, the uuid field of the order can be used as a service key needing locking, and the implementation logic is substantially as follows.

The difference between the two modes is illustrated below by way of example, and the target object is assumed to be a payment method.

For the first mode:

if the annotation is added to the whole payment method, the subsequent locking aims at the whole payment method, namely, the user A locks the payment method during payment, the user B cannot pay after the locking, the user B can pay only after the payment of the user A is finished and the lock added on the payment method is released, the user B also locks the payment method during payment, the user A cannot pay after the locking, and the user A can pay again only after the payment of the user B is finished and the lock added on the payment method is released.

For the second mode:

if the service key needing to be locked is manually specified to be the mobile phone numbers of the users A and B, the user A can lock the payment method when paying based on the mobile phone numbers, the lock is only effective for the user A, and is invalid for the user B, namely the user B can still pay after the lock is locked; similarly, when the user B pays based on the mobile phone number, the payment method can be locked, the lock is only effective for the user B, and is ineffective for the user A, and the user A can still pay after the lock is locked.

And step S102, locking the target object and executing the target object.

The target object may be triggered multiple times due to network jitter or frequent user clicks, for example, if the target object is triggered each time and executed, multiple results may occur, resulting in an ineptiveness to business. To avoid this, this step may lock the target object so that the target object only executes once after locking until the lock is released.

It should be noted that, this step may lock the target object before the target object is executed for the first time. If the target object needs to be executed again after the locking process is carried out until the lock is released, the target object is not locked again in the step, the target object is intercepted, and the target object is stopped from being executed again, so that the target object is prevented from being executed for multiple times. That is, in this step, before the target object needs to be executed for the first time, the target object may be locked, and the target object may be executed after locking, and after locking the target object until the lock is released, if the target object still needs to be executed, the target object may be intercepted, and the re-execution of the target object may be terminated, so that it may be ensured that the target object is executed only once in a "lock-release lock" process, thereby implementing the service idempotent, etc.

For example, when the user clicks the payment key for the first time, the payment method corresponding to the payment key may be locked, the payment method starts to be executed after the locking, and before the locking is performed until the lock is released, if the user clicks the payment key again, the payment method is intercepted, and the re-execution of the payment method is terminated, so as to prevent the user from paying for many times.

More specifically, the present embodiment acquires the lock before the target object is executed each time (i.e., the target object is about to be executed but is not executed), wherein if the acquisition of the lock is successful and indicates that the target object is not locked yet, the target object may be locked based on the acquired lock; if the lock acquisition fails and indicates that the target object is locked, the exception is thrown, the target object is intercepted, the re-execution of the target object is terminated, and preferably, information indicating the repeated execution exception can be returned.

It can be understood that, for the first execution of the target object, the probability of successful lock acquisition is higher, and at this time, the target object can be locked based on the acquired lock; if the target object is not executed for the first time, whether the target object is locked or not is automatically judged when the lock is acquired, if the target object is locked, namely the target object is locked, the exception is thrown, the target object is intercepted, the re-execution of the target object is terminated, and if the target object is not locked, the target object is locked based on the acquired lock.

Optionally, in this step, after the target object is locked, it may be further determined whether the locking is successful, if the locking is successful, the subsequent operation is performed, for example, a log is printed before the target object is executed, and if the locking is failed, an exception is thrown out, and exception information indicating that the locking is failed is returned.

It should be noted that, in the present application, the "lock-release" operation may be repeatedly performed on a target object, and then the "first execution" in this step refers to the first execution in a "lock-release" process (non-first execution may be intercepted after the target object is locked), and if the "lock-release" operation is performed on a target object multiple times, the target object may be correspondingly "first executed" multiple times. For example, after the user clicks the payment key for the first time, the payment method corresponding to the payment key may be locked, after the locking, the payment method may be executed for the first time, after the user completes payment, the lock added to the payment method may be released, and then the user may click the payment key again, and after the locking, the payment method may be executed for the first time again.

In an optional embodiment, this embodiment provides a specific implementation manner of this step, and optionally, this implementation manner may include the following steps S1021 to S1022:

and step S1021, generating a section AOP corresponding to the target object.

The AOP refers to a section-Oriented Programming, which is called "Aspect ordered Programming" in English, and has the capability of calling a pre-processing before the target object executes and calling a post-processing after the target object executes.

Alternatively, the pre-processing may include printing a log and acquiring a lock (in this embodiment, after the lock is successfully acquired, a try code block may be opened to lock the target object), and the post-processing may include printing a log and opening a finish code block to release the lock applied to the target object.

And step S1022, locking the target object based on the section AOP.

Specifically, after creating a lock for the target object, a try code block may be called based on the tangent plane AOP to lock the target object. Optionally, after determining that the locking is successful, a log may be printed before the target object is executed based on the tangent plane AOP.

Step S103, after the target object is executed, releasing the lock added on the target object.

Alternatively, corresponding to the above "locking the target object based on the facet AOP", the step may release the lock added to the target object based on the facet AOP, that is, the step may call a finish code block based on the facet AOP to release the lock added to the target object. Optionally, after releasing the lock, a log may also be printed based on the tangent plane AOP.

According to the method for realizing the business idempotent, in the process of realizing the business idempotent, developers only need to add annotations to the target objects in the business codes, do not need to write codes additionally for each target object, are friendly to the developers, only need one annotation to ensure the business idempotent, and the developers have low cost and are simple to use.

In addition, the method for realizing the service power and the like can be introduced into the service code in a mode that the jar packet depends on, so that the jar packet and the service code can be completely decoupled, the jar packet can be easily stripped from the service code when the service power and the like do not need to be realized, and the use is more convenient.

In the following embodiments, some cases that may occur in the target object execution are described.

In a first case, a service exception, such as an empty pointer, no authority, or the like, may occur during the execution of a target object, and in order to ensure that a lock applied to the target object can be successfully released after the service exception occurs, this embodiment may capture the service exception generated during the execution of the target object through a catch code block, intercept the target object after capturing the service exception, terminate the execution of the target object, and release the lock applied to the target object, and preferably, may also be thrown out as it is after capturing the service exception, and throw out an "execution process exception".

Optionally, "to release the lock added to the target object" in this embodiment may specifically be: the finish code block is called through the tangent plane AOP to release the lock added on the target object.

In the second situation, the target object may be successfully executed, and then the embodiment may determine whether the thread where the target object is located is in the locked state after the target object is successfully executed, and if so, release the lock added to the target object.

Optionally, in this embodiment, when it is determined that the thread in which the target object is located is in the locked state, a lock release signal may be issued to release the lock applied to the target object. Here, "to release the lock added to the target object" may specifically be: the finish code block is called through the tangent plane AOP to release the lock added on the target object.

Optionally, if the thread where the target object is located is not in the locked state, the log may be printed, so as to troubleshoot the problem based on the log.

By combining the above first and second cases, it can be seen that no matter a service exception occurs in the process of executing the target object or the target object is successfully executed, the present application can call a finish code block through the facet AOP to release the lock added to the target object. It will be appreciated that releasing the lock applied to the target object may be successful or may fail. If the release is successful, the log can be printed, the service code is normally ended, and if the release is failed, the 'lock release exception' can be thrown out, and see the third case.

In order to deal with the situation that the lock applied to the target object fails to be released, in the embodiment of the present application, a timeout time may be set during locking, and a "patrol" inside the lock (the "patrol" is an asynchronous timing task) is used to automatically release the lock, specifically, the lock applied to the target object may be scanned at the timeout time based on the asynchronous timing task inside the lock applied to the target object, and if it is found that the lock release signal has been received but the lock applied to the target object fails to be released, the lock applied to the target object is automatically released, where "release failure" refers to performing a lock release operation on the lock on the target object within the timeout time and failing to be released. For example, assuming that the timeout time is 30 seconds, a scan may be performed every 5 seconds based on the asynchronous timing task, and if it is found at the 15 th second that the lock release signal has been received but the lock release abnormality applied to the target object is present, the lock applied to the target object may be automatically released.

Optionally, there may be a case where the lock added to the target object is being released when the timeout time is reached, or a case where the lock added to the target object just fails to be released when the timeout time is reached, and at this time, the lock added to the target object may be automatically released directly based on the asynchronous timing task.

Because the method and the device can automatically release the lock added on the target object based on the asynchronous timing task, when the lock is released unsuccessfully, a developer can autonomously select whether to process the exception.

In case four, in an extreme case, such as an extreme case where the target object is disconnected from the network during execution, powered off, and an application after locking exits abnormally (the target object is still executing before the extreme case occurs, and the step of releasing the lock is not executed, i.e., step S103 is not executed), in order to prevent occurrence of "deadlock", the lifetime of the lock may be prolonged when the unreleased lock is found based on the asynchronous timing task. That is, the present application may periodically scan a lock added to a target object based on an asynchronous timed task inside the lock added to the target object, and if it is found that a lock release operation is not performed on the lock on the target object within the timeout period, the timeout period is extended. For example, assuming a timeout of 30 seconds, a scan may be performed every 5 seconds based on the asynchronous timed task, and if it is found at the 5 th second that no lock release operation has been performed on the lock on the target object, the timeout is extended, for example, by 30 seconds. In this way, even if the target object cannot be executed temporarily due to the occurrence of a special situation, the target object can be continuously executed after the normal state is restored.

In conclusion, the method and the device can be applied to a full scene, and can ensure that the lock added on the target object is released smoothly and deadlock does not occur no matter whether the execution of the target object is abnormal or not, and can ensure that the target object can be executed smoothly by prolonging the compensation mode of the overtime time under the extreme condition, thereby ensuring that the service of the method is 100% idempotent and the like. In addition, the method and the device can achieve at least 5 and 9 availabilities in a high-availability and distributed scene, and are higher in performance and better in stability.

In view of the compatibility problem of the new and old systems when the method for implementing business idempotent provided by the present application is applied to a distributed system, in this embodiment, the lock added to the target object may be an optimistic lock or a distributed lock based on Redis.

The core of the Redis-based distributed lock is realized as SET lockKey locakVualE EX 30. In this embodiment, the Redis-based Distributed lock may use an existing Redisson framework, where the framework implements a Redlock (Redis Distributed Lock) algorithm, and can guarantee the consistency of lock data in a Redis cluster, and the framework supports the consistency and availability of lock data in a Redis cluster mode.

The core implementation of the optimistic lock based on the database is as follows: UPDATE t _ lock SET lock $ { lock }, SET version $ { version }. In this embodiment, in the master-slave mode of the database, it is preferable to start "semi-synchronous replication" to ensure that the slave library returns after the master library writes data and the slave library also writes data successfully.

Since the performance of a Redis-based distributed lock is higher than that of an optimistic lock, a Redis-based distributed lock is used by default, although a database-based optimistic lock may also be used to ensure historical entry and downward compatibility.

In this embodiment, which lock to select specifically needs to be determined according to information pre-configured by a developer, or according to a plug-in introduced by a distributed system, wherein if a database plug-in is introduced, an optimistic lock based on a database is used; if a Redis plug-in is introduced, a Redis-based distributed lock is used.

Because the embodiment can be realized by adopting cache (namely, a Redis-based distributed lock) and database double locks, the method can support a new distributed system while being compatible with an old distributed system, has better compatibility and supports high concurrency requirements of a complex distributed system.

The embodiment of the present application further provides a device for implementing business idempotent, which is described below, and the device for implementing business idempotent described below and the method for implementing business idempotent described above may be referred to correspondingly.

Referring to fig. 2, a schematic structural diagram of an apparatus for implementing idempotent services according to an embodiment of the present application is shown, and as shown in fig. 2, the apparatus may include: a code scanning module 201, a locking module 202 and a releasing lock module 203.

The code scanning module 201 is configured to scan a service code, and determine a target object from the service code, where the target object is an object to be subjected to idempotent operation, and the target object is marked with an annotation.

And the locking module 202 is used for locking the target object and executing the target object.

And the lock releasing module 203 is used for releasing the lock added on the target object after the target object is executed.

The device for realizing the business idempotent and the like scans the business codes, determines the target object from the business codes, locks the target object, executes the target object, and releases the lock added on the target object after the target object is executed. Therefore, the device for realizing the business idempotent provided by the application enables developers to add annotations only on the target objects in the business codes in the process of realizing the business idempotent, does not need to write codes additionally for all the target objects, is more friendly to the developers, and has lower use cost.

In a possible implementation manner, the locking module 202 is specifically configured to generate a tangent plane AOP corresponding to the target object, and lock the target object based on the tangent plane AOP.

Accordingly, the lock releasing module 203 is specifically configured to release the lock applied to the target object based on the tangent plane AOP.

In a possible implementation manner, the apparatus for implementing idempotent services provided in this embodiment of the present application may further include: and an exception handling module.

And the exception handling module is used for intercepting the target object and releasing the lock added on the target object if the business exception occurs in the process of executing the target object.

In a possible implementation manner, the lock releasing module 203 may further include: a thread locking judgment module and a lock release submodule.

And the thread locking judgment module is used for determining whether the thread where the target object is located is in a locking state if the target object is successfully executed.

And the lock releasing submodule is used for releasing the lock added on the target object when the thread locking judging module determines that the thread where the target object is located is in a locking state.

In a possible implementation manner, a lock added to a target object is set to have a timeout time, and the apparatus for implementing service idempotency provided in this embodiment may further include: a scanning module and an automatic release module.

And the lock scanning module is used for scanning the locks added on the target object at regular time based on the asynchronous timing task inside the locks added on the target object.

And the automatic release module is used for automatically releasing the lock added on the target object if the lock on the target object is released within the overtime and the release fails.

In a possible implementation manner, the apparatus for implementing idempotent services provided in this embodiment of the present application may further include: and a timeout time prolonging module.

And the overtime time prolonging module is used for prolonging the overtime time if the lock on the target object is not released within the overtime time.

The embodiment of the application also provides equipment for realizing the service idempotent. Optionally, fig. 3 shows a block diagram of a hardware structure of a device for implementing a business idempotent, and referring to fig. 3, the hardware structure of the device for implementing a business idempotent may include: at least one processor 301, at least one communication interface 302, at least one memory 303, and at least one communication bus 304;

in the embodiment of the present application, the number of the processor 301, the communication interface 302, the memory 303 and the communication bus 304 is at least one, and the processor 301, the communication interface 302 and the memory 303 complete communication with each other through the communication bus 304;

the processor 301 may be a central processing unit CPU, or an application Specific Integrated circuit asic, or one or more Integrated circuits configured to implement embodiments of the present invention, or the like;

the memory 303 may include a high-speed RAM memory, and may further include a non-volatile memory (non-volatile memory) or the like, such as at least one disk memory;

wherein the memory 303 stores a program and the processor 301 may call the program stored in the memory 403 for:

scanning the service code, and determining a target object from the service code, wherein the target object is an object to be subjected to idempotent operation, and the target object is marked with notes;

locking the target object and executing the target object;

and releasing the lock added on the target object after the target object is executed.

Alternatively, the detailed function and the extended function of the program may be as described above.

Embodiments of the present application further provide a readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, the method for implementing service idempotent as described above is implemented.

Alternatively, the detailed function and the extended function of the program may be as described above.

Finally, it is further noted that, herein, relational terms such as, for example, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without further limitation, an element defined by the phrase "comprising an … …" does not exclude the presence of other identical elements in a process, method, article, or apparatus that comprises the element.

The embodiments in the present description are described in a progressive manner, each embodiment focuses on differences from other embodiments, and the same and similar parts among the embodiments are referred to each other.

The previous description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the present application. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other embodiments without departing from the spirit or scope of the application. Thus, the present application is not intended to be limited to the embodiments shown herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.