章
目
录
在分布式系统和高并发编程的面试中，“高并发下一定适合用乐观锁吗”是个常见的问题。不少同学对乐观锁的认知可能存在一些误区，认为它能完美解决高并发问题。今天咱们就深入探讨一下这个话题，帮大家在面试和实际开发中做出正确判断。
一、乐观锁在高并发场景下的“陷阱”
很多人觉得乐观锁在高并发场景下优势明显。就拿扣减库存来说，使用乐观锁时，操作会带上版本号。读取库存时获取一个版本号，更新库存时，只有版本号和读取时一致才会执行更新操作，不一致就不更新。这和悲观锁不同，悲观锁一上来就用for update把资源锁住，只有等数据库事务提交后，其他线程才能操作，还容易引发死锁。所以乍一看，乐观锁似乎不存在锁竞争，没有那么多冲突，非常适合高并发场景。但实际情况并非如此简单。
（一）前端重试导致接口压力剧增
在高并发场景下，同一时刻会有大量线程读取资源。由于乐观锁的机制，同一时刻只有一个线程能成功更新，其他线程都会因为版本号不一致而更新失败。一旦更新失败，前端通常会有重试机制，会不断地去获取资源，这就大大增加了查询接口的压力。比如在电商大促时，大量用户同时抢购商品，如果使用乐观锁扣减库存，可能会导致抢购失败的用户频繁重试，给服务器带来巨大压力。
（二）数据库层面的锁竞争问题
从数据库的角度来看，乐观锁也并非毫无问题。在执行update更新语句时，即使没有手动开启事务、使用for update，数据库默认也会使用行锁来锁住资源，只是这个过程很快，我们可能没有感知到。在高并发的扣减库存场景中，如果大量update操作同时涌入，它们就会不停地争抢行锁。随着操作量的增加，数据库的锁竞争会越来越激烈，这会导致整体效率下降，出现性能问题。
二、高并发下扣减库存的优化方案
既然乐观锁在高并发且涉及批量更新（如扣减库存）的场景下并不适用，那该怎么办呢？一般来说，我们建议使用Redis来做库存的预扣减。Redis具有高性能、高可用等特性，利用它来处理库存扣减非常方便。在实际操作中，我们可以先在Redis中进行库存的预扣减，然后定期将Redis中的库存数据和数据库进行同步。这样既能利用Redis的高性能应对高并发，又能保证数据的最终一致性。
三、乐观锁的适用场景
乐观锁并非一无是处，它在特定场景下还是非常适用的。比如在一些读多写少的场景中，虽然存在资源竞争，但竞争并不激烈，这种情况下使用乐观锁就再合适不过了。在这些场景里，大部分操作是读取数据，偶尔的写入操作即使因为版本号不一致更新失败，也不会对系统性能造成太大影响，而且还能避免悲观锁带来的锁竞争和阻塞问题。
在高并发场景下，不能盲目地使用乐观锁。我们需要根据具体的业务场景和需求，综合考虑各种因素，选择最合适的解决方案。如果大家在这方面有什么疑问或者经验，欢迎在评论区留言讨论，咱们一起进步！
