Practical application cases of optimism and pessimistic locks in business

The choice of optimistic locks and pessimistic locks depends on business scenarios and data consistency requirements. 1. Pessimistic locks assume data conflicts, and locks ensure data consistency, but low efficiency under high concurrency, such as bank transfers; 2. Optimistic locks assume data conflict probability is low, and no locks are added, check whether the data is modified before update, with high efficiency but data inconsistency, such as e-commerce inventory management and forum comments; 3. In high concurrency scenarios, you can consider combining optimistic locks and pessimistic locks, first pre-processing of optimistic locks, and finally confirming pessimistic locks, taking into account efficiency and data consistency. The final choice requires the trade-off between efficiency and data consistency.

Optimistic lock and pessimistic lock: Trade-offs and choices in business practices

Optimistic lock and pessimistic lock, these two concepts sound mysterious, but in fact they are two completely different strategies when dealing with concurrent access to databases. Simply put, optimistic locks believe that "data generally does not conflict", while pessimistic locks believe that "data is likely to conflict". This article will not give you a boring definition, but will take you into the business scenarios to see how they play and how to choose the right solution based on actual conditions. After reading it, you can control these two lock mechanisms like an old driver based on business needs.

Let’s start with the basics. Pessimistic lock, as the name suggests, always assumes the worst case – concurrent modification. In order to avoid data conflicts, it will directly lock the data when accessing data. Typical examples are the transaction isolation level of the database and the mutex mechanism provided by some programming languages. Imagine bank account transfers. Pessimistic locks are like a strict security guard. Only one user can enter the operation at a time, and others can only wait in line. This ensures the consistency of the data, but efficiency... You know, especially when the concurrency is large, the waiting time will be long.

Optimistic locks are completely different. It believes that the probability of data conflict is very low, so it will not actively add locks. It will check whether the data has been modified before updating it. If it has not been modified, it will be updated; if it has been modified, it will prompt a conflict and let the user re-operate. This is like a flexible administrator, which allows multiple users to view and modify data simultaneously, and only perform verification when submitting modifications. This is much more efficient, but there are risks, that is, "dirty writing" may occur and needs to be handled with caution.

Let’s look at some actual cases.

Case 1: E-commerce product inventory management

Commodity inventory is a typical concurrent scenario. If you use pessimistic locks, you need to add a lock every time the user visits the product page or even just checks the inventory, which will lead to a serious performance bottleneck. And optimistic locking is very suitable. We can use the version number mechanism to achieve optimistic locking: each product has a version number, and each time the inventory is updated, check whether the version number is consistent. If it is inconsistent, it means that the data has been modified and update is refused. It's like a label posted on the product inventory, recording the number of modifications, and only when the label has not changed can it be modified.

 <code class="language-python">class Product:</code><pre class='brush:php;toolbar:false;'> def __init__(self, id, name, stock, version):
    self.id = id
    self.name = name
    self.stock = stock
    self.version = version

def update_stock(self, new_stock, current_version):
    if self.version == current_version:
        self.stock = new_stock
        self.version = 1
        return True # Update successful else:
        return False # Update failed, data has been changed

Simulate concurrent updates

product = Product(1, "iPhone", 100, 1)
thread1 = threading.Thread(target=lambda: product.update_stock(90, 1))
thread2 = threading.Thread(target=lambda: product.update_stock(80, 1))

thread1.start()
thread2.start()
thread1.join()
thread2.join()

print(f"final inventory: {product.stock}") #The result may not be 80 or 90, depending on the order of thread execution, showing the possible problems with optimistic locks

This code uses Python to simulate the implementation of optimistic locks. Note that this is just a simplified version, and issues such as the atomicity of database transactions need to be considered in actual applications. Have you seen it? Although optimistic locking is efficient, it may lead to data inconsistency and requires appropriate mechanisms to deal with conflicts.

Case 2: Forum post comments

Forum post comments, the concurrency volume is also very large. If you use pessimistic locks, every comment needs to be locked, which is too inefficient. Optimistic locks apply here too. We can use a mechanism similar to the version number, or use a timestamp to determine whether the data has been modified.

Case 3: Bank Transfer (Another emphasized)

As mentioned above, pessimistic locking seems to be a safer choice because it can ensure the consistency of data. However, if the concurrency volume is extremely high, the performance bottleneck of pessimistic locking will be very obvious. At this time, we can consider combining optimistic locks and pessimistic locks. For example, using optimistic locks for preprocessing in high concurrency scenarios, and using pessimistic locks for final confirmation only when the last commit is submitted. This can ensure both efficiency and data consistency. This requires more complex strategies and design.

In short, there is no absolute good or bad for optimistic locks and pessimistic locks. Which strategy to choose depends on the specific business scenario and the requirements for data consistency. In high concurrency scenarios, optimistic locks are usually more efficient, but data conflicts need to be handled with caution; while in scenarios with extremely high requirements for data consistency, pessimistic locks are more secure, but performance may become a bottleneck. When making a choice, you need to weigh efficiency and data consistency, and choose the appropriate solution according to the actual situation, or even use it in combination. Remember, there is no silver bullet, only suitable solutions. I wish you become a lock mechanism master!

The above is the detailed content of Practical application cases of optimism and pessimistic locks in business. For more information, please follow other related articles on the PHP Chinese website!