当前位置:网站首页>Interface idempotent design

Interface idempotent design

2020-11-10 16:01:23 army

Because the caller is highly available for sending messages , So there will be a retrial mechanism . If there is such a scene :
service A Call the service B, At this point, the first request , Because of the Internet , service B Delayed receipt of this request , Or services B Reply service A When , service A received , Lead to service A Sent the same request again . here , service B And then we processed the request again , If the request is to operate on the database , For example, the amount of deduction , That's a lot of trouble .
image.png
First , Let's first see if the interface needs idempotency . The following two don't need to be idempotent :

  1. If it's just a query operation , No matter how many times it's called , The result is the same , So query operations don't need to be idempotent .
  2. If business permits , For example, the number of likes is 10000 still 10001 Less important , That doesn't have to be idempotent .

Basically, the new database 、 modify 、 All deletions need idempotency .

newly added

When it's added , The only identifier is the primary key ( How is the primary key generated in the distributed environment ?), So even though you insert it many times , Only one piece of data can succeed , In this case, the addition is idempotent . If the primary key is generated by the database , That requires a unique index to avoid inserting duplicate data , This time is also idempotent . If you need a database to generate a primary key , There's no unique index , Then there is no way to guarantee the idempotency . So make sure that the new idempotent , You have to generate your own primary key ( recommend ), Or create a unique index .

modify

There are two cases of revision ( Here, we only consider asking to try again , Regardless of concurrency , Concurrency is discussed in distributed locks ), One is direct assignment , One is relative assignment .

#  Direct assignment 
update table set num=5 where id=1;
#  Relative assignment 
update table set num=num-1 id=1;

If it's a direct assignment , No matter what num How many assignments 5, The results are 5, So if it's a relative assignment , At this point, it will always decrease 1. At this point, you should first query from the database num, The result is 5, service A Calculation num-1, And then the results 4 To the service B, service B No matter how many times set num=4 Are all the same , Idempotent is like this .
image.png

Delete

There are two cases of deletion , One is to delete the specified value , One is to delete range values .

#  Direct assignment 
delete from table where id=1;
#  Relative assignment 
delete from table order by id desc limit 3;

If it is the specified value, delete it , The first deletion returns 1, The second deletion returns 0, No matter how many times , There's no database id=1 Information about , So it's idempotent .
If it's a range value, delete , Delete for the first time 3 individual , The second execution deleted 3 individual , So it's not idempotent . The method is similar to the above , First, delete the id Find out , obtain 10,9,8, And then delete what needs to be deleted id(10,9,8) To the service B, service B No matter how many times you delete id(10,9,8), There's no database id(10,9,8) Information about , There's no extra information to delete , So it's idempotent .
image.png

版权声明
本文为[army]所创,转载请带上原文链接,感谢