This article reprinted from: PingCAP public number; Author: Shirly
If in TiDB 3.0, the pessimistic lock is "long-awaited, still holds partly concealed." Then TiDB 4.0, the pessimistic locking after a market test of time, both performance and stability are able to "Qinglong twist slowly wiping complex challenges, first as a" "post" Seduction six unitary "," Welcome to early adopters and feedback. This article from the user's perspective, describes the use pessimistic locking and precautions, divided into the following areas:
-
Vernacular pessimistic locking
-
TiDB use pessimistic locking and common phenomenon
-
TiDB pessimistic locking and MySQL Compatibility
-
Future Prospects
Vernacular pessimistic locking
Since the New Year, masks as 2020's most fashionable New Year, became very difficult to buy, in order to successfully grab the mask, I was down every night, every day staring at a single major sites, through this process, they do She summed up the major platform of shopping experience:
-
A class website: Add Cart fast , successful Add to Cart add, the order is not necessarily in stock.
-
Class B website: Add Cart point card , after the success of the shopping cart order a certain stock.
As Internet research and development practitioners, intelligent as you, to think together how to achieve these two types of sites are added to cart this logic?
A class website optimistically assume that there are no other customers at the same time grab these masks, no inventory orders on behalf of the inventory, gave a very positive experience for the customer, we call the shopping cart add this behavior, use optimistic locking.
This experience is using optimistic locking: pre-cool plus cart moment, the final orders may not necessarily cool.
When the presence of other users at the same time grab these masks orders with you, you may encounter the following problems:
-
Submitted not succeed.
-
Conflict needs to be retried (other people get orders, inventory changes, needs to be retried).
-
Conflict serious and retry the high price scenario (for example one time you bought a million products) poor performance, high failure rate.
Class B sites can be described as cautious and assume that all the masks in someone's home shopping car ahead of you will be the next one, show it to your stock inventory in the current worst case scenario can be seen, we call this behavior plus the shopping cart, use pessimistic locking.
As experience is pessimistic lock: pre-plus Shopping Cart cards, but there must be added to cart successfully stock. No inventory Mo worry, wait a minute there may come a stock.
In the implementation of the database, when there are multiple transactions to modify the same row, it would also encounter similar conflict by implementing the pessimistic locking, optimistic locking can solve part of the problem, focusing on the following:
-
Transaction commit some success.
-
MySQL default support pessimistic locking, pessimistic locking support means, MySQL's customers do not need to modify any code, you can easily board TiDB.
TiDB use pessimistic locking and common phenomenon
TiDB support a variety of ways to open the pessimistic locking, detailed information, see the official documentation, for example paper will unfold describes the following ways:
-
Execute BEGIN PESSIMISTIC; open statement of affairs, will enter pessimistic transaction mode.
-
! Notes form BEGIN / * 90000 PESSIMISTIC * /; be compatible with MySQL syntax.
Concurrent updates to the same data row
The following diagram, the vertical axis represents a time axis, session A session B, and concurrently updating the same data row.
Pessimistic locking behavior can be seen as follows:
-
When performing DML session B, found in the same row is locked session A, wait until the session A submission was executed.
-
After the successful implementation of DML, ultimately commit successfully.
SELECT .. FOR UPDATE
Consistent with the example shown pessimistic locking Affairs and MySQL behavior, understood as follows:
-
Pure query SI isolation level is the isolation level, data that is read as a version of affairs begin.
-
SELECT .. FOR UPDATE isolation level for the RC, that is read as the current version of the data submitted.
DEADLOCK
Before looking at this case, we first think about why there is a deadlock, the same shopping as an example, assume that now the two small A and small B have to buy masks and disinfectant, you may experience the following scenarios:
That is, A and B have to buy two of these two commodities, one can only wait for each other, that is, we are talking about a deadlock state, it is similar in the database:
The example scenario illustrated in session A and session B creates a deadlock, the deadlock time, pessimistic locking is detected immediately and returns an error, the deadlock strangled in the cradle.
TiDB pessimistic locking VS MySQL InnoDB
As a distributed database TiDB been working on the agreement to maintain compatibility with MySQL, MySQL to benefit the majority of users. However, the underlying implementation TiDB and MySQL logical distinction, part of the logic that can not be completely compatible. In TiDB 4.0 in, TiDB pessimistic locking is not compatible with MySQL in the use of behavioral see the official documents, here we briefly describe the following points.
TiDB no gap lock
When we can not guarantee that the data meet the filter criteria only:
-
MySQL locks the filter condition that covers all the rows to: lock range, full table lock.
-
TiDB read only lock on to the line.
DETAILED comparison in the following table (Note: table in primary key id):
embedded select inconsistent behavior
TiDB DML performed in the process if the package contains embedded select, the corresponding row is not locked, MySQL will be locked.
Future Prospects
Affairs as the most important database, has been the focus of public attention. Since the birth of TiDB to support high-performance distributed transaction is known. From the user's perspective, introduced TiDB 4.0 in pessimistic locking use and precautions, we welcome early adopters and feedback.