分布式锁-三种实现方式简述

Posted 2021-09-05 、Dong

文章目录

• 前言
• 一、基于数据库实现分布式锁
• • 1.悲观锁
  • 2.乐观锁
• 二、基于缓存（Redis等）实现分布式锁
• 三、基于Zookeeper实现分布式锁
• 四、三种实现对比
• • 1.三种实现应用场景
  • 2.综合分析
• 结尾

---

前言

目前几乎很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。”所以，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证“最终一致性”，只要这个最终时间是在用户可以接受的范围内即可。
在很多场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。有的时候，我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中，Java中其实提供了很多并发处理相关的API，但是这些API在分布式场景中就无能为力了。也就是说单纯的Java Api并不能提供分布式锁的能力。所以针对分布式锁的实现目前有多种方案。

分布式锁有三种实现方式：

• 基于数据库实现分布式锁
• 基于缓存（Redis等）实现分布式锁
• 基于Zookeeper实现分布式锁

---

一、基于数据库实现分布式锁

1.悲观锁

利用select … where … for update 排他锁
注意: 其他附加功能与实现一基本一致，这里需要注意的是“where name=lock ”，name字段必须要走索引，否则会锁表。有些情况下，比如表不大，mysql优化器会不走这个索引，导致锁表问题。

2.乐观锁

所谓乐观锁与前边最大区别在于基于CAS思想，是不具有互斥性，不会产生锁等待而消耗资源，操作过程中认为不存在并发冲突，只有update version失败后才能觉察到。我们的抢购、秒杀就是用了这种实现以防止超卖。通过增加递增的版本号字段实现乐观锁

---

二、基于缓存（Redis等）实现分布式锁

相比较于基于数据库实现分布式锁的方案来说，基于缓存来实现在性能方面会表现的更好一点。而且很多缓存是可以集群部署的，可以解决单点问题。
目前有很多成熟的缓存产品，包括Redis，memcached等
流程如下，redis较为流行且分布式锁实现方式较多，单独写一篇文章讲解

---

三、基于Zookeeper实现分布式锁

zookeeper实现分布式锁的原理就是多个节点同时在一个指定的节点下面创建临时会话顺序节点，谁创建的节点序号最小，谁就获得了锁，并且其他节点就会监听序号比自己小的节点，一旦序号比自己小的节点被删除了，其他节点就会得到相应的事件，然后查看自己是否为序号最小的节点，如果是，则获取锁。流程如下：

---

四、三种实现对比

上面几种方式，哪种方式都无法做到完美。就像CAP一样，在复杂性、可靠性、性能等方面无法同时满足，所以，根据不同的应用场景选择最适合自己的才是王道。

1.三种实现应用场景

• 数据库分布式锁由于数据库本身的限制：性能不高且不满足高可用（即是存在备份，也会导致数据不一致），因此，工作中很难见到真正使用数据库来作为分布式锁的解决方案，这里使用数据库实现主要是为了理解分布式锁的实现原理。

• redis分布式锁（非redlock）由于redis自身的高性能原因，会有很好的性能，但是极端情况下会存在两个客户端获取锁（可以通过监控leader故障和运维措施来缓解和解决该问题），因此适用于高并发的场景。

• zookeeper分布式锁实现简单，zookeeper集群自己来保证数据一致性，但是会存在建立无用节点且多节点之间需要同步数据的问题，因此一般适合于并发量小的场景使用，例如定时任务的运行等。

2.综合分析

• 从理解的难易程度角度（从低到高）
  数据库 > 缓存 > Zookeeper

• 从实现的复杂性角度（从低到高）
  Zookeeper >= 缓存 > 数据库

• 从性能角度（从高到低）
  缓存 > Zookeeper >= 数据库

• 从可靠性角度（从高到低）
  Zookeeper > 缓存 > 数据库

---

结尾

• 感谢大家的耐心阅读，如有建议请私信或评论留言。
• 如有收获，劳烦支持，关注、点赞、评论、收藏均可，博主会经常更新，与大家共同进步