Idempotency practice operation, explaining idempotency based on business

The question about idempotence was also mentioned in the previous interview , I checked Baidu about its concept, but it's very simple , But I don't quite understand , Discuss with someone today , Then I understood it in combination with reality .

• Idempotent concept comes from mathematics , Express N Secondary transformation and 1 The result of secondary transformation is the same . Here we discuss in some scenarios , When the client invokes the service and does not achieve the expected result , Multiple calls will be made , To avoid side effects on service resources caused by repeated calls , The service provider will promise to meet idempotent .

• HTTP/1.1 The definition of idempotence in is ： One and more requests for a resource should have the same side effects on the resource itself （ Except for network timeout and other problems ）. in other words , The impact of any multiple execution on the resource itself is the same as that of one execution .

• In a nutshell ： Call the same interface multiple times , The result returned is the same .

In fact, we may have done it in the actual code idempotent But because we don't know this concept, we don't know （ In fact, there are many such situations ）

You may not understand the concept alone , Here are two examples , One is what my colleague told me , One is my previous practical example .

One 、

There is an order receiving operation in the work order system , One work order can be distributed to multiple people , Everyone can take orders , The rule is whoever receives it first .

If we don't Idempotent processing Then it will happen that the second person covers the first person's order .

The error operation is as follows ：
Assign work order to A、B Two people , then A、B At the same time, enter the order receiving interface , Now A The order is accepted , however B There's a call , He went to answer the phone , After answering the phone, he still stayed in the order receiving interface , Then he took the order .

The transformation is as follows ：

1. Get... Every time you come in Redis Inside key, Judge whether it exists , If it doesn't exist, go on
2. Judge the status of the current work order , Is it equal to To be received , If it's going down
3. Use work order id As key Deposit in Redis Go inside （ Distributed lock implementation ）
4. Execute a series of business logic
5. Delete Redis Inside key

Pseudo code implementation ：

public String fun(String id) {
    
    if (RedisUtils.get(id) != null) {
    
        return " The work order has been received ";
    }
    RedisUtils.put(id,id);
    if (testDao.getStateById(id) != 3) {
    
        return " The work order has been received ";
    }
    //  Execute specific business logic 
    //......

    if (RedisUtils.get(id) != null) {
    
        RedisUtils.delete(id);
    }
    return " Successful operation ";
}

Two 、

This is a typical payment scenario ： User payment and order scenario , Theoretically, an order user can only pay once , But if you don't do idempotent processing, you may pay multiple times .

The error operation is as follows ：

Stuck because of the network or various reasons , The user refreshes the page and clicks pay again , This will result in two payments

The transformation is as follows ：

1. Lock the button every time you click pay .（ But refreshing the page will cause unlocking ）
2. Return to the front end after payment , The front end jumps to the payment success page .
3. Get... Every time you come in Redis Inside key, Judge whether it exists , If it doesn't exist, go on
4. Judge the status of the current order , Is it equal to To be paid , If it's going down
5. Use order id As key Deposit in Redis Go inside （ Distributed lock implementation ）
6. Execute a series of business logic
7. Delete Redis Inside key

This is the same as the above code implementation, so it is no longer written .