java - 怎么理解在生成订单的时候幂等性的控制

Question

经常听人说在交易系统中，生成订单的时候要控制好两个：一个是幂等性的控制，一个是并发性的控制。
我的理解是这样的，并发性的控制，可以从数据库层面上，利用锁表中行的操作，分布式锁的方式来实现并发性，那么幂等性呢？查了一些资料对于幂等性这个概念的理解，还是越看越模糊，有没有什么通俗的对于幂等性的解释呢？此外怎么在生成订单的系统中做好幂等性的控制呢？
所以我的问题是：
1、怎么通俗的理解幂等性 ？
2、如何在项目中做到幂等性的控制，防止订单碎片的产生？？

谢谢~~

Answer 1

Thank you~ In fact, your understanding is wrong~ I don’t know where you saw this information...
In fact... solving the concurrency problem... is not just a simple database lock... it requires a series of caches , diversion, filtering, etc. ~
And idempotence is just a convention ~ It is agreed that in the same operation, only one of the users will take effect ~ For example, when a user clicks and places an order, only one will take effect in practice... The solution is very simple~ Layer 2... The front-end control point cannot be clicked again... The back-end uniquely identifies the request~ and then saves it in the cache~ After that, only one will actually take effect~

I feel like the questions you asked these past few times are more like what is discussed in textbooks. Practical applications are far from that. It is recommended that you pay attention to some articles on technology. For example, the flash sale principle written by Taobao. Alibaba Cloud recently published high concurrency. The architecture of the red envelope system and other practical information summarized in actual production~

Answer 2

Idempotence is a promise (rather than an implementation) made by the system's interface to the outside world. It promises that as long as the interface is called successfully, multiple external calls will have the same impact on the system. An interface declared as idempotent will consider the failure of external calls to be normal. And there will definitely be a retry after failure.

As for preventing order fragmentation you mentioned, all I know is that it relies on transactions. I don’t know what they use in high-concurrency environments like Alipay.

Answer 3

Using tokens can not only prevent CSRF, but also prevent replay at the UI level.

Answer 4

A simple example to understand idempotence

public class Main {
    private int i = 0;
    
    //这个方法不具有幂等性，每调用一次，它就会改变Main的状态(即改变了i)
    public void idempotent() {
        i++;
    }
    
    //幂等性，无论这个方法调用多少次，它都不会改变Main类的状态。
    public void simple() {
        System.out.println(i);
    }
}

I understand that printing orders requires idempotence, which is a state where data cannot be printed when printing orders. No matter how many times the same order is printed, it will not affect the printing of other orders. This is easy to control. Don't modify the database data when printing orders. Fetch the data to the application side for processing, so that it will not cause fragmentation on the database side.

Answer 5

Equality refers to calls to the business system. If multiple calls occur, there will be no impact on the business system.
This requirement is very important in distributed systems, because in distributed systems, the database itself can no longer complete transaction control. Some message queues and asynchronous calls will be used. When encountering some abnormal situations, the remote call status will not change. When it is clear, it will try to call the remote service again. If the service does not have equality guarantee, the retry mechanism cannot be used.

The scenario of creating an order is not equitable. If it is called multiple times, multiple orders will appear. The usual solution is to query based on the passed information before creating an order. If it has been executed, directly return the successful call information to prevent duplicate orders.

Answer 6

Impotence can be understood as the GET request in HTTP (don’t say that sometimes the content is different when you visit the same website), and the POST request is non-idempotent. So most of the time, using GET is good! Don’t think that POST is safe because it hides the body data.

Answer 7

Idempotence solves the problem that if network reasons such as timeout occur in a distributed system, the client does not know whether the server has executed successfully or failed. At this time, the client needs to retry. If the interface is not idempotent. Will result in different expected results.

Simply put, if an interface is idempotent, the effect will be the same if you call it once or multiple times. For example

UPDATE table SET NAME="LILEI" WHERE UID='1'

Answer 8

UPDATE table SET NAME="LILEI" WHERE UID='1'