Idempotent of the back-end interface

Under the microservices architecture, we often encounter the following scenario when we complete an order process: an order creation interface, the first call timed out, and then the caller retries one time when the order is created, we need to deduct the inventory, when the interface has timed out and the caller retries once the order starts to pay, After the payment request is issued, there is a debit operation on the server, the interface response times out, the caller retries an Order status update interface, the caller sends two messages consecutively, one is created, one is paid. But you receive the payment first, and then you receive it. After the payment has been completed, a text message is sent, and the processing is slow after a machine receives messages sent by SMS. Message middleware also delivers the message to another machine for processing

The above problem is the problem that comes after the monolithic architecture has been converted into a micro-service architecture. Of course not to say that there are no such problems in the monolithic architecture, and that the duplicate requests should be avoided under the monolithic architecture. But there are a lot less problems than that.

In order to solve the above problems, it is necessary to ensure the power of the interface, the power of the interface is actually the interface can be repeated calls, in the case of multiple calls of the caller, the interface will eventually get the result is consistent . Some interfaces can be natural to achieve idempotent, such as query interface, for the query, you query once and two times, for the system, no impact, the results are the same.

In addition to the query function has a natural power, such as increase, update, delete to ensure idempotent. So how to ensure the power of the same. Global Unique ID

If a global unique ID is used, a global ID is generated based on the operation and content of the business, and the operation is judged by whether the global unique ID exists before the operation is performed. If not present, the global ID is stored in the storage system, such as database, Redis, etc. If present, indicates that the method has been executed.

From the point of view of engineering, the use of global ID to power and so on as a business basis for the micro-service exists, in many microservices will use such services, in each micro-service to complete such a function, there will be duplication of effort. In addition, to create a high-reliability power and other services need to consider a lot of problems, such as a machine, although the global ID is written to the storage, but after the write is hung, this requires the introduction of a global ID timeout mechanism.

Using a globally unique ID is a common scenario that enables you to insert, UPDATE, and delete business operations. But the plan looks beautiful but it's cumbersome to implement, and the following scenario works for a particular scenario, but it's easier to implement. go to re-watch

This approach applies to the insertion scenario where there is a unique tag in the business, such as in the above payment scenario, if an order is only paid once, the order ID can be uniquely identified. At this point, we can build a go to the table, and the unique identity as a unique index, when we implement, the creation of payment documents and write to go to the table, put in a transaction, if repeatedly created, the database throws a unique constraint exception, the operation will be rolled back. Insert or update

This method inserts and has a unique index, for example, we want to associate the product category, where the ID of the product and the ID of the category can form a unique index, and the data table also adds a unique index. You can then use the insertorupdate operation. In the MySQL database, the following:

1 2 3 4

Insert into Goods_category (goods_id,category_id,create_time,update_time) VALUES (#{goodsid},#{categoryid}, now (), Now ()) on DUPLICATE KEY UPDATE update_time= Now ()

Multi-version control

This method is suitable for updating the scene, such as we want to update the name of the product, then we can add a version number in the updated interface, to do idempotent

1	Boolean updategoodsname (int id,string newname,int version);

The implementation can be as follows

1	Update goods set Name=#{newname}, version=#{version} where id=#{ID} and version<${version}

state Machine Control

This method is suitable in the case of the flow of the state machine, such as the creation and payment of the order, the payment of the order must be before, when we can design the state field, using the int type, and by the size of the value type to do idempotent, such as the creation of the order of 0, payment success is 100. Payment failure is 99

When we do a state machine update, we can control it this way.

1	Update ' order ' set status=#{status} where id=#{ID} and status<#{status}

The above is a number of methods to ensure the power of the interface.