The definition of idempotency

The central feature of idempotency is that any number of executions have the same effect as a single execution. In fact, the main operation in our programming is CURD, where the Retrieve operation and Delete operation are naturally idempotent, and the ones affected are Create and Update.

A common scenario where repeated requests occur

In the service, the idempotent is usually repeated requests of the interface. Repeated requests refer to the same request being submitted several times for some reason. There are several scenarios that can lead to this situation: Repeated submission in the front end: when an order is submitted, the user clicks it repeatedly for many times quickly, resulting in multiple repeated orders generated in the back end. Interface timeout retry: To prevent request loss caused by network jitter or other reasons, the interface that is invoked by a third party is designed to retry multiple times due to timeout. Message repeat consumption: MQ message middleware, message repeat consumption.

Idempotent solution

The front-end control

For interfaces that interact with the Web side, we can intercept some of them in the front end, such as preventing forms from being submitted repeatedly, and putting buttons in grey, hidden and unclickable ways.

The back-end control

Token mechanism

In general, token scheme should pay attention to atomicity of query and deletion

The main process is as follows: The server provides an interface for sending tokens. When we analyze the business, which business has idempotent problem, we must obtain the token before executing the business, and the server will save the token in Redis. (Microservices must be distributed, if a single machine is suitable for JVM caching). The token is then carried over when the business interface request is invoked, usually in the header of the request. The server checks whether the token exists in redis. If the token exists in Redis, the server deletes the token in redis for the first time and continues services. If the token does not exist in redis, it indicates that the operation is repeated, and the repeated token is directly returned to the client. In this way, the business code will not be executed repeatedly.

Database unique index

This is very simple, create a unique index.

Redis implementation

About the process

The way Redis is implemented is to use the unique serial number as the Key. The unique serial number is generated in the same way as the anti-duplicate table introduced above. The value can be any information you want to fill in. The unique sequence number can also be a single field, such as the order number of an order, or a unique combination of multiple fields. Of course, you need to set a key expiration time, otherwise there will be too many keys in Redis.

Note: Delete the redis key when an exception occurs

The state pattern

The state pattern, in which one state can flow to another, ensures idempotency. For details, see the previous article: Design and implementation of state patterns for order flow

Idempotent state patterns note that, in theory, repeated processing of business logic can still occur as long as the query operation is completed before the data state is updated.

conclusion

There are trade-offs and choices based on different business scenarios. There is no silver bullet.