分布式锁
为什么要用分布式锁?
在分布式场景下多个客户端同时获取一把锁,为了保证只有一个客户端能获取到这把锁,分布式锁诞生了,而分布式锁的诞生就是为了解决数据的最终一致性.在分布式系统中有一个著名的原理叫做CAP原理:其中Consistency(一致性)、 Availability(可用性)、Partition tolerance(分区容错性),它描述的是在分布式系统中同时最多只能满足其中两个条件,如果你想实现强一致性你就需要牺牲高性能.如果服务是单点,那其实本质上就不存在分布式锁这个概念.
本文接下来将探讨实现分布式锁的几种解决方案,并做下对比
1. 说明
关于分布式锁这块,其实没有办法做到100%的绝对安全性
2. 背景
在很多秒杀系统中、生成全局唯一递增id、支付、任务分配等场景都需要用到分布式锁
3. 数据库乐观锁
基于数据库乐观锁实现分布式锁,讲到乐观锁顺便讲一下悲观锁
悲观锁:悲观锁认为所有的操作都是不安全的,所以操作之前它先上锁,比如行锁、表锁都是基于悲观锁原理实现的
乐观锁:乐观锁和悲观锁不同的是,只在数据更新的做比较,查询阶段不加锁,所以性能上要快一些
乐观锁的实现大多是基于数据库的版本号机制去实现的,简单的来说就是,即为数据增加一个版本标识,在基于数据库表的版本解决方案中,一般是通过为数据库表添加一个 “version”字段来实现读取出数据时,将此版本号一同读出,之后更新时,对此版本号加1,其中id是唯一建.
假设数据库有这样一条记录:
id | name | version |
---|---|---|
1 | jack | 100 |
大致的过程就是:
这个时候假设有两个线程(c1,c2)同时要对id为1的记录进行修改
1)先查询出来id为1的记录
2)那么两个线程查询出来的结果都是一样的,c1想把id为1的name修改成tom,c2想把id为1的name修改成robin
3)c1在更新的时候,c2也在更新记录,假设c2后更新,更新的时候两者都带上最近一次查询的版本号
4)如果发现更新失败,重试,说明此记录已经被修改
这个实现看看就行了
4. 基于Redis分布式锁实现
redis分布式锁是目前很多大公司采取的技术解决方案,基于Redis单线程模式,采用队列模式,队列本是就是先进后出的模型,将并发访问转变成串行访问,这样就避免了资源的有序性和竞争关系.
早期的时候我们用的比较多的是setNX命令,做一些简单的操作,伪代码如下:
long result= JedisUtil.setnx(key,value);
if(result>0) {
JedisUtil.expire(key,locktime);
return true;
}
long expire=Jedisutil.ttl(key);
if(expire<0){
if(expire==-1{
JedisUtil.remove(key);
....
}
}
这段代码看似没有什么毛病,一般情况下也确实问题不大,但是实现上并不是安全的.
1)第一种情况:执行expire命令时候发生了网络抖动,执行超时或者失败了,如果这把锁不释放,它将会成为死锁.(我的想法比较~发生的概率比较小)
2)第二种情况:因为现在的操作是非原子性的,那么理论上说你的操作都可以被“打断”,比如你的redis部署采用哨兵集群模式,简单了来说就是HA高可用,主从模式,其实严格来说就不是集群了,如果主节点挂了,由于是主从异步复制的,这个时候从还没同步过去,就导致主有这个key而从没有key,被提升为主的从节点会导致在某个时刻,会有多个客户端同时持有该key.这个在后续的redlock和redission中都有解决.
3)第三种情况:超时时间如果控制的不但,会出现,任务还没执行完,到了超时时间,这个时候锁自动释放了,这个就尴尬了,此时你就要解决自动续租的问题了
4)效率比较低,强依赖于失效时间,需要一直去轮询锁是否失效
redis官方推荐我们配合lua脚本去解决原子性问题:
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
Object result = jedis.eval(script, Collections.singletonList(fullKey), Collections.singletonList(value));
if (Objects.equals(UNLOCK_SUCCESS, result)) {
flag = true;
}
redission实现分布式锁
楼主比较推荐: 因为简单易用,功能强大
相比Jedis而言可伸缩性性更高,jedis使用的是阻塞IO,而Redisson使用非阻塞的I/O和基于Netty框架的事件驱动的通信层,而且Redisson的API是线程安全的,这个就比较讨人喜欢了.
支持更丰富的数据结构比如:BitSet, Set, Multimap, SortedSet, Map, List, Queue, BlockingQueue, Deque, BlockingDeque, Semaphore, Lock, AtomicLong, CountDownLatch, Publish / Subscribe, Bloom filter, Remote service, Spring cache, Executor service, Live Object service, Scheduler service
引入maven依赖:
<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>2.2.13</version>
</dependency>
代码实现:
RLock lock = redisson.getLock("lockName");
try{
// 尝试加锁,最多等待2秒,上锁以后8秒自动解锁
boolean res = lock.tryLock(2, 8, TimeUnit.SECONDS);
if(res){ //成功
//处理业务
}
} catch (InterruptedException e) {
e.printStackTrace();
} finally {
//释放锁
lock.unlock();
}
5. 基于zk开源客户端Curator实现分布式锁
Curator内部是通过InterProcessMutex(可重入锁)来在zookeeper中创建临时有序节点实现的.基于zab协议保证锁的数据安全性,基于ping的心跳保活机制解决死锁问题,并通过watch机制能及时唤醒被阻塞的状态
1). 基于Zk名称唯一性
利用名称唯一性,加锁操作就是建立一个znode节点,释放锁就是删除这个目录,操作简单,ZAB一致性协议保证了锁的数据安全性。缺点就是会产生著名的“羊群”效应,N个客户端在等待一把锁时,锁释放时候所有客户端都被唤醒,而仅仅只有一个客户端才能得到锁。
2). 基于临时有序顺序节点
首先建立一个节点;
当进程访问资源时,获得锁,创建znode节点下顺序节点;
对znode节点下子节点排序,序号最小的获得锁;后面的节点获得上一顺序节点,并注册监听事件,等待监听事件,获得锁;资源用完后释放资源,调用unlock,去关掉zk
InterProcessMutex lock = new InterProcessMutex(client, lockPath);
if ( lock.acquire(maxWait, waitUnit) ) {
try
{
} finally {
lock.release();
}
}
基于zk实现的分布式锁,安全可靠,也不需要考虑没有设置失效时间的问题,因为zk会自动删除znode节点目录,但是zk相对redis效率比较低,因为他会频繁的创建和销毁节点,性能上不是很好,所以不太适合并发比较高的业务场景.