What is Idemdempotent
Idempotency was originally a concept in mathematics that meant that a 1st transformation would have the same effect as an n transformation.
Idempotency: The result of performing the same operation multiple times is the same as the result of performing the same operation once.
It is important to design interfaces that are idempotent, especially when dealing with operations that involve changes in the state of a resource.
1. Scenarios of idempotency
1. Repeated submission on the front-end
It's like having a function to add a new product, there is a save button, if the front-end clicks save multiple times in a row, the back-end will receive multiple requests to the interface, and if it is not idempotent, multiple records will be created repeatedly, and dirty data will appear.
This is what we call the question of how to prevent duplicate commits on the frontend.
2. The interface times out and tries again
When we call a third-party interface, the call may fail due to network and other reasons, so we will add a failure retry mechanism to the interface call, and Spring can implement the retry mechanism through @retryable annotations.
Since the retry is possible, there may be repeated calls to the interface. In this case, if you don't do idempotent when you call again, dirty data may occur.
3. Repeated message consumption
This is unavoidable, because we say that MQ is both on the production side and on the consumer sideRetry mechanism, that is, the same message is likely to be consumed repeatedly.
If the service guarantees that the result of multiple consumption is the same, then it is fine, but if the service cannot meet the requirements, then it needs to ensure the idempotency of the consumer side in other ways.
2. How to ensure idempotency
Here are some common strategies for designing interfaces that are idempotent:
1.Use the http method:
Use http's idempotent methods, such as get, put, and delete, to perform operations on resources.
Avoid using non-idempotent methods such as POST unless there is a clear reason to use it and idempotency is taken into account by design.
2.Provide a unique identifier:
Make sure that each resource has a unique identifier, such as an id or key.
Use this unique identifier as part of the request so that the resource to be acted upon accurately is located on each request.
3.Check the resource status:
Check the status of the current resource before processing the resource change operation.
If you are already in the target state, you can return a successful response without making any changes.
4.Ignore duplicate requests:
If you receive duplicate requests, you can choose to ignore them without making any changes to the resource.
You can use the request identifier, timestamp, or other identifiers to check the uniqueness of the request.
5.Use optimistic concurrency control:
Include a version number or timestamp in the resource state and include it in the request every time it is requested.
Before processing the request, compare the version number or timestamp of the resource, and if there is a conflict, return the conflicting response.
6.Provide idempotent identifiers:
For non-idempotent operations, you can ask the client to provide an idempotency identifier.
In each request, the client provides the same idempotent identifier to ensure that the same operation is performed only once.
7.Log requests and results:
Each request and its results are recorded server-side for inspection and tracking when handling duplicate requests.
Choose the right strategy based on your specific needs and business logic to ensure the idempotency of the interface. When designing interfaces, it is also important to consider the consistency and security of the data.