分布式锁拯救不了并发？——你真正需要的是乐观锁和悲观锁

后端

2023-12-31 08:20:02

并发之痛：分布式锁的局限性

并发访问共享资源的挑战

在分布式系统中，当多个用户同时访问共享资源时，可能会导致竞争条件和数据不一致。为了解决这个问题，引入了分布式锁，作为一种协调机制，以确保在任何给定时间，只有一个请求可以访问共享资源。

分布式锁的类型和机制

分布式锁有各种实现，包括基于数据库、缓存、ZooKeeper和Redis的锁。这些锁都是悲观锁，这意味着它们在访问共享资源之前获取锁，并持有锁直到请求完成。

悲观锁的局限性：性能代价

虽然悲观锁可以保证数据一致性，但它们也有一个缺点，即它们会降低性能。获取锁的过程涉及跨多个节点的通信，这会增加开销并延长请求响应时间。

乐观锁：一种性能优化策略

乐观锁提供了一种替代方案，它可以在不获取锁的情况下访问共享资源。相反，它假设没有其他请求会同时修改资源。只有当请求尝试更新资源时，它才会检查是否有其他请求已经修改了资源。

如何选择合适的锁机制

在选择锁机制时，需要考虑以下因素：

并发量： 如果并发量低，乐观锁就足够了。对于高并发场景，则需要悲观锁。
数据一致性要求： 对于需要严格数据一致性的场景，悲观锁是必需的。对于不那么关键的一致性要求，可以使用乐观锁。
性能要求： 如果性能至关重要，可以使用乐观锁。对于不太注重性能的场景，可以使用悲观锁。

实战案例：电商系统中的乐观锁

一家电商公司在实施分布式锁后，遇到了商品超卖的问题。分析后发现，分布式锁的悲观性质导致了性能下降和死锁。因此，他们决定改用乐观锁，并取得了显著的性能提升，同时解决了商品超卖问题。

代码示例：使用乐观锁库

可以使用乐观锁库，例如乐观锁，它可以自动实现乐观锁逻辑：

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Service;
import org.springframework.transaction.annotation.Transactional;

import javax.persistence.LockModeType;

@Service
public class OrderService {

    @Autowired
    private ProductRepository productRepository;

    @Transactional(lockMode = LockModeType.OPTIMISTIC)
    public void placeOrder(Order order) {
        Product product = productRepository.findById(order.getProductId()).orElseThrow();
        if (product.getQuantity() < order.getQuantity()) {
            throw new RuntimeException("Insufficient product quantity");
        }
        product.setQuantity(product.getQuantity() - order.getQuantity());
        productRepository.save(product);
    }
}