首先要知道,分布式锁需要具备哪些条件:
- 获取锁和释放锁的性能要好
- 判断是否获得锁必须是原子性的,否则可能导致多个请求都获取到锁
- 具备锁失效机制,网络中断或宕机无法释放锁时,锁必须被清除,不然会发生死锁
- 可重入一个线程中可以多次获取同一把锁,比如一个线程在执行一个带锁的方法,该方法中又调用了另一个需要相同锁的方法,则该线程可以直接执行调用的方法,而无需重新获得锁;
- 阻塞锁和非阻塞锁,阻塞锁即没有获取到锁,则继续等待获取锁;非阻塞锁即没有获取到锁后,不继续等待,直接返回锁失败。
实现分布式锁的三种实现方式:
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锁。
- 缺点:性能比不上缓存锁,因为要频繁的创建节点删除节点。