Database deadlock is a very serious problem for the business, and it must be caused by improper handling of the code execution process.
However, refactoring a huge business code is not something that can be easily done by talking about it. Some solutions are given below, from the shallower to the deeper, to tell you the correct way to solve the deadlock problem.
Causes and conditions of deadlock problems
The deadlock problem generally occurs when multiple concurrent tasks modify the same set of tables in a short period of time.
The database locks when updating data to ensure that no concurrent data writing occurs.
The MySQL locking mechanism is to lock according to the index situation, which may be a row lock or an interval lock (for details, please refer to the document: https://dev.mysql.com/doc/refman/8.0/en/innodb-locks- set.html)
When modifying table A concurrently, only one request can acquire the lock, and the remaining requests need to wait for it to finish processing and release the lock before the next round of competition can proceed.
If the thread T1 that acquired the lock of table A needs to modify table B at the same time, but the lock of table B is acquired by thread T2, and T2 is waiting for the lock of table A, this causes the two threads to wait for each other, and then deadlock.
Solution
1. Add an index to the table
When MySQL locks a table, the scope of the lock is affected by the index. If the where condition happens to be covered by an index when updating the table, then MySQL can precisely lock the row records that meet the condition, without locking the data in a range (even the entire table).
Adding an index to the table that needs to be updated and covering the fields in the where condition can alleviate the collision probability of locks to a certain extent and reduce the number of deadlocks.
2. Update the table using the primary key
The principle of this method is the same as that of method 1, and it also uses indexes to lock the database accurately. Because the primary key is naturally an index, there is no need to add additional indexes to the table.
3. Shorten the transaction duration or cancel the transaction
Many database frameworks or libraries provide transaction management mechanisms. By default, they use AOP to cut into transaction management behavior.
However, this transaction management behavior is very crude and poses a problem: if the method executes for a long time, the transaction will also last for a long time. The longer the transaction, the greater the probability of lock collision.
If developers are familiar enough with frameworks and libraries and have a good understanding of database transactions, they can consider manually controlling transactions and adopting a programmatic transaction management method to allow applications to start transactions only when they need to access the database.
Alternatively, if the system does not emphasize transient consistency and there are no concurrent access data conflicts, transactions can be eliminated entirely.
4. Use a reasonable programming paradigm
The 123 method can only alleviate the collision probability of database table locks, but it is not the fundamental way to solve the deadlock problem.
The deeper reason for the deadlock problem is: the application program accesses the database out of order, and the process control is unreasonable.
A clear and neat programming paradigm can not only effectively improve the readability of the code, but also reduce the number of visits to the database (and external services) to achieve higher program performance.
//1. Collect data
var requiredData = queryFromDatabase()
//2. Process data
process(requiredData)
//3. Persist the processed data
saveToDatabase(requiredData)
In addition, try not to access the internal database in the loop, collect all the necessary information before the loop starts, and persist it to the database after the loop ends.
5. Use cache to process heat data
The ability of RMDB to handle intensive small transactions is not weak, but if the data processed concurrently overlaps, there will be a hidden danger of deadlock. If you want to solve the problem of RMDB in this area, you need to invest a lot of energy to optimize the code flow and fine-tune the control of transactions.
If you use cache to process hot data, you can cleverly avoid the defects of RMDB in this regard.
The cache can use a local cache or a distributed cache, which is determined by the design and architecture of the system.
6. Other methods
In addition to the above five methods, there are many ways to solve the transaction deadlock problem, such as: other advanced programming models, specific middleware support, and open thinking. But no amount of optimization techniques is as good as designing an efficient program structure.