Explain service idempotency design in detail

hello, Hello everyone , I'm Zhang Zhang ,「 The road to the advanced architecture 」 The public name author .

Introduction

In some technical design scheme review meetings in daily work , It is often mentioned that attention should be paid to the idempotency of service interfaces , Recently, a classmate ran up to me and asked me , What is idempotency ？

At present, there are many problems / Microservicing today , The service capabilities provided are rich and diverse , be based on HTTP Agreed Web API It's the most popular way to provide distributed services , It is particularly important to guarantee the idempotency of services .

I thought about it , I think it's necessary to popularize it to everyone .

Today, we plan to discuss a series of questions about service idempotency , Summarize and sort out the materials here , Share with you ~

1、 What is idempotency ？

idempotent （idempotence）, It comes from a concept in Mathematics , for example ： Idempotent function / Idempotent methods （ Refers to the repeated execution of... With the same parameters , And can get the same result function , These functions do not affect the system state , You don't have to worry about repeated execution that will change the system ）.

Simple understanding is ： The impact of multiple calls on the system is the same , That is, it has the same effect on resources .

Idempotency emphasizes the influence of the outside world on the inside of the system through the interface , As long as one or more calls should have the same side effects on a resource .

Be careful ： This means that the side effects on resources must be the same , But the return value is allowed to be different ！

2、 What are the main scenarios of idempotency ？

According to the definition of idempotency above, we know that ： Produce duplicate data or data inconsistencies , Most of this is due to repeated requests .

The repeated request here means that the same request is initiated multiple times in some cases .

What scenarios will lead to this situation ？

• Microservices architecture , There will be a large number of micro services based on http,rpc perhaps mq Network communication of messages , There will be a third situation 【 Unknown 】, That's timeout . If I run out of time , Microservice framework will retry .

• Multiple clicks during user interaction , Inadvertently trigger multiple transactions .

• MQ Message middleware , Message re consumption

• Third party platform interface （ Such as ： Payment success callback interface ）, Because exceptions can also cause multiple asynchronous callbacks

• Other middleware / Application services according to their own characteristics , It is also possible to retry .

3、 What is the function of idempotency ？

Idempotency main guarantee The impact of multiple calls on resources is consistent .

Before describing the role , Let's use the resource processing application to illustrate ：

HTTP And database CRUD Operation corresponds to ： 

   PUT ：CREATE

   GET ：READ

   POST ：UPDATE

   DELETE ：DELETE

（ It's not just databases , This is true of any data such as a file chart ）

1） Inquire about

      
   
   
   
         
    
    
    
SELECT * FROM users WHERE xxx;

No changes to the data , Nature is idempotent .

2） newly added

      
   
   
   
         
    
    
    
INSERT INTO users (user_id, name) VALUES (1, 'zhangsan');

case1： With unique index （ Such as ：`user_id`）, Repeated insertion will result in subsequent execution failure , Have idempotence ;

case2： Without a unique index , Multiple insertions can lead to data duplication , Not idempotent .

3） modify

case1： Direct assignment , No matter how many times score Are all the same , Idempotent .

UPDATE users SET score = 30 WHERE user_id = 1;

case2： Calculation and assignment , Every operation  score  The data are different , Not idempotent .

UPDATE users SET score = score + 30 WHERE user_id = 1;

4） Delete

case1： Absolute value delete , Repeat many times, the result is the same , Idempotent .

DELETE FROM users WHERE id = 1;

case2： Relative values are deleted , Repeated several times, inconsistent results , Not idempotent .

      
   
   
   
         
    
    
    
DELETE top(3) FROM users;

summary ： Usually you only need to write requests to （ newly added & to update ） Guarantee idempotency . 

4、 How to solve the idempotent problem ？

We search the Internet for solutions to idempotency problems , There will be all kinds of solutions , But how to determine which solution is the best solution for your business scenario , In this case , We need to grasp the essence of the problem .

After the above analysis , We find that the idempotency problem is To control write operations to resources .

We analyze and solve the problem from each link process ：

4.1 Control duplicate requests

The control action triggers the source , That is, the front end performs idempotent control to realize

Relatively unreliable , No fundamental solution , Only as a secondary solution .

The main solution ：

• Control the number of operations , for example ： The submit button can only be operated once （ The button is grayed out after submitting the action ）

• Redirect in time , for example ： Place an order / After the payment is successful, jump to the success prompt page , This eliminates the problem of repeated submission caused by browser forward or backward .

4.2 Filter repetitive actions

Control filter repeat action , It refers to controlling the number of effective requests during action flow .

1） Distributed lock

utilize Redis Record the business ID currently processed , When it is detected that this task is not in process , Enter processing , Otherwise, it will be judged as repeated request , It can be filtered .

Order initiate payment request , Payment system will go Redis In the cache, you can query whether there is a Key, If it doesn't exist , to Redis increase Key Is the order number . Query order payment has been paid , Pay if not , Delete... Of this order number after payment Key. adopt Redis Achieve distributed lock , Only this order payment request is completed , You can't come in until next request .

Distributed phase lock ratio de duplication table , Put concurrent into cache , More efficient . The same way of thinking , Only one payment request can be completed at a time .

2）token token

The application process is as follows ：

1） The server provides sending token The interface of . Get... Before doing business token, At the same time, the server will send token Save to redis in ;

