面试宝典系列-怎么实现分布式锁

为什么80%的码农都做不了架构师？>>>   

首先要知道，分布式锁需要具备哪些条件：

1. 获取锁和释放锁的性能要好
2. 判断是否获得锁必须是原子性的，否则可能导致多个请求都获取到锁
3. 具备锁失效机制，网络中断或宕机无法释放锁时，锁必须被清除，不然会发生死锁
4. 可重入一个线程中可以多次获取同一把锁，比如一个线程在执行一个带锁的方法，该方法中又调用了另一个需要相同锁的方法，则该线程可以直接执行调用的方法，而无需重新获得锁；
5. 阻塞锁和非阻塞锁，阻塞锁即没有获取到锁，则继续等待获取锁；非阻塞锁即没有获取到锁后，不继续等待，直接返回锁失败。

实现分布式锁的三种实现方式：
    1、基于数据库

• 基于MySQL锁表

该实现方式完全依靠数据库唯一索引来实现，当想要获得锁时，即向数据库中插入一条记录，释放锁时就删除这条记录。
存在以下几个问题：
(1) 锁没有失效时间，解锁失败会导致死锁，其他线程无法再获取到锁，因为唯一索引insert都会返回失败。
(2) 只能是非阻塞锁，insert失败直接就报错了，无法进入队列进行重试
(3) 不可重入，同一线程在没有释放锁之前无法再获取到锁
(4) 这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。

• 采用乐观锁增加版本号

根据版本号来判断更新之前有没有其他线程更新过，如果被更新过，则获取锁失败。

2、缓存锁

• redis的setnx()、expire()方法

设置过期时间防止死锁，但是如果在setnx和expire之间宕机了，还是会造成死锁

• redis的setnx()、get()、getset()方法

a、setnx时value=过期时间，
b、如果setnx失败，则get，获取oldExpireTime，
c、如果oldExpireTime小于当前时间currentExpireTime，则认为锁失效，使用getset重新设置，
d、getset返回的时间如果和oldExpireTime时间相同，则说明成功获取锁，如果不同，则说明又被其他请求获取了。
e、当业务处理完毕后，比较自己的处理时间和对于锁设置的超时时间，如果小于锁设置的超时时间，则直接执行delete释放锁；如果大于锁设置的超时时间，则不需要再锁进行处理
存在的问题：设置超时时间要大于自己业务执行的时间，不然会有两个请求同时拥有锁。

• memcache的add()方法

add会添加第一个到达的值，并返回true，后续的添加则都会返回false。

3、Zookeeper分布式锁

• 首先了解下什么是ZooKeeper

ZooKeeper是一个为分布式应用提供一致性服务的软件，它内部是一个分层的文件系统目录树结构，规定统一个目录下只能有一个唯一文件名。

• 数据模型：

永久节点：节点创建后，不会因为会话失效而消失
临时节点：与永久节点相反，如果客户端连接失效，则立即删除节点
顺序节点：与上述两个节点特性类似，如果指定创建这类节点时，zk会自动在节点名后加一个数字后缀，并且是有序的。

• 监视器（watcher）：

当创建一个节点时，可以注册一个该节点的监视器，当节点状态发生改变时，watch被触发时，ZooKeeper将会向客户端发送且仅发送一条通知，因为watch只能被触发一次。

• 根据ZooKeeper的这些特性，我们来看看如何利用这些特性来实现分布式锁：

a、创建一个锁目录lock
b、希望获得锁的线程A就在lock目录下，创建临时顺序节点
c、获取锁目录下所有的子节点，然后获取比自己小的兄弟节点，如果不存在，则说明当前线程顺序号最小，获得锁
d、线程B获取所有节点，判断自己不是最小节点，设置监听(watcher)比自己次小的节点（只关注比自己次小的节点是为了防止发生“羊群效应”）
e、线程A处理完，删除自己的节点，线程B监听到变更事件，判断自己是最小的节点，获得锁。

三种实现方式的对比：

数据库锁：

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

缓存锁：

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

zookeeper锁：

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

转载于:https://my.oschina.net/suyain/blog/1859634