分布式锁的多种实现方式 - ZhaoHongnan/multiple-implementations-of-distributed-lock GitHub Wiki

任何问题欢迎联系[email protected]

一、分布式锁介绍

何为分布式？在单机程序中，如果多条线程同时执行访问同一资源，这个资源被成为共享资源，如果它的状态会被每一条线程改变，那么每条线程就可能读取到一个已被其他线程改变的共享变量的状态从而导致获取共享变量的状态是失效的，在执行操作就会发生不可预知的结果。因此在多线程操作下我们需要对可变的共享资源进行加锁处理，这就是程序中的锁。分布式程序是相对于单机而言由多台服务器公共提供服务的程序，换言之程序部署在多台机器上，服务器间程序访问可变资源仍然需要有锁来控制，此时本地锁不会起到作用，需要利用其他辅助程序建立锁协助分布式程序加锁。在分布式程序中的锁就是分布式锁。本文将介绍三种常用到的分布式锁实现，zookeeper，redis和mysql实现。

二、zookeeper

zookeeper介绍

zookeeper是apache开源的分布式服务。利用类似于标准文件系统的层级命名空间（namespace）协调分布式程序，每个命名空间成为znode节点。znode节点与文件和文件夹相似。zookeeper为了实现高吞吐和低延迟将数据驻留于内存中，并且server端保证具有相同的内存视图。client端通过TCP与zookeeper集群通信，集群只要多数节点存活则集群可用。zookeeper对于每一次节点的改变都会产生唯一的数字编号称为zxid标示这次事务。参考文档https://zookeeper.apache.org/

znode

znode节点按照存活时间分为持久（persistent）和临时（ephemeral），并且znode可以是顺序的也可以是非顺序的。具体说来，持久化znode一旦被创建就会一直存在，除非手动删除；临时znode会随着client连接zookeeper服务的session建立而创建，当session断开，znode会随之消失。顺序持久化znode指新创建的znode会根据已存在的znode节点编号自动递增，但不会随着session断开而消失，与之相对是临时顺序znode，不同之处会随之session断开而消失。

watch

watch是一次性的事件触发器，监听znode节点状态，一旦节点状态发生改变，服务端就会通知所有监听这个znode节点的客户端，继而客户端知道znode发生变化随之根据watch设置逻辑做出响应。

zookeeper分布式锁的几种实现

• 简单互斥锁 多个线程尝试在指定的目录下创建临时znode，只有一个线程会创建成功，占有锁，而其他线程设置watch监听这个临时znode。当占有锁的线程执行完成断开连接，临时znode消失，其他线程再一起尝试创建临时znode抢占锁，重复这个过程直到所有线程执行完成。
• 无惊群效应的互斥锁 上面实现的简单互斥锁在程序量级很小的情况，实现简单好用。然后当程序量级增加，大量线程同时监听一个znode，每次释放锁时，所有线程都被唤醒去抢占锁，极大损耗网络资源和集群性能，这种现象称为惊群现象。为了解决惊群现象，线程不在创建相同的临时znode，而是每个线程都创建一个顺序临时节点，znode序号最小线程的获得锁，其他线程只监听比它znode次序小的znode。这样分布式锁就会依据线程创建znode节点的次序依次被占有。
• 自定义拓展的实现方式 在实际生产中会有许多根据需求而产生的特定加锁要求，例如对用户id加锁进行操作，同样可以利用上面介绍的两种方式实现，但这里存在一个问题就是如果用户数量很大将会产生大量的目录结构，每个用户一个目录结构，而有些用户可能操作一次之后就很久不再操作，这样就会导致zookeeper集群内存的浪费。这时可以结合使用临时znode和持久znode，手动定义判断是否有线程占有锁的逻辑，删除不必要的znode节点。或者在zookeeper3以上定义了container节点类型，container节点如果其下面的最后一个孩子节点已经被删除，那么它也将被系统在未来某个时刻删除，使用container是要注意在其中创建子节点时可能存在KeeperException.NoNodeException无节点异常。

三、redis

redis简介

redis是基于内存的键值对数据库。多数情况下，我们都使用其作为程序的分布式缓存，因为所有数据都存储在内存中，吞吐量很大。使用好redis是程序员必备的一项技能，因为大多数人对于redis较为属性，这里不再多言，直接进入redis分布式锁的实现。

redis分布式锁的实现

其实因为redis内存使用常用数据结构储存数据，对于我们而言比较好理解，redis API接口丰富，在实现分布式锁的过程也相对简单些，使用**NX操作即可。例如SETNX操作，SETNX key value，将key的值设为value，当且仅当key不存在。若给定的key已经存在，则SETNX不做任何动作。SETNX『SET if Not eXists』(如果不存在，则 SET)的简写。利用一个固定的key值作为锁，多个分布式程序同时执行SETNX操作，只有一个线程可以成功，而其他失败，成功者获得锁，其他线程可以等待继续尝试执行SETNX直到获取锁。如今redis分布式锁实现有很多已经实现的开源工具，推荐使用Redisson，参考文档https://github.com/redisson/redisson/wiki

四、mysql

关于mysql就不介绍了，直接说如何使用mysql实现分布式锁，关键是利用UNIQUE KEY，多个线程获取锁时向mysql数据库中插入一条记录，其中UNIQUE KEY都相同，如此就仅仅只能有一条线程可以成功插入，而其他线程会弹出异常表示唯一键已经存在，获取锁失败。其实与上文介绍的redis原理一致，只是mysql实现分布式锁相对比较笨拙，在可以使用其他方式的前提下不推荐使用mysql实现分布式锁。但是如果系统锁的请求量级很小，可以使用mysql实现分布式锁减少程序的外部依赖复杂度。