Shulou(Shulou.com)06/02 Report--

Several schemes to realize the idempotency of interface

When robbing WeChat red packet, we all know: once you have robbed a red packet, the result will be the same no matter how many times you click. The red packet will remind you that you have already snatched the red packet, but will not let you do it again.

Red packet grabbing interface is a very typical idempotent interface, robbing once and robbing many times has the same effect. There will be a lot of similar interfaces in our development process, such as in the process of placing orders for e-commerce:

The order creation API has timed out the first time it is called. The retry mechanism usually calls this API again. At this time, we cannot create two identical orders just because this API has been adjusted twice.

Inventory deduction interface and payment interface are similar logic.

Today's article will talk about what is the idempotency of the interface and introduce several schemes to realize the idempotence of the interface.

# what is idempotent #

Idempotence was originally a concept in mathematics, which means that the effect of one transformation is the same as that of N transformations.

When we discuss the idempotency of the interface, we are generally saying that calling the interface once with the same request and calling the interface multiple times will have the same impact on the system. If an interface satisfies this feature, then let's say this.

Interface is an idempotent interface. For example, the interface of grabbing red packets above.

PS: here, by the way, is the difference between idempotency and preventing duplicate commits.

What is more important to prevent repeated submissions is to prevent users from making the same request multiple times. For example, the user clicks the submit order button when placing an order online, but the response is very slow due to network reasons, so the user clicks the order submit button many times in a hurry.

In this case, multiple orders may be placed. General solutions to prevent repeated submissions are: graying the order button, jumping to the results page, and so on. Mainly from the client point of view to solve this problem.

Idempotency is more likely to take certain technical measures to make these repeated requests do not bring side effects to the system when repeated requests have occurred or are unavoidable.

# when do you need idempotents? #

Not all interfaces need to be idempotent. Call this interface one or more times with the same request, and when you need to return consistent results to the caller, consider designing the interface as an idempotent interface.

Several schemes for realizing idempotency #

When we design idempotent interfaces, we focus on adding interfaces and updating interfaces. Because query and delete operations are inherently idempotent (based on id queries and multiple deletions based on id are consistent on the system), there is no need for us to provide additional

Technical means to ensure idempotency. (? )

For adding and updating interfaces, there are roughly the following solutions to ensure the idempotency of the interface.

Source plus serial number #

This is a relatively easy to understand, general-purpose scheme.

When calling the API, the source field and seq field must be passed in the parameters (a column in our project is listed here, but it is not necessary to pass two fields. Passing a unique serial number uuid can achieve the same effect). When the server receives the request, it first determines whether it is an idempotent interface, and if it is not an idempotent interface, it processes the request normally.

If it is an idempotent interface, use source and seq to form a joint primary key to query in the database table or Redis. If it is not queried, the request has not been processed, and then the request will be processed normally. After processing, the processing results and source and seq information are stored in the database or Redis.

If it can be queried according to source and seq, it means that the request has been processed, and the result of processing can be returned directly.

We find this scheme very simple, easy to understand and universal. However, if the number of requests is large, the table to store the request records will be very large, and the records from a period of time can be deleted to improve performance.

Unique index (unique field) #

This scheme is suitable for interfaces that are used to perform new operations.

For example, add a user interface. We add a unique index to the ID field in the user table. When the same request is called twice, we can first query whether the user exists according to the ID field, and then add it if it does not exist. If it exists, the new failure will be returned.

Or it can be added directly, the database will throw an exception, and we can return the exception handling to the foreground.

PS: you may have a question. I called the same request twice. The first returned success, and the second returned failed. The result returned is different. Is this interface still idempotent?

Here I would like to reiterate the concept that idempotence emphasizes that the effect of one call to an interface is the same as that of multiple calls. One call and multiple calls here add an object, so it is idempotent.

Optimistic lock #

This scheme applies to interfaces that perform update operations.

Optimistic locking only locks the table at the moment the data is updated, but does not lock the table the rest of the time, so it is more efficient than pessimistic locking. We generally implement optimistic locks through the database, and a more common approach is to add a timestamp field.

Copyupdate table_xxx set name=#name#, timestamp= now where id=#id# and timestamp=#timestamp#-this value is queried from the front end to the data, and then passed to refer to the interface idempotent design of # distributed system how to avoid placing duplicate orders.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.