分布式锁 哨兵模式_正确解锁分布式锁的各种姿势

分布式锁

为什么要用分布式锁?

在分布式场景下多个客户端同时获取一把锁,为了保证只有一个客户端能获取到这把锁,分布式锁诞生了,而分布式锁的诞生就是为了解决数据的最终一致性.在分布式系统中有一个著名的原理叫做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依赖:

org.redisson

redisson

2.2.13

代码实现:

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效率比较低,因为他会频繁的创建和销毁节点,性能上不是很好,所以不太适合并发比较高的业务场景.