scenes to be used:
Recently, I encountered a concurrent registration problem of the account dubbo service, and a large number of primary key conflict problems were thrown in the log. There are multiple SQL operations in the process of registering users, and these SQLs can implement single-machine local transactions. In order to solve so many log exceptions, how to deal with distributed concurrent requests?
Solution:
One: cache method
Atomic operation CAS is used to write to the cache, and only one of multiple concurrent requests can write successfully at the same time.
a) If the non-idempotent case is not successfully written, it will directly return false. Did not get the lock.
b) In the case of idempotency, polling is required, and there are three results: the lock is grabbed, the polling succeeds without a lock, and the polling fails without a lock, which is processed according to the business. Because the account can guarantee the transaction, if the polling fails, the registration is performed directly.
So what are the other ways to achieve this distributed request preemption function?
Two: with the help of the database
a) unique key
Implementation principle:
Multiple requests to insert a record at the same time, only one can be inserted successfully, delete the data after the request to get the lock is processed, and return or select the polling attempt if the lock is not obtained.
shortcoming:
1. Non-blocking lock, return immediately, only polling or return failure
2. The application is down, who will release the lock
3. How to implement a reentrant lock
Summarize:
I don't think my scenarios 1 and 3 are a problem. Just consider how to release the lock when the application is down. If a scheduled task is used, the scheduled task needs to determine the current time and the lock time of the lock. If it is greater than the execution time of the transaction, delete it. Drop this lock. However, if the lock is deleted, the current request may only be half done, and other requests also come in, which will evolve into a consistency problem, which requires distributed transactions.
b) for update
Implementation principle:
start tran; select * for update If it succeeds, it will return immediately, if it fails, it will wait, which solves the problem of non-blocking locks, and the downtime will also release the lock, but the reentrant lock will not work
Three: Redis method
Four: zookeeper