数据库乐观锁和悲观锁、redis分布式锁使用场景

前言

最近发现我们同事，但凡需要加锁的地方都用的是分布式锁。而且我们的后台系统，并没有什么并发量，而且还是单体应用。我真的有点怀疑我的同事不太清楚数据乐观锁、悲观锁和redis分布式的使用场景。

请今天就说一下各种锁的应用场景吧。

乐观锁和悲观锁、redis分布式锁

悲观锁

悲观锁假设最坏的情况，即在数据处理过程中，总是假设会发生冲突，因此在数据处理之前先加锁。这种锁通常由数据库自身提供支持，如MySQL的SELECT FOR UPDATE。

使用场景：

● 当数据竞争较多，冲突频繁发生时。
● 更新和删除操作多的应用场景。

在高并发场景中，一般来说并发写入的冲突较为频繁，所以建议优先考虑悲观锁。即在做并发操作前，先尝试获取锁，如果获取锁成功，在进行业务操作，否则就直接返回失败。如果用乐观锁，不仅仅有大量执行失败的数据，这部分数据还占用大量的服务器资源（因为前置的数据校验、计算、查询等操作都做完了，最后却失败了）。

乐观锁

乐观锁采用一种宽松的加锁机制，它假设多个事务在大多数时间不会同时修改同一数据。通常是通过版本号或时间戳来实现。每次数据更新过程中，检查版本号或时间戳是否发生变化，如果没有变化，则进行更新；如果已经变化，则放弃更新或重试。

主要使用场景是：

● 当数据竞争较少，冲突不频繁时，乐观锁能减少锁的开销，提高系统的整体性能。
● 适用于读多写少的应用场景。

Redis分布式锁

分布式锁是为了控制分布式系统中多个进程间的执行顺序，用于保护跨多个系统的共享资源。数据库的锁，也是分布式锁的实现方式的一种。因为Redis有更好的性能，并且一般服务器的性能瓶颈在数据库，所以用Redis来做分布式锁性能好的同时也能帮数据库分担压力。

分布式锁的主要使用场景：

● 在多个应用或服务需要共同访问同一资源时使用，如在微服务架构中保护共享资源。
● 适用于处理跨多个节点的业务流程，保证数据的一致性和系统的稳定性。
也就是说，用数据库悲观锁的地方，都可以用Redis分布式锁。当然Redis也支持乐观锁。但是一般用的比较少而已。

什么时候用数据库的悲观锁，什么时候用Redis的分布式锁呢？

数据库悲观锁

1. 如果是单体应用（且并发低），在做数据库操作的时候，建议直接基于数据库的悲观锁来做并发控制。如果是分布式应用，二者都可以。
2. 并发不高的情况，如果不想额外引入Redis，也可以直接基于数据库做悲观锁控制。

redis分布式锁

当然在分布式系统中，由于业务没啥并发，也是可以数据的悲观锁，来加锁的。

在分布式系统中，做并发控制的时候，建议用Redis的分布式锁，而不是数据库的悲观锁（分布式锁）。主要有几个原因：

1. Redis更快，性能更好，可以有更快的响应。
2. Redis实现的分布式锁功能更多，比如可重入，续期等等，这些都是数据库的悲观锁不支持的。
3. 数据库悲观锁可能会锁表，影响整体性能。
4. 数据库的链接资源要比Redis更加珍贵，建议把这些非业务逻辑操作放到Redis中去抗，而不是用数据库抗。

总结

简单的介绍了乐观锁和悲观，以及基于redis实现分布式锁，对应的应用场景。让我们在实际开发中能够合理的去选择锁方案。

希望这篇文章对你有用，感谢佬们点赞收藏，谢谢！！！

ps: 买服务器返点；收徒中；面试全集在线文档,需要请私信。