Distributed interface idempotence

Preface

What is idempotence? One time and multiple requests for a certain resource have the same impact on the resource itself as the impact of one execution.

Idempotence is a promise of system services to the outside world, which promises that as long as the interface is successfully called, the impact of multiple calls on the system is consistent.

Comparison of idempotence and repeated submissions

Idempotence more commonly used when the result is known for the first time, but the normal response is not returned due to network jitter or connection timeout. In this case, the system automatically initiates the request again, and the purpose is to confirm the first time Whether the request is complete.

repeated submission of more use is the case where the first request is successful or the request result has not been returned, and multiple operations are artificially performed.

SQL statement idempotence

SELECT

SELECT * FROM `user` WHERE id = 1

No matter how many times it is executed, the resources will not be affected, and the query is naturally idempotent.

UPDATE

UPDATE `user` SET status = 1 WHERE id = 1;

No matter how many times the execution is successful, the state is consistent. This scenario is an idempotent operation.

UPDATE `user` SET score = score+1 WHERE id = 1;

The result of each execution will change. This scenario is not an idempotent operation.

According to the specific scenario, see if it can be written as SQL :

UPDATE `user` SET score = score+1 WHERE id = 1 AND score = 59;

No matter how many times the execution is successful, the score is consistent. This scenario is an idempotent operation.

DELETE

DELETE FROM `user` WHERE id = 1;

No matter how many times the execution is successful, the data is consistent. This scenario is an idempotent operation.

INSERT

INSERT INTO `user` (`name`, `status`, `score`) VALUES ('tom', 1, 80);

The result of each execution will change. This scenario is not an idempotent operation.

According to the specific scenario, see if you can name , or the execution type SQL :

INSERT INTO ... values ... ON DUPLICATE KEY UPDATE ...

// 注意，要使用这条语句，前提条件是这个表必须有一个唯一索引或主键。

Implementation plan

Option One

The downstream system provides the corresponding query interface.

After the upstream system is at timeout , first check it. If it is found, it means it has been done. If it succeeds, it does not need to be done. If it fails, it will go through the failure process.

Option II

This query operation is handed over to the downstream system, and the upstream system only retrying, and the downstream system ensures that the impact of one and multiple requests is the same. At this time, we say that the interface provided by the downstream system supports idempotence.

summary

Idempotence is concerned with whether multiple requests have side effects on the resource, not the result of the concern. SELECT statement may query data inconsistently each time, but it is idempotent.

Regarding the implementation plan -> the specific implementation plan of the second plan, consider the appropriate solution according to the actual situation of the business, for example: through the SQL statement can achieve idempotence, there is no need to introduce the global unique ID solution.

Recommended reading

1. Distributed Transactions
2. The final consistency implementation plan of distributed transactions
3. Distributed asynchronous communication component selection
4. Distributed configuration center