concept

Multiple operations have the same effect on the data as one operation. 【 query 】, 【 delete 】 operation does not exist idempotent problem, no matter how the query result is the same, delete once this data is gone. The idempotent problem exists only when [add] and [change].

To solve

Here only discusses how to deal with the idempotent problem of the background, the limitation of the page belongs to the front end category does not expand.

  1. Primary keys and optimistic/pessimistic locks

The first thing that comes to mind is to ensure idempotency directly from the database, in the operation of “ById” primary key can be.

However, this only guarantees that the data will be the same no matter what way I modify it, and cannot guarantee the sequence of [changes]. In order to further make our program design in line with our expectations, the general table design will have a version field to ensure the version of data, but also to avoid multiple clients at the same time query and modify at the same time caused by different changes to cover each other, here leads to the way of optimistic lock.

The method of primary key to determine the specified data to modify, optimistic lock to ensure the order of the execution of the modification, can be perfect to solve the problem of idempotent and sequential change operation, at the same time in the distributed environment is also applicable, the premise is that the operation is the same table in the same database.

For some scheduled tasks or scenarios that are not sensitive to sequential operations, the update can be performed by querying the latest version in compensation measures after the update fails. However, this cannot be done in high concurrency scenarios, where frequent changes in concurrency will result in continuous compensation operations and the resulting changes may not be the intended content.

Of course, optimistic lock must be optimistic lock, but this use of the scene may be less, compared to optimistic lock granularity is much larger, in the performance of the operation compared to the efficiency will be low. But it might as well be a solution.

  1. Token and distributed lock

All idempotent operations are bound to the existing data for operation. There is no such anchor for increment, which can only be done by marking it in the system. Markup is nothing more than a Token, which makes sense. Every time a user opens a new page, they request a Token from the backend. After the user clicks save, the foreground sends the Token to the background to match the Token. After the match is successful, the Token will be deleted from the system. This avoids adding multiple copies of the same data due to network fluctuations or retries in various situations.

However, for non-page interface invocation, the interface that obtained the Token can be invoked before invoking the new interface to perform subsequent data addition operations. The principle is the same as the above page call. However, centralized management is required for the location where the Token is stored in a distributed scenario, such as redis or ZK (zK is not recommended as a place to store data).

There are many different ways to obtain permission and then add/modify. For business scenarios with high idempotent requirements like banks, each operation will add serial number and customer id. The principle is the same: obtain permission and then modify, but the serial number determines whether the operation is in order.

conclusion

Idempotency is important in some scenarios, especially for scenarios with large amounts of money or high concurrent additions and modifications. Common idempotency such as optimistic lock + primary key will do, and it is very simple to code.

MyBaits is one of those frameworks that comes with version numbers. However, the idempotent design in the new scenario will have one or two more methods and fields. If there is really a need for idempotent design, don’t be lazy. You can complete the verification of all tokens by making a unified section with annotations.

Implementation methods, in order to ensure that the program less bug or suggested design procedures to consider more possible aspects of all aspects.