Idempotence of interfaces -- talk about idempotence of interfaces in detail, that is, solutions

One 、 What is idempotence

Interface idempotency means that the results of one request or multiple requests initiated by the user for the same operation are consistent , Not because of Side effects caused by multiple clicks ; For example, the payment scenario , The user has successfully deducted the payment after purchasing the goods , But the return knot The result is that the network is abnormal , At this time, the money has been deducted , The user clicks the button again , A second deduction will be made , Return knot Fruit success , The user found that he had deducted more money after checking the balance , There are two records of running water ．．．, There is no guaranteed interface Idempotency .

Two 、 What situations need to be prevented

The user clicks the button several times
The user page goes back and submits again
Microservices call each other , Due to network problems , Cause the request to fail .feign Trigger retry mechanism
Other business conditions

3、 ... and 、 When idempotent is needed

With SQL For example , Some operations are naturally idempotent .
SELECT * FROM table WHER id=?, No matter how many times it is executed, it will not change the State , It's a natural idempotent .
UPDATE tab1 SET col1=1 WHERE col2=2, The status is consistent no matter how many times the execution is successful , It's also an idempotent operation .
delete from user where userid=1, Multiple operations , Results the same , Idempotent
insert into user(userid,name) values(1,‘a’) Such as userid Is the unique primary key , Repeat the above business , only A piece of user data will be inserted , Idempotent .

UPDATE tab1 SET col1=col1+1 WHERE col2=2, The result of each execution changes , Not idempotent .
insert into user(userid,name) values(1,‘a’) Such as userid Not the primary key. , Can be repeated , The above business has been operated many times do , More than one data will be added , Not idempotent .

Is idempotent required for both read and write requests ？

Read requests do not need to be idempotent （ Because the read request will not change the data ）.
Writing a request requires idempotent （ When the data is changed, idempotent is performed as required ）.

Four 、 Idempotent solutions

1、token Mechanism

1、 The server provides sending token The interface of . When we analyze the business , Which businesses have idempotent problems , Before we can do business , Get it first token, The server will send token Save to redis in .
2、 Then call the business interface request. , hold token Carry the past , Generally placed in the request header .
3、 Server judgment token Whether there is redis in , Presence indicates first request , Then delete token, Continue to pursue the industry service .
4、 If you judge token non-existent redis in , It means repeat operation , Direct return to repeat mark to client, such It ensures the business code , Not repeated .

danger ：
1、 Delete first token Delete after token;
(1) Deleting first may lead to , The business did not execute , Try again with the previous token, Due to anti weight design , The request still cannot be executed .
(2) Post deletion may result in , Successful business processing , But the service flashed , There is a timeout , Not deleted token, other People continue to try again , Cause the business to be executed
(3) We'd better design to delete token, If the business call fails , Just get back token Ask again .
2、Token obtain 、 Comparison and deletion must be atomic
(1) redis.get(token) 、token.equals、redis.del(token) If these two operations are not atoms , May lead to Cause , High and low , all get To the same data , All judgments are successful , Continue business and execute concurrently
(2) Can be in redis Use lua The script does this
if redis.call(‘get’, KEYS[1]) == ARGV[1] then return redis.call(‘del’, KEYS[1]) else return 0 end

2、 Various locking mechanisms

1、 Database pessimistic lock
select * from xxxx where id = 1 for update; Pessimistic locks are usually used with transactions , Data locking time can be long , It needs to be selected according to the actual situation . Another thing to note ,id Fields must be primary keys or unique indexes , Otherwise, it may cause the result of locking the watch , Dealing with it will Very trouble .

2、 Database optimistic lock
This method is suitable for updating scenarios ,
update t_goods set count = count -1 , version = version + 1 where good_id=2 and version = 1 according to version edition , That is to say, before operating the inventory, we first get the information of the current commodity version Version number , Then when operating Take this version Number . Let's sort out , The first time we operated inventory , obtain version by 1, Call inventory service version Turned into 2; But there's a problem going back to the order service , The order service starts calling the inventory service again , When order A single service is transmitted as version still 1, Then execute the above sql When the sentence is , They don't execute ; because version It has changed by 2 了 ,where Conditions don't hold . This ensures that no matter how many calls are made , It will only be dealt with once . Optimistic locking is mainly used to handle Read more and write less The problem of .

3、 Business layer distributed lock
If multiple machines can process the same data at the same time , For example, multiple machines get the same number of scheduled tasks According to the processing , We can add distributed locks , Lock this data , Release the lock after processing . To obtain a lock, you must first judge Whether this data has been processed .

3、 Various unique constraints

1、 Database unique constraints
insert data , It should be inserted according to the unique index , Like the order number , It is impossible to insert two records into the same order . We prevent duplication at the database level .

This mechanism takes advantage of the unique constraint of the primary key of the database , Solved in insert Scene time idempotent problem . But the primary key The requirement is not a self increasing primary key , In this way, the business needs to generate a globally unique primary key . In the scenario of sub database and sub table , Routing rules should ensure that the same request , Landing in the same database and table , want Otherwise, the database primary key constraint will not work , Because different databases and table primary keys are not related .

2、 The database uses atomic operations ： Add without this data , Modify with this data
The database is not added , Modify if you have

3、redis set Anti weight

A lot of data needs to be processed , Can only be processed once , For example, we can calculate the data MD5 Put it in the redis Of set, Every time you process data , Look at this first MD5 Does it already exist , If it exists, it does not deal with .

4、 Counterweight gauge

Use order number orderNo As the unique index of de duplication table , Insert the unique index into the de duplication table , Conduct business operation again , And They are in the same business . This ensures that repeated requests , Because there is a unique constraint to the de duplication table , Cause the request to fail , avoid The idempotent problem is avoided . What we should pay attention to here is , The de duplication table and the business table should be in the same database , This ensures that in the same Business , Even if the business operation fails , It will also roll back the data of the de duplication table . This is a good guarantee of data consistency .

As I said before redis Weight prevention is also

5、 Global request unique id

When calling the interface , Generate a unique id,redis Save data to collection （ duplicate removal ）, Exist is processed .
have access to nginx Set unique for each request id;
proxy_set_header X-Request-Id $request_id;