探讨一下分布式锁的设计与实现
1. 分布式锁概述
我们的系统都是分布式部署的，日常开发中，秒杀下单、抢购商品 等等业务场景，为了防⽌库存超卖，都需要用到分布式锁 。
分布式锁其实就是，控制分布式系统不同进程共同访问共享资源的一种锁的实现。如果不同的系统或同一个系统的不同主机之间共享了某个临界资源，往往需要互斥来防止彼此干扰，以保证一致性。
业界流行的分布式锁实现，一般有这3种方式：
基于数据库实现的分布式锁
基于redis实现的分布式锁
基于zookeeper实现的分布式锁
基于微服务的思想，构建在 b2c 电商场景下的项目实战。核心技术栈，是 spring boot + dubbo 。未来，会重构成 spring cloud alibaba 。
项目地址：https://github.com/yunaiv/onemall
2. 基于数据库的分布式锁
2.1 数据库悲观锁实现的分布式锁
可以使用select ... for update 来实现分布式锁。我们自己的项目，分布式定时任务 ，就使用类似的实现方案，我给大家来展示个简单版的哈
表结构如下：
create table `t_resource_lock` ( `key_resource` varchar(45) collate utf8_bin not null default '资源主键', `status` char(1) collate utf8_bin not null default '' comment 's,f,p', `lock_flag` int(10) unsigned not null default '0' comment '1是已经锁 0是未锁', `begin_time` datetime default null comment '开始时间', `end_time` datetime default null comment '结束时间', `client_ip` varchar(45) collate utf8_bin not null default '抢到锁的ip', `time` int(10) unsigned not null default '60' comment '方法生命周期内只允许一个结点获取一次锁，单位：分钟', primary key (`key_resource`) using btree) engine=innodb default charset=utf8 collate=utf8_bin
加锁lock方法的伪代码如下：
@transcational //一定要加事务public boolean lock(string keyresource，int time){ resourcelock = 'select * from t_resource_lock where key_resource ='#{keysource}' for update'; try{ if(resourcelock==null){ //插入锁的数据 resourcelock = new resourcelock(); resourcelock.settime(time); resourcelock.setlockflag(1); //上锁 resourcelock.setstatus(p); //处理中 resourcelock.setbegintime(new date()); int count = insert into resourcelock; if(count==1){ //获取锁成功 return true; } return false; } }catch(exception x){ return false; } //没上锁并且锁已经超时，即可以获取锁成功 if(resourcelock.getlockflag=='0'&&'s'.equals(resourcelock.getstatus) && new date()>=resourcelock.adddatetime(resourcelock.getbegintime(,time)){ resourcelock.setlockflag(1); //上锁 resourcelock.setstatus(p); //处理中 resourcelock.setbegintime(new date()); //update resourcelock; return true; }else if(new date()>=resourcelock.adddatetime(resourcelock.getbegintime(,time)){ //超时未正常执行结束,获取锁失败 return false; }else{ return false; } }
解锁unlock方法的伪代码如下：
public void unlock(string v，status){ resourcelock.setlockflag(0); //解锁 resourcelock.setstatus(status); s:表示成功，f表示失败 //update resourcelock; return ;}
整体流程：
try{if(lock(keyresource,time)){ //加锁 status = process();//你的业务逻辑处理。 }} finally{ unlock(keyresource,status); //释放锁}
其实这个悲观锁实现的分布式锁，整体的流程还是比较清晰的。就是先select ... for update 锁住主键key_resource那个记录，如果为空，则可以插入一条记录，如果已有记录判断下状态和时间 ，是否已经超时 。这里需要注意一下哈，必须要加事务 哈。
2.2 数据库乐观锁实现的分布式锁
除了悲观锁，还可以用乐观锁实现分布式锁 。乐观锁，顾名思义，就是很乐观，每次更新操作，都觉得不会存在并发冲突，只有更新失败后，才重试。它是基于cas思想实现的。我以前的公司，扣减余额 就是用这种方案。
搞个version字段，每次更新修改，都会自增加一，然后去更新余额时，把查出来的那个版本号，带上条件去更新，如果是上次那个版本号，就更新，如果不是，表示别人并发修改过了，就继续重试。
大概流程如下：
查询版本号和余额
select version,balance from account where user_id ='666';
假设查到版本号是oldversion=1.
逻辑处理，判断余额
if(balance= #{left_balance} and user_id ='666';
大家可以看下这个流程图哈：
这种方式适合并发不高 的场景，一般需要设置一下重试的次数
3.基于redis实现的分布式锁
redis分布式锁一般有以下这几种实现方式：
setnx + expire
setnx + value值是过期时间
set的扩展命令（set ex px nx）
set ex px nx + 校验唯一随机值,再删除
redisson
redisson + redlock
3.1 setnx + expire
聊到redis分布式锁，很多小伙伴反手就是setnx + expire，如下：
if（jedis.setnx(key,lock_value) == 1）{ //setnx加锁 expire（key，100）; //设置过期时间 try { do something //业务处理 }catch(){ } finally { jedis.del(key); //释放锁 }}
这段代码是可以加锁成功，但是你有没有发现问题，加锁操作和设置超时时间是分开的 。假设在执行完setnx加锁后，正要执行expire设置过期时间时，进程crash掉或者要重启维护了，那这个锁就长生不老 了，别的线程永远获取不到锁啦，所以分布式锁不能这么实现 ！
3.2 setnx + value值是过期时间
long expires = system.currenttimemillis() + expiretime; //系统时间+设置的过期时间string expiresstr = string.valueof(expires);// 如果当前锁不存在，返回加锁成功if (jedis.setnx(key, expiresstr) == 1) { return true;} // 如果锁已经存在，获取锁的过期时间string currentvaluestr = jedis.get(key);// 如果获取到的过期时间，小于系统当前时间，表示已经过期if (currentvaluestr != null && long.parselong(currentvaluestr) 30ms+40ms+50ms+4m0s+50ms）
如果取到了锁，key的真正有效时间就变啦，需要减去获取锁所使用的时间。
如果获取锁失败（没有在至少n/2+1个master实例取到锁，有或者获取锁时间已经超过了有效时间），客户端要在所有的master节点上解锁（即便有些master节点根本就没有加锁成功，也需要解锁，以防止有些漏网之鱼）。
简化下步骤就是：
按顺序向5个master节点请求加锁
根据设置的超时时间来判断，是不是要跳过该master节点。
如果大于等于3个节点加锁成功，并且使用的时间小于锁的有效期，即可认定加锁成功啦。
如果获取锁失败，解锁！
redisson实现了redlock版本的锁 ，有兴趣的小伙伴，可以去了解一下哈~
4. zookeeper分布式锁
在学习zookeeper分布式锁之前，我们复习一下zookeeper的节点哈。
zookeeper的节点znode有四种类型：
持久节点 ：默认的节点类型。创建节点的客户端与zookeeper断开连接后，该节点依旧存在。
持久节点顺序节点 ：所谓顺序节点，就是在创建节点时，zookeeper根据创建的时间顺序给该节点名称进行编号，持久节点顺序节点就是有顺序的持久节点。
临时节点 ：和持久节点相反，当创建节点的客户端与zookeeper断开连接后，临时节点会被删除。
临时顺序节点 ：有顺序的临时节点。
zookeeper分布式锁实现应用了临时顺序节点 。这里不贴代码啦，来讲下zk分布式锁的实现原理吧。
4.1 zk获取锁过程
当第一个客户端请求过来时，zookeeper客户端会创建一个持久节点locks。如果它（client1）想获得锁，需要在locks节点下创建一个顺序节点lock1.如图
接着，客户端client1会查找locks下面的所有临时顺序子节点，判断自己的节点lock1是不是排序最小的那一个，如果是，则成功获得锁。
这时候如果又来一个客户端client2前来尝试获得锁，它会在locks下再创建一个临时节点lock2
客户端client2一样也会查找locks下面的所有临时顺序子节点，判断自己的节点lock2是不是最小的，此时，发现lock1才是最小的，于是获取锁失败。获取锁失败，它是不会甘心的，client2向它排序靠前的节点lock1注册watcher事件，用来监听lock1是否存在，也就是说client2抢锁失败进入等待状态。
此时，如果再来一个客户端client3来尝试获取锁，它会在locks下再创建一个临时节点lock3
同样的，client3一样也会查找locks下面的所有临时顺序子节点，判断自己的节点lock3是不是最小的，发现自己不是最小的，就获取锁失败。它也是不会甘心的，它会向在它前面的节点lock2注册watcher事件，以监听lock2节点是否存在。
4.2 释放锁
我们再来看看释放锁的流程，zookeeper的客户端业务完成或者发生故障，都会删除临时节点，释放锁。如果是任务完成，client1会显式调用删除lock1的指令
如果是客户端故障了，根据临时节点得特性，lock1是会自动删除的
lock1节点被删除后，client2可开心了，因为它一直监听着lock1。lock1节点删除，client2立刻收到通知，也会查找locks下面的所有临时顺序子节点，发下lock2是最小，就获得锁。
同理，client2获得锁之后，client3也对它虎视眈眈，啊哈哈~
zookeeper设计定位就是分布式协调，简单易用。如果获取不到锁，只需添加一个监听器即可，很适合做分布式锁。
zookeeper作为分布式锁也缺点：如果有很多的客户端频繁的申请加锁、释放锁，对于zookeeper集群的压力会比较大。
5. 三种分布式锁对比
5.1 数据库分布式锁实现
优点：
简单，使用方便，不需要引入redis、zookeeper等中间件。
缺点：
不适合高并发的场景
db操作性能较差；
5.2 redis分布式锁实现
优点：
性能好，适合高并发场景
较轻量级
有较好的框架支持，如redisson
缺点：
过期时间不好控制
需要考虑锁被别的线程误删场景
5.3 zookeeper分布式锁实现
缺点：
性能不如redis实现的分布式锁
比较重的分布式锁。
优点：
有较好的性能和可靠性
有封装较好的框架，如curator
5.4 对比汇总
从性能角度（从高到低）redis > zookeeper >= 数据库；
从理解的难易程度角度（从低到高）数据库 > redis > zookeeper；
从实现的复杂性角度（从低到高）zookeeper > redis > 数据库；
从可靠性角度（从高到低）zookeeper > redis > 数据库。
伯特利拟募集资金6.17亿元 各家上市公司年报
比克电池预计2020年开发出6Ah产品
蓝牙HI-FI车载DSP数字音频方案
首款模拟IC方案,解决产品三大阶段可靠性问题
贸泽备货Bosch BMM350磁力计 为3D、虚拟和增强现实、室内导航等领域提供支持
探讨一下分布式锁的设计与实现
华为开始进军6G，6G网速到底有多快？
DeepMind开源了一个内部强化学习库TRFL
选择性波峰焊介绍
诺基亚9什么时候上市？最新消息：诺基亚9工程机、跑分、配置曝光，超强旗舰来袭实力不容小觑！
基于TMS320F2812 DSP的交流永磁同步直线电机控制
360N7Lite评测 在同价位的千元机中几乎是没有对手的
长虹等家电厂商“拓路”智慧家庭 竞谋物联“蓝海”
华为Mate40 RS保时捷斩获2020年手机保值榜第一
AD20拼板步骤
虚拟现实火爆的背后 这7个问题需要解决
为何UWB定位方案能快速占领室内定位市场？
智能配电柜与普通配电柜
为什么单片机的I/O口需要驱动？
亚马逊携手 AWS 为企业提供混合云基础架构
我们的系统都是分布式部署的，日常开发中，秒杀下单、抢购商品 等等业务场景，为了防⽌库存超卖，都需要用到分布式锁 。
分布式锁其实就是，控制分布式系统不同进程共同访问共享资源的一种锁的实现。如果不同的系统或同一个系统的不同主机之间共享了某个临界资源，往往需要互斥来防止彼此干扰，以保证一致性。
业界流行的分布式锁实现，一般有这3种方式：
基于数据库实现的分布式锁
基于redis实现的分布式锁
基于zookeeper实现的分布式锁
基于微服务的思想，构建在 b2c 电商场景下的项目实战。核心技术栈，是 spring boot + dubbo 。未来，会重构成 spring cloud alibaba 。
项目地址：https://github.com/yunaiv/onemall
2. 基于数据库的分布式锁
2.1 数据库悲观锁实现的分布式锁
可以使用select ... for update 来实现分布式锁。我们自己的项目，分布式定时任务 ，就使用类似的实现方案，我给大家来展示个简单版的哈
表结构如下：
create table `t_resource_lock` ( `key_resource` varchar(45) collate utf8_bin not null default '资源主键', `status` char(1) collate utf8_bin not null default '' comment 's,f,p', `lock_flag` int(10) unsigned not null default '0' comment '1是已经锁 0是未锁', `begin_time` datetime default null comment '开始时间', `end_time` datetime default null comment '结束时间', `client_ip` varchar(45) collate utf8_bin not null default '抢到锁的ip', `time` int(10) unsigned not null default '60' comment '方法生命周期内只允许一个结点获取一次锁，单位：分钟', primary key (`key_resource`) using btree) engine=innodb default charset=utf8 collate=utf8_bin
加锁lock方法的伪代码如下：
@transcational //一定要加事务public boolean lock(string keyresource，int time){ resourcelock = 'select * from t_resource_lock where key_resource ='#{keysource}' for update'; try{ if(resourcelock==null){ //插入锁的数据 resourcelock = new resourcelock(); resourcelock.settime(time); resourcelock.setlockflag(1); //上锁 resourcelock.setstatus(p); //处理中 resourcelock.setbegintime(new date()); int count = insert into resourcelock; if(count==1){ //获取锁成功 return true; } return false; } }catch(exception x){ return false; } //没上锁并且锁已经超时，即可以获取锁成功 if(resourcelock.getlockflag=='0'&&'s'.equals(resourcelock.getstatus) && new date()>=resourcelock.adddatetime(resourcelock.getbegintime(,time)){ resourcelock.setlockflag(1); //上锁 resourcelock.setstatus(p); //处理中 resourcelock.setbegintime(new date()); //update resourcelock; return true; }else if(new date()>=resourcelock.adddatetime(resourcelock.getbegintime(,time)){ //超时未正常执行结束,获取锁失败 return false; }else{ return false; } }
解锁unlock方法的伪代码如下：
public void unlock(string v，status){ resourcelock.setlockflag(0); //解锁 resourcelock.setstatus(status); s:表示成功，f表示失败 //update resourcelock; return ;}
整体流程：
try{if(lock(keyresource,time)){ //加锁 status = process();//你的业务逻辑处理。 }} finally{ unlock(keyresource,status); //释放锁}
其实这个悲观锁实现的分布式锁，整体的流程还是比较清晰的。就是先select ... for update 锁住主键key_resource那个记录，如果为空，则可以插入一条记录，如果已有记录判断下状态和时间 ，是否已经超时 。这里需要注意一下哈，必须要加事务 哈。
2.2 数据库乐观锁实现的分布式锁
除了悲观锁，还可以用乐观锁实现分布式锁 。乐观锁，顾名思义，就是很乐观，每次更新操作，都觉得不会存在并发冲突，只有更新失败后，才重试。它是基于cas思想实现的。我以前的公司，扣减余额 就是用这种方案。
搞个version字段，每次更新修改，都会自增加一，然后去更新余额时，把查出来的那个版本号，带上条件去更新，如果是上次那个版本号，就更新，如果不是，表示别人并发修改过了，就继续重试。
大概流程如下：
查询版本号和余额
select version,balance from account where user_id ='666';
假设查到版本号是oldversion=1.
逻辑处理，判断余额
if(balance= #{left_balance} and user_id ='666';
大家可以看下这个流程图哈：
这种方式适合并发不高 的场景，一般需要设置一下重试的次数
3.基于redis实现的分布式锁
redis分布式锁一般有以下这几种实现方式：
setnx + expire
setnx + value值是过期时间
set的扩展命令（set ex px nx）
set ex px nx + 校验唯一随机值,再删除
redisson
redisson + redlock
3.1 setnx + expire
聊到redis分布式锁，很多小伙伴反手就是setnx + expire，如下：
if（jedis.setnx(key,lock_value) == 1）{ //setnx加锁 expire（key，100）; //设置过期时间 try { do something //业务处理 }catch(){ } finally { jedis.del(key); //释放锁 }}
这段代码是可以加锁成功，但是你有没有发现问题，加锁操作和设置超时时间是分开的 。假设在执行完setnx加锁后，正要执行expire设置过期时间时，进程crash掉或者要重启维护了，那这个锁就长生不老 了，别的线程永远获取不到锁啦，所以分布式锁不能这么实现 ！
3.2 setnx + value值是过期时间
long expires = system.currenttimemillis() + expiretime; //系统时间+设置的过期时间string expiresstr = string.valueof(expires);// 如果当前锁不存在，返回加锁成功if (jedis.setnx(key, expiresstr) == 1) { return true;} // 如果锁已经存在，获取锁的过期时间string currentvaluestr = jedis.get(key);// 如果获取到的过期时间，小于系统当前时间，表示已经过期if (currentvaluestr != null && long.parselong(currentvaluestr) 30ms+40ms+50ms+4m0s+50ms）
如果取到了锁，key的真正有效时间就变啦，需要减去获取锁所使用的时间。
如果获取锁失败（没有在至少n/2+1个master实例取到锁，有或者获取锁时间已经超过了有效时间），客户端要在所有的master节点上解锁（即便有些master节点根本就没有加锁成功，也需要解锁，以防止有些漏网之鱼）。
简化下步骤就是：
按顺序向5个master节点请求加锁
根据设置的超时时间来判断，是不是要跳过该master节点。
如果大于等于3个节点加锁成功，并且使用的时间小于锁的有效期，即可认定加锁成功啦。
如果获取锁失败，解锁！
redisson实现了redlock版本的锁 ，有兴趣的小伙伴，可以去了解一下哈~
4. zookeeper分布式锁
在学习zookeeper分布式锁之前，我们复习一下zookeeper的节点哈。
zookeeper的节点znode有四种类型：
持久节点 ：默认的节点类型。创建节点的客户端与zookeeper断开连接后，该节点依旧存在。
持久节点顺序节点 ：所谓顺序节点，就是在创建节点时，zookeeper根据创建的时间顺序给该节点名称进行编号，持久节点顺序节点就是有顺序的持久节点。
临时节点 ：和持久节点相反，当创建节点的客户端与zookeeper断开连接后，临时节点会被删除。
临时顺序节点 ：有顺序的临时节点。
zookeeper分布式锁实现应用了临时顺序节点 。这里不贴代码啦，来讲下zk分布式锁的实现原理吧。
4.1 zk获取锁过程
当第一个客户端请求过来时，zookeeper客户端会创建一个持久节点locks。如果它（client1）想获得锁，需要在locks节点下创建一个顺序节点lock1.如图
接着，客户端client1会查找locks下面的所有临时顺序子节点，判断自己的节点lock1是不是排序最小的那一个，如果是，则成功获得锁。
这时候如果又来一个客户端client2前来尝试获得锁，它会在locks下再创建一个临时节点lock2
客户端client2一样也会查找locks下面的所有临时顺序子节点，判断自己的节点lock2是不是最小的，此时，发现lock1才是最小的，于是获取锁失败。获取锁失败，它是不会甘心的，client2向它排序靠前的节点lock1注册watcher事件，用来监听lock1是否存在，也就是说client2抢锁失败进入等待状态。
此时，如果再来一个客户端client3来尝试获取锁，它会在locks下再创建一个临时节点lock3
同样的，client3一样也会查找locks下面的所有临时顺序子节点，判断自己的节点lock3是不是最小的，发现自己不是最小的，就获取锁失败。它也是不会甘心的，它会向在它前面的节点lock2注册watcher事件，以监听lock2节点是否存在。
4.2 释放锁
我们再来看看释放锁的流程，zookeeper的客户端业务完成或者发生故障，都会删除临时节点，释放锁。如果是任务完成，client1会显式调用删除lock1的指令
如果是客户端故障了，根据临时节点得特性，lock1是会自动删除的
lock1节点被删除后，client2可开心了，因为它一直监听着lock1。lock1节点删除，client2立刻收到通知，也会查找locks下面的所有临时顺序子节点，发下lock2是最小，就获得锁。
同理，client2获得锁之后，client3也对它虎视眈眈，啊哈哈~
zookeeper设计定位就是分布式协调，简单易用。如果获取不到锁，只需添加一个监听器即可，很适合做分布式锁。
zookeeper作为分布式锁也缺点：如果有很多的客户端频繁的申请加锁、释放锁，对于zookeeper集群的压力会比较大。
5. 三种分布式锁对比
5.1 数据库分布式锁实现
优点：
简单，使用方便，不需要引入redis、zookeeper等中间件。
缺点：
不适合高并发的场景
db操作性能较差；
5.2 redis分布式锁实现
优点：
性能好，适合高并发场景
较轻量级
有较好的框架支持，如redisson
缺点：
过期时间不好控制
需要考虑锁被别的线程误删场景
5.3 zookeeper分布式锁实现
缺点：
性能不如redis实现的分布式锁
比较重的分布式锁。
优点：
有较好的性能和可靠性
有封装较好的框架，如curator
5.4 对比汇总
从性能角度（从高到低）redis > zookeeper >= 数据库；
从理解的难易程度角度（从低到高）数据库 > redis > zookeeper；
从实现的复杂性角度（从低到高）zookeeper > redis > 数据库；
从可靠性角度（从高到低）zookeeper > redis > 数据库。
伯特利拟募集资金6.17亿元 各家上市公司年报
比克电池预计2020年开发出6Ah产品
蓝牙HI-FI车载DSP数字音频方案
首款模拟IC方案,解决产品三大阶段可靠性问题
贸泽备货Bosch BMM350磁力计 为3D、虚拟和增强现实、室内导航等领域提供支持
探讨一下分布式锁的设计与实现
华为开始进军6G，6G网速到底有多快？
DeepMind开源了一个内部强化学习库TRFL
选择性波峰焊介绍
诺基亚9什么时候上市？最新消息：诺基亚9工程机、跑分、配置曝光，超强旗舰来袭实力不容小觑！
基于TMS320F2812 DSP的交流永磁同步直线电机控制
360N7Lite评测 在同价位的千元机中几乎是没有对手的
长虹等家电厂商“拓路”智慧家庭 竞谋物联“蓝海”
华为Mate40 RS保时捷斩获2020年手机保值榜第一
AD20拼板步骤
虚拟现实火爆的背后 这7个问题需要解决
为何UWB定位方案能快速占领室内定位市场？
智能配电柜与普通配电柜
为什么单片机的I/O口需要驱动？
亚马逊携手 AWS 为企业提供混合云基础架构