How to effectively handle data concurrency issues

This article data concurrency problems I have encountered in a real project as a background, the reasons to explain the problem and solution, and the resulting reflection from. Concurrency stepped on a lot of the pit, where there may be inadequate, but it will always grow and learn, will learn something now recorded ,,,, efforts efforts.

A: The reason appears concurrent operation

Reason: a plurality of simultaneously operating operation of the same data at the moment

phenomenon:

  1. People in a moment by the operation of the same data in the same manner
  2. Operation than in a moment the same data in different ways
  3. In a moment, the same action multiple times

II: Concurrent Examples and Solutions

For three of the above, for example the actual situation, respectively.

[ People in a moment by the same manner as the operation of the same pieces of data ]

1. Storage system has a certain brand product A, product A in the database allows only one record, the number of stocks is a field of this data, the existing inventory 100, one day in 1000 arrival. As the number of large, now need 10 operators to handle the 1000 commodity warehousing, the way the operation is carried out using a PDA storage after the scan is complete. We assume that there is at least one operator simultaneous storage operation. This would address the above-described conditions [ people in the same way a certain moment the operation of the same pieces of data ]. In this case, if untreated, can lead to data disorder, disorder of the reason simply is not to get the latest database data when both the write data.

Solution:

Method One: lock. Locking is a more commonly used method. From the architecture of the system, the lock is divided into stand-alone key and distributed lock. If the system is only deployed on a single machine, it can be operated by a variety of simple lock provided java. If the system is deployed on multiple machines, you can use redis to implement a distributed lock. Both ways are pessimistic locking lock in a sense. The above-mentioned problems, the only thing we can use the product attributes, such as id unique bar code or merchandise to be locked.

Method two: database optimistic locking. Database lock is suitable for almost all optimistic concurrency scenarios. Usage: add a version number field in a database table, every update and delete when the current version number and hold objects in a database the latest version for comparison, if the same is verified, otherwise the operation fails.

Method 3: Use the message queue. This way when too many messages, handling of inventories may not be particularly timely. Since stocks usually require more timely visibility, so this approach is not recommended.

[ People in a moment in different ways operate the same article data ]

2. It is in accordance with the above background. Simultaneous storage in these 10 operators, as well as at least one operator of a commodity A library operation. We assume no concurrent problems of storage, but one out of storage and a library at the same time operating inventory A goods, operate on stock in two different ways. If left untreated, the disorder inventory data will be problems.

Solution:

Method One: lock. This time using an ordinary stand-alone key has no meaning, you can use distributed lock, still using a unique property to lock, despite the different methods, but the key is the same key, so that you can lock operation.

Method two: database optimistic locking.

For the above-mentioned problems, I extend that, if a group of commodity, you can not be a lock a deal with it, so efficiency is too low. So in this case, a simple lock can no longer meet current needs. So the database optimistic locking reappeared. When the batch update and found the version number of any commodity is inconsistent, error immediately rolled back.

[In a moment, the same actions , multiple times ]

3. This situation repeatedly submit requests belonging to the same, if not treated, the data will have problems.

When a user submitted warehousing repeated twice, so without considering the impact of other concurrent data inventory will increase more than once, but in the history of storage but can only see one record, this is certainly not acceptable .

Solution:

Method One: foreground can be disabled immediately after the first click a button or link. This can effectively solve most of the problems. However, due to the ever-changing operations end, this approach does not fully solve the problem.

Method II: generates a random number background to the foreground, the background when accessing the foreground, the background will transmit the random number to be verified, immediately destroyed by the first authentication, the random number may be present or redis session it is generally used for the form is submitted. However, this approach is flawed, if there are multiple requests for the same page, a random number is completely not enough.

Method three: nginx ip can control the frequency of access services at the same time. For example when storage, if a number of clicks, a number of requests sent, for this one second, the system only receives the first request.

 

Three: summary

The final principle is actually concurrent processing: the user's operation becomes parallel serial operation.

In solving concurrency problems, from operating the service end to end, and then to the database, we need to be processed, layers of filtration.

Front: prevent multiple clicks.

Server: operations on the same data is written in the same service.

Database: Be sure to use optimistic locking. The need arises, joint database should also prepare a unique index.

Four: Extended

So far, there are related project experience (warehouse) Readers may find some problems. The question is: not enough inventory of elegant design, which leads to a lot of concurrency generated. For example, 10 operators in the warehouse, why Operation A commodity inventory to increase inventory it? In fact, all inbound and outbound, including inventory, are in order to be able to prompt the user to see inventory only. Now that we know the inventory calculation, we can calculate the corresponding inventory, and also reduce the number of concurrent operations.

The next article, I will design a highly available, and fewer concurrent operation of warehouse systems. Interested students can follow me ah!

Say there is something wrong, please correct me a lot.

thank! thank! thank!

Published 21 original articles · won praise 18 · views 7577

Guess you like

Origin blog.csdn.net/love1793912554/article/details/92437035