@adamhand 2019-02-27T12:03:12.000000Z 字数 4155 阅读 852

分布式锁

什么是分布式锁

在单节点情况下，如果多个线程同时访问共享变量时，为了保证线程安全，需要对共享变量加锁。比如Java语言中的synchronized关键字和Lock锁。这样就解决了多线程并发问题。

在集群模式情况下，可能两个线程不再属于同一台机器上的同一个进程，线程同步上升到进程同步，这样synchronized和Lock就不起作用了。为了对共享变量进行保护，防止多个进程同时操作共享变量，这样是为了解决多进程的并发问题。类似于单节点的锁，这种保护方式被称为分布式锁。

分布式锁和分布式事务是两个不同的概念，它们解决的是两个问题。举个例子，一个商品的买卖过程中有两个这样的操作：

添加商品到购物车，购物车中的商品数+1
修改商品库存，将库存中的商品数-1

此时购物车的数据和库存的数据被存放在两个数据库中。

分布式锁解决的是这样的问题：多个进程同时修改购物车中商品的数量，只有一个进程能够成功，最后的结果是购物车中商品数量+1，不能多也不能少。

分布式事务解决的是这样的问题：购物车中商品数量和库存中商品数量联动改变，不能一个变了一个没变。

分布式锁的实现方式

常见的分布式锁有三种实现方式：

基于数据库(MySQL)的分布式锁
基于缓存(redis , memcached)的分布式锁
基于zookeeper的分布式锁

基于数据库的分布式锁

基于数据库实现分布式锁，可以有两种做法：

基于数据库的悲观锁
基于数据库的乐观锁

而实现悲观锁也有两种方法：使用数据库唯一索引的特性，使用数据库的排他表锁。

需要注意的是，基于数据库的锁并不是为了保证数据库访问的安全，而是为了利用数据库中的某些特性保证不同进程的安全。啥意思呢？比如MySQL数据库中有X锁和S锁，同时具有三级封锁协议和四种隔离界别，这些特性基本就能保证MySQL的安全。现在要做的是，A和B两个进程需要对一个共享的变量x进行修改，为了保证同一时刻只能有一个进程对x进行修改，就需要一把锁，竞争到锁的进程可以修改。而如何做这把锁呢？就可以利用MySQL的一些特性比如索引的唯一性来做这把锁，保证了锁的唯一性。

基于数据库的唯一索引特性

做法是这样的：获得锁时向表中插入一条记录，释放锁时删除这条记录。唯一索引可以保证同一条记录只被插入一次，那么就可以用这个记录是否存在来判断是否存于锁定状态。

例如，看下面这张表：