2） Then, when the business side initiates a business request , hold token Take it with you , Generally placed in the request header ;

3） Server judgment token Whether there is redis in , Existence is the first request , Can continue to perform business , After the execution of the business is completed token from redis Delete in ;

4） If you judge token non-existent redis in , It means repeat operation , Direct return to repeat mark to client, This ensures that the business code will not be executed repeatedly .

3） Buffer queue

Follow all requests quickly , To access the buffer pipeline . The subsequent use of asynchronous tasks to process the data in the pipeline , Filter out duplicate request data .

advantage ： Synchronous to asynchronous , Achieve high throughput .

shortcoming ： Unable to return processing results in time , Asynchronous return data of subsequent listening and processing results is required .

4.3 Solve repeated write

Common ways to realize idempotence are ： Pessimistic locking （for update）、 Optimism lock 、 Unique constraint .

1） Pessimistic locking （Pessimistic Lock）

The simple understanding is ： Suppose every time you take the data , They think it's going to be modified , So lock the rows or tables of the database .

When the database executes select for update Will get the quilt select Row lock of data row in , So other concurrent execution select for update If you try to select the same line, rejection occurs （ Need to wait for row lock to be released ）, So achieve the lock effect .

select for update The acquired row lock will be released automatically at the end of the current transaction , So you have to use .（ Be careful for update To be used in the index , Or I'll lock the watch ）

      
   
   
   
         
    
    
    
START TRANSACTION; #  Open transaction SELETE * FROM users WHERE id=1 FOR UPDATE;UPDATE users SET name= 'xiaoming' WHERE id = 1;COMMIT; #  Commit transaction 

2） Optimism lock （Optimistic Lock）

The simple understanding is ： Is very optimistic , Every time I go to get the data, I think other people won't modify it . When updating, if version Changed , The update will not succeed .

however , Failure of optimistic lock , It's often said ABA problem , But if version The version has always been self increasing and will not appear ABA The situation of .

UPDATE users SET name='xiaoxiao', version=(version+1) WHERE id=1 AND version=version;

shortcoming ： Just before we operate the business , You need to find out the current version edition

in addition , There is also a ： State machine control

for example ： Payment status flow process ： To be paid -> In the payment -> Paid

With certain pre requirements , Strictly speaking , It also belongs to a kind of optimistic lock .

3） Unique constraint

It's common to use Database unique index perhaps Global business unique identifier （ Such as ：source+ Serial number, etc ）.

This mechanism takes advantage of the unique constraint of the primary key of the database , Solved in insert Scene time idempotent problem . But the requirement of primary key is not self increasing primary key , In this way, the business needs to generate a globally unique primary key .

overall situation ID Generation scheme ：

• UUID： Combine the network card of the machine 、 Local time 、 A random number to generate UUID;

• Database autoincrement ID： Using the database id Self increasing strategy , Such as MySQL Of auto_increment.Redis Realization ： By providing something like INCR and INCRBY Such a self increasing atomic order , Guaranteed to be generated ID It must be the only orderly .

• Snowflake algorithm -Snowflake： from Twitter Open source distributed ID generating algorithm , In the way of dividing the namespace, I will 64-bit Bits are divided into parts , Each part represents a different meaning .

Summary ： According to the optimal benefit of application , The recommended order is ： Optimism lock > Unique constraint > Pessimistic locking .

5、 summary

Usually , Non idempotent problem , Mainly Due to repeated and uncertain write operations Caused by the .

1、 The main thinking points for solving duplication

From request to whole process , Control duplicate request triggering and duplicate data processing

• client Controls the initiation of duplicate requests

• Server side Filter duplicate invalid requests

• Underlying data processing Avoid repeated write operations

2、 The main thinking points for controlling uncertainty

Change the service design idea , Try to avoid uncertainty ：

• Change the statistical variable to the data recording method

• Change the range operation to the confirm operation

Postscript

After listening to my above paragraph , He said as if full of harvest ： Probably understood ...

But out of a sense of responsibility , I have to tell him a few words ：

1） Idempotent treatment Although complex business processing , It may also reduce the execution efficiency of the interface , But in order to ensure the accuracy of system data , It's very necessary ;

2） Have a problem , Be good at discovering and excavating essential problems , Only in this way can we solve it efficiently and accurately ;

3） Choose a solution that suits your business scenario , Instead of trying to implement some off the shelf technologies , Whether it's combination or innovation , Remember that the right thing is the best .

I hope you can master the ability of problem analysis and solution , Don't rush to solve problems as soon as you come up , You can do more in-depth analysis , Understand the nature of the problem before considering solutions to solve .

I hope today's explanation will be helpful to you ,Thanks for reading!

  welfare ： Pay attention to the official account reply key ：Redis, Free access to 《Redis Design and implementation 》 e-book

·················· END ··················

Official account , Free learning materials

Ten years of R & D , Big factory architect ,CSDN Blogger

Focus on architecture technology learning and sharing , Career and cognitive upgrading

Insist on sharing the dry goods of the earth , Looking forward to growing with you

---

「 The road to the advanced architecture 」 Focus on Architecture Research , Technology sharing

spot “ Fabulous ” and “ Looking at ” Oh

This article is from WeChat official account. - The road to the advanced architecture （jiagou_jingjin）.
If there is any infringement , Please contact the [email protected] Delete .
Participation of this paper “OSC Source creation plan ”, You are welcome to join us , share .