How to solve the concurrent phenomenon of lock grabbing in distributed development

In the process of system development, problems such as repeated data insertion, repeated update and message retransmission are often encountered. Because of the complex logic of the application system and the uncertainty of network interaction, this phenomenon will occur repeatedly, but some logic needs to have idempotent characteristics, otherwise the consequences will be more serious, such as creating orders repeatedly, which brings extraordinary problems this time.

What is the idempotency of a system

Idempotent is a concept in data, which means that the result of n transformation is the same as that of 1 transformation.

How to ensure idempotency in high concurrency system?

1. Ask

The query API can be said to be naturally idempotent, because you query once and twice, and there is no data change for the system, so querying once is the same as querying many times.

2.MVCC plan

Multi-version concurrency control, conditional update and conditional update are also optimistic locking's reasonable choices when designing the system. optimistic locking will be carried out through versions or other conditions to ensure that the timely update will not cause too much problems in the case of concurrency.

For example: updatetable _ xxxsetname = # name #, version = version+1whereversion = # version #, or updatetable _ xxxsetquality = quality-# sub-quality # wherequality-# sub-quality # > = 0.

3. Separate and repeated forms

If there are many places to be duplicated, such as various business documents in ERP system, each business document needs to be duplicated. At this point, you can create a duplicate table separately, and when inserting data, use the unique index characteristics of the database to insert the duplicate table to ensure unique logic.

4. Distributed lock

Let's take inserting data as an example. If it is a distributed system, it is difficult to establish a unique index. For example, a unique field cannot be determined. At this point, distributed locks can be introduced. Through the third-party system, you can insert or update data in the business system, obtain the distributed lock, and then release the lock. This is actually the idea of multi-thread concurrent locking, which is a solution in distributed system.

deleted data

When deleting data, only the first deletion is the real operation data, and the second or even the third deletion directly returns success, thus ensuring idempotency.

6. Insert a unique index of data

Business primary key can constrain the uniqueness of inserted data. For example, in a specific business scenario, uniqueness must be determined by three fields. Then, you can add a unique index to the database table for tagging.

Here is a scenario, an API-level idempotent, such as how to control the repeated submission of data. Here, you can add a unique tag to the form or client software that submits data, and then the server will delete duplicates according to this UUID, so that you can better realize the unique tag at the API level.

7. Idempotent state machine

When designing a document-related business or a task-related business, a state machine will be involved, that is, there is a state on the business document, and the state will change under different circumstances. There is generally a finite state machine. At this point, if the state machine is already in the next state, it is theoretically impossible to change the last state. In this case, the idempotency of the finite state machine is guaranteed.

The above is the data collation of data idempotent solutions in high concurrency systems, and we will continue to supplement relevant knowledge in the future. Thank you for your support of this site!