Pessimistic lock
- The concept of pessimistic lock
Pessimistic lock, as its name suggests, has strong exclusive and exclusive characteristics. It refers to a conservative attitude towards data being modified by the outside world (including other current transactions of the system and transaction processing from external systems). Therefore, the data is locked during the entire data processing process. The realization of pessimistic locking often relies on the locking mechanism provided by the database (and only the locking mechanism provided by the database layer can truly guarantee the exclusivity of data access, otherwise, even if the locking mechanism is implemented in this system, it cannot be guaranteed that the external system will not be modified. data).
In short, pessimistic locks are mainly used to protect the integrity of data. When multiple operations are executed concurrently, and a certain operation applies a lock to the data, other operations can only modify the data after the operation is completed.
- Pessimistic lock example
In a commodity purchase scenario, when multiple users place an order for a commodity with limited inventory at the same time. If the inventory quantity is changed by checking the inventory first and then reducing the inventory, it will lead to oversold.
If the pessimistic lock is used, when user A obtains the inventory data of a certain product, user B will block, and user B will not be able to obtain the inventory data of the product until user A completes the entire transaction of reducing inventory. You can avoid oversold goods. Of course, this is just an example for easy understanding. If it is a system with a large number of users, this operation is certainly not friendly.
Optimistic lock
- The concept of optimistic locking
Optimistic Locking (Optimistic Locking) Relative to pessimistic locking, the optimistic locking mechanism adopts a more relaxed locking mechanism. In most cases, pessimistic locking relies on the database lock mechanism to ensure the maximum exclusivity of the operation. But what comes with it is a lot of overhead in database performance, especially for long transactions, which is often unbearable. The optimistic locking mechanism solves this problem to a certain extent. Optimistic locks are mostly implemented based on the data version (Version) recording mechanism. What is data version? That is to add a version identifier to the data. In a version solution based on a database table, it is generally achieved by adding a "version" field to the database table. When reading out the data, read this version number together, and add one to this version number when updating later. At this time, the version data of the submitted data is compared with the current version information of the corresponding record of the database table. If the version number of the submitted data is greater than the current version number of the database table, it will be updated, otherwise it is considered as outdated data.
- Optimistic locking example
In a financial system, when an operator reads user data and makes modifications based on the read user data (such as changing the user account balance), if a pessimistic lock mechanism is adopted, it means that the entire operation process (The whole process from the operator reading out the data, starting the modification to submitting the modification result, even including the time when the operator goes to brew coffee in the middle), the database record is always locked. It is conceivable that if you face hundreds of thousands Concurrency, what consequences will this situation lead to.
The optimistic locking mechanism solves this problem to a certain extent. Optimistic locks are mostly implemented based on the data version (Version) recording mechanism. What is data version? That is to add a version identifier to the data. In a version solution based on a database table, it is generally achieved by adding a "version" field to the database table.
When reading out the data, read this version number together, and add one to this version number when updating later. At this time, the version data of the submitted data is compared with the current version information of the corresponding record of the database table. If the version number of the submitted data is greater than the current version number of the database table, it will be updated, otherwise it is considered as outdated data.
Now suppose there is a version field in the account information table in the database, the current value is 1; and the current account balance field (balance) is $100.
method one:
- Operator A reads it out (version=1) and deducts $50 ($100-$50) from his account balance.
2. During the operation of operator A, operator B also reads this user information (version=1 ), and deducts $20 ($100-$20) from his account balance.
3. Operator A completes the modification work, adds one to the data version number (version=2 ), and submits it to the database for update along with the account deduction balance (balance=$50 ). At this time, because the submitted data version is greater than the current version of the database record, The data is updated and the database record version is updated to 2.
4. Operator B completed the operation and also increased the version number by one (version=2) and tried to submit data to the database (balance=$80 ), but at this time, when comparing the database record version, it was found that the version number of the data submitted by operator B was 2. , The current version of the database record is also 2, which does not meet the optimistic locking strategy of "the submitted version must be greater than the current version of the record to perform the update". Therefore, the submission of operator B is rejected.
In this way, it is avoided that operator B overwrites the operation result of operator A with the result of old data modification based on version=1.
Method 2:
1. Operator A reads balance=100 at this time, and deducts 50 (100-50) from his account balance.
2. During the operation of operator A, operator B also reads this user information balance=100, and deducts 20 (100-20) from his account balance.
3. Operator A submits the deduction (100-50), together with the account balance=100 originally queried as the update condition, and submits it to the database for update. At this time, the submitted update condition balance=100 is equal to the balance in the original database. , Find this piece of data and update it.
4. Operator B completed the operation and tried to submit data (100-20) to the database, and used the previously queried balance=100 as the update condition, but at this time the account balance in the comparison database is already (50), and operator B The submitted condition balance is 100 originally queried, so the database cannot find this record, and operator B's submission operation fails.
In this way, it is also possible to avoid the possibility that the result of operator B's old data modification overwrites the result of operator A's operation.
Reprinted from: https://www.kancloud.cn/mikkle/thinkphp5_study/359349