CREATE TABLE `methodLock` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的方法名',
  `desc` varchar(1024) NOT NULL DEFAULT '备注信息',
  `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '保存数据时间，自动生成',
  PRIMARY KEY (`id`),
  UNIQUE KEY `uidx_method_name` (`method_name `) USING BTREE
)
ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的方法';

上面的表中，通过UNIQUE KEY将method_name设置为唯一索引，那么在method_name这个索引上，同一条记录只能进行一次插入操作，它就相当于一把唯一的锁。

当要锁住某个方法时，可以在方法中执行以下SQL：

insert into methodLock(method_name,desc) values (‘method_name’,‘desc’)

其他方法检测到method_name字段不为空，说明处于加锁状态。当方法执行完毕之后，想要释放锁的话，需要执行以下sql：

 delete from methodLock where method_name ='method_name'

这种方法存在几个问题：

锁没有失效时间，解锁失败的话其它进程无法再获得该锁。
只能是非阻塞锁，插入失败直接就报错了，无法重试。
不可重入，已经获得锁的进程也必须重新获取锁。

基于数据库的表锁

还可以借助数据库中自带的锁来实现分布式锁。还是利用上面创建的数据库表，基于MySQL的InnoDB引擎，可以使用以下方法来实现加锁操作：

public boolean lock(){
    Connection.setAutoCommit(false);
    while (true) {
          try {
                result = select * from MethodLock where methodName = 'xxxx' for update;
                if (result != null) {
                      return true; //表示获取到锁，返回true
                }
          } catch (Exception e) {
          }
          //没有获得锁，继续获取
          sleep(1000);
    }
    return false;
}

在查询语句后面增加for update，数据库会在查询过程中给数据库表增加排他锁。

通过以下方法解锁：

public void unlock(){
    connection.commit();
}

这种方法在加锁失败时也不会报错，但是还是不可重入锁。

基于数据库版本号实现乐观锁

乐观锁机制其实就是在数据库表中引入一个版本号（version）字段来实现的。

当要从数据库中读取数据的时候，同时把这个version字段也读出来，如果要对读出来的数据进行更新后写回数据库，则需要将version加1，同时将新的数据与新的version更新到数据表中。但是必须必须在更新之前检查目前数据库里version值是不是之前的那个version，如果是，则正常更新。如果不是，则更新失败，说明在这个过程中有其它的进程去更新过数据了。有点类似于CAS算法。

基于缓存的分布式锁

主要介绍几种基于redis实现的分布式锁。

另外，Redisson 是一个基于Redis的分布式锁框架，可以直接用。Maven依赖如下：

<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson</artifactId>
    <version>3.9.0</version>
</dependency>

基于SETNX 指令

使用 SETNX（set if not exist）指令插入一个键值对，如果 Key 已经存在，那么会返回 False，否则插入成功并返回 True。

SETNX 指令和数据库的唯一索引类似，保证了只存在一个 Key 的键值对，那么可以用一个 Key 的键值对是否存在来判断是否存于锁定状态。

EXPIRE 指令可以为一个键值对设置一个过期时间，从而避免了数据库唯一索引实现方式中释放锁失败的问题。

基于RedLock 算法

使用了多个 Redis 实例来实现分布式锁，这是为了保证在发生单点故障时仍然可用。

尝试从 N 个相互独立 Redis 实例获取锁；
计算获取锁消耗的时间，只有当这个时间小于锁的过期时间，并且从大多数（N / 2 + 1）实例上获取了锁，那么就认为锁获取成功了；
如果锁获取失败，就到每个实例上释放锁。

基于zookeeper的分布式锁

使用zookeeper的分布式锁最简单的方法是使用curator开源项目提供的基于zookeeper实现的分布式锁。

Maven依赖如下：

<dependency>
    <groupId>org.apache.curator</groupId>
    <artifactId>curator-recipes</artifactId>
    <version>4.0.0</version>
</dependency>

Zookeeper 抽象模型

Zookeeper 提供了一种树形结构级的命名空间，/app1/p_1 节点的父节点为 /app1。

节点类型

永久节点：不会因为会话结束或者超时而消失；
临时节点：如果会话结束或者超时就会消失；
有序节点：会在节点名的后面加一个数字后缀，并且是有序的，例如生成的有序节点为 /lock/node-0000000000，它的下一个有序节点则为 /lock/node-0000000001，以此类推。

监听器

为一个节点注册监听器，在节点状态发生改变时，会给监听者发送消息。

分布式锁实现

创建一个锁目录 /lock；
当一个客户端需要获取锁时，在 /lock 下创建临时的且有序的子节点；
客户端获取 /lock 下的子节点列表，判断自己创建的子节点是否为当前子节点列表中序号最小的子节点，如果是则认为获得锁；否则监听自己的前一个子节点(比自己次小的节点，只监听一个节点是为了避免“羊群效应”)，获得子节点的变更通知后重复此步骤直至获得锁；
执行业务代码，完成后，删除对应的子节点。

会话超时

如果一个已经获得锁的会话超时了，因为创建的是临时节点，所以该会话对应的临时节点会被删除，其它会话就可以获得锁了。可以看到，Zookeeper 分布式锁不会出现数据库的唯一索引实现的分布式锁释放锁失败问题。

羊群效应

一个节点未获得锁，只需要监听自己的前一个子节点，这是因为如果监听所有的子节点，那么任意一个子节点状态改变，其它所有子节点都会收到通知（羊群效应），而我们只希望它的后一个子节点收到通知。

小结

几种分布式锁的优缺点：

数据库锁：

优点：直接使用数据库，使用简单。
缺点：分布式系统大多数瓶颈都在数据库，使用数据库锁会增加数据库负担。

缓存锁：

优点：性能高，实现起来较为方便，在允许偶发的锁失效情况，不影响系统正常使用，建议采用缓存锁。
缺点：通过锁超时机制不是十分可靠，当线程获得锁后，处理时间过长导致锁超时，就失效了锁的作用。

zookeeper锁：

优点：不依靠超时时间释放锁；可靠性高；系统要求高可靠性时，建议采用zookeeper锁。
缺点：性能比不上缓存锁，因为要频繁的创建节点删除节点。

参考

分布式锁、事务和分布式事务概念汇总
 浅谈分布式锁
 还有人不懂分布式锁的实现就把这篇文章丢给他
 基于Zookeeper的分布式锁
 为什么分布式要有分布式锁！
再有人问你分布式锁是什么，就把这篇文章发给他
 分布式锁的几种实现方式
 基于数据库的分布式锁实现
 分布式锁方式（一、基于数据库的分布式锁）
分布式锁1 Java常用技术方案