Original address: Liang Guizhao’s blog
Blog: blog.720uenterp rise
Welcome to reprint, reprint please indicate the author and source, thank you!
Before, we discussed the implementation of idempotent mechanism. Today, we will discuss whether distributed locking is a way to control concurrent idempotent mechanism. Multiple commits may result from repeated commits on the client side or from the retry mechanism on the server side. In this case, it is not enough to pass the anti-repetition mechanism alone, but also need the idempotent mechanism of the server to ensure uniqueness. At its core, idempotent mechanisms ensure resource uniqueness, such as repeated client commits or multiple server retries resulting in only one result. Payment scenarios, refund scenarios, transactions involving money can not appear multiple deductions and other problems. In fact, the query interface is used to fetch resources, because it only queries data and does not affect resource changes, so no matter how many times the interface is called, the resource does not change, so it is idempotent. The new interface is non-idempotent, because the interface is called multiple times, resulting in resource changes. Therefore, we need idempotent processing when repeated commits occur.
Note that to avoid concurrent scenarios, we can ensure data uniqueness through locking mechanisms such as pessimistic and optimistic locking. Distributed locking is a commonly used scenario here, and it is typically a pessimistic implementation of locking. However, pessimistic locking, optimistic locking, and distributed locking are often viewed as solutions to idempotent mechanisms, which is incorrect. Concurrency control is only to ensure the safety of critical area resources, no dirty data, if concurrency control, multiple submission is legal, but business is illegal, so do idempotent control.
Therefore, the distributed lock is not the way to control concurrent idempotent, and the idempotent mechanism should be used to ensure the uniqueness of data when submitting records, so as to ensure that no matter how the timeout time is set, the problem of idempotent control will not occur.
(after)
More wonderful articles, all in the “server-side thinking” wechat public account!
