Author: Three Points Evil
Original: cnblogs.com/three-fighter/p/14054749.html
The project in charge of the blogger reported a problem, and the user operation rollback failed. In our design, the operation rollback is to return to the state before the operation. After checking the log, it is found that the user's previous operation has been done twice, that is to say, the interface for submitting the operation has been called twice, resulting in the user's last state and this time's state are the same, so there is no problem with the operation rollback Yes, the problem is that the interface of the operation is called twice.
To prevent repeated submissions, it is placed in the front-end control. After the user clicks the button, the background returns a successful result, and the button is invisible. Practice has proved that the limit operation of the client is not absolutely reliable.
For the above scenario, today's question is introduced, what is interface idempotency? How to ensure interface idempotency?
What is interface idempotency?
First look at the concept of idempotency:
Idempotency is originally a mathematical concept, and it can be understood when used in interfaces: the same interface, if the same request is issued multiple times, must ensure that the operation is performed only once. When an exception occurs in the calling interface and repeated attempts will always cause losses that the system cannot bear, it is necessary to prevent this phenomenon from happening.
For example, in the following cases, if the interface idempotency is not implemented, there will be serious consequences: for the payment interface, repeated payments will result in multiple deductions; for the order interface, the same order may be created multiple times.
Why does the interface idempotency problem occur?
So, under what circumstances will the problem of interface idempotence occur?
- Network fluctuations, which may cause repeated requests
- If the user repeats the operation, the user may unintentionally trigger multiple order transactions during the operation, or even intentionally trigger multiple transaction applications without responding.
- The failure or timeout retry mechanism is used (Nginx retry, RPC retry or business layer retry, etc.)
- Page refreshes repeatedly
- Repeating previous action with browser back button, resulting in repeated form submission
- Repeat form submission using browser history
- Browser repeated HTTP requests
- Repeated execution of scheduled tasks
- User double clicks submit button
How to ensure interface idempotency?
So the most important thing is, how to ensure the idempotency of the interface?
The solution is divided into two directions, one is for the client to prevent repeated calls, and the other is for the server to verify. Of course, it is not absolutely reliable for the client to prevent repeated submissions, and the advantage is that it is relatively simple to implement.
Button can only be operated once
Generally, the button is set to gray or loding state after submission to eliminate the repeated records generated by the user due to repeated clicks, such as adding operations, which generate two records due to two clicks.
token mechanism
Functionally, repeated submissions are allowed, but it must be ensured that repeated submissions will not cause side effects. For example, only one record will be generated by clicking n times. The specific implementation is to apply for a token when entering the page, and then all subsequent requests will bring this token, and the backend will be based on the token. Avoid repeating requests.
Use Post/Redirect/Get mode
Execute page redirection after submission, this is the so-called Post-Redirect-Get (PRG) mode, in simple terms, when the user submits the form, jump to a redirected information page, so as to avoid the user pressing F5 to refresh Caused by repeated submission, and there will be no warning of repeated submission of the browser form, and it can also eliminate the problem of the same repeated submission caused by pressing the browser forward and backward.
Store special flags in session
On the server side, a unique identifier is generated and stored in the session. At the same time, the front end obtains the value of this identifier and writes it into the hidden form for the user to click and submit after entering information. On the server side, the form is obtained. The value of the hidden field in the session is compared with the unique identifier in the session. If it is equal, it means that the request is submitted for the first time, and the request will be processed, and then the unique identifier in the session will be removed. .
Use unique indexes to prevent new dirty data
Using the database unique index mechanism, when the data is repeated, an exception will be thrown when the data is inserted into the database to ensure that there will be no dirty data.
optimistic locking
If you update existing data, you can perform lock update, or you can use optimistic lock when designing table structure, and use version to do optimistic lock, which can not only ensure execution efficiency, but also ensure idempotency. The version version of optimistic lock is updating the business. data to auto-increment
update table set version = version + 1 where id = #{id} and version = #{version}Example: When there are repeated requests, the first request will obtain the version number of the current product, the obtained version is 1, and then because the first request has not updated the version of the product, the version obtained by the second request is still It is also 1. At this time, when the first request to update the operation, bring the version as a condition and auto-increment the update. At this time, the version of the product will become 2. When the second request is to update the operation, it is obvious that the version is inconsistent, which leads to the update. fail.
select + insert or update or delete
The solution is to query before the operation, and then insert it if it meets the requirements. This solution can solve the idempotent problem in a system without concurrency. When a single JVM has concurrency, JVM locking can be used to ensure idempotency. In a distributed environment It is not guaranteed to be idempotent and can be guaranteed using distributed.
Distributed lock
If it is a distributed system, it is difficult to build a global unique index. For example, the unique field cannot be determined. At this time, a distributed lock can be introduced to insert data or update data in the business system through a third-party system (redis or zookeeper). Acquiring distributed locks, then performing operations, and then releasing the locks is actually the idea of introducing multi-threaded concurrent locks into multiple systems, that is, the solution to the distributed system.
Point: A long process process requires that it cannot be executed concurrently. You can obtain a distributed lock according to a certain flag (user ID + suffix, etc.) before the process is executed. There can be one that can be executed successfully. After the execution is completed, the distributed lock is released (the distributed lock needs to be provided by a third-party system).
state machine idempotent
When designing a document-related business or a task-related business, a state machine (state change diagram) will definitely be involved, that is, there is a state on the business document, and the state will change under different circumstances. Generally, there are limited states. At this time, if the state machine is already in the next state, and a change to the previous state comes at this time, it cannot theoretically be changed. In this way, the idempotency of the finite state machine is guaranteed. Note: Document business such as orders has a long state flow. It is necessary to deeply understand the state machine, which is of great help to improve the design ability of business systems.
Anti-weight table
Take payment as an example: use the unique primary key as the unique index of the anti-duplication table, such as using the order number as the unique index of the anti-duplication table, each request inserts a piece of data into the anti-duplication table according to the order number, and the successful insertion indicates that it can be processed In the following business, after processing the business logic, delete the order number data in the anti-duplication table. If there are repeated requests in the future, the insertion will fail due to the unique index of the anti-duplication table, and the operation will fail directly until the first request returns. As a result, it can be seen that the function of the anti-weight table is the function of locking.
Note: It is best to judge first in conjunction with state machine idempotency
buffer queue
Receive requests quickly and put them in the buffer queue, then use asynchronous tasks to process the data in the queue and filter out duplicate requests. The advantage of this solution is that synchronous processing is changed to asynchronous processing and high throughput. The disadvantage is that it cannot To return the request results in a timely manner, subsequent polling is required to process the results.
global unique number
For example, the source source + unique serial number is passed to the backend, and the backend judges whether the request is repeated. Only one request can be processed when concurrent. Other identical concurrent requests either return the request to be repeated, or wait for the execution of the previous request to complete before executing.
Recommended recent hot articles:
1. 1,000+ Java interview questions and answers (2022 latest version)
2. Madden! Java coroutines are coming. . .
3. Spring Boot 2.x tutorial, so complete!
4. Don't write the full screen explosion class, try the decorator mode, this is the elegant way! !
5. "Java Development Manual (Songshan Edition)" is the latest release, download it quickly!
If you think it's good, don't forget to like + retweet!