图解Redis和Zookeeper分布式锁

图解,redis,zookeeper,分布式 · 浏览次数 : 139

小编点评

#分布式锁实现机制 **1.加锁原理** * 在Zookeeper上创建临时顺序节点Node01、Node02等2 * 第二步客户端拿到加锁路径下所有创建的节点 * 判断自己的序号是否最小,如果最小的话,代表加锁成功 * 不是最小的话,就对前一个节点创建监听器 **2.可重入锁** * 利用Map记录线程持有的锁ConcurrentMap<Thread, LockData> lockMap * 在释放锁的时候减少加锁的次数 * 获取到锁失败时尝试获取锁 **3.解锁原理解锁** * 判断锁是不是自己的 * 如果是则减少加锁次数 * 如果加锁次数等于0,则释放锁,删除掉创建的临时节点 *下一个监听这个节点的客户端会感知到节点删除事件,从而重新去获取锁 **4.Redis和Zookeeper锁对比** * **读性能**:Redis分布式锁高效的读写性能更能支持高并发 * **加锁性能**:Redis锁操作更快速,可以避免锁竞争 * **数据一致性**:Redis集群之间的数据同步是存在一定的延迟的,当主节点宕机后,数据如果还没有同步到从节点上,就会导致分布式锁失效,会造成数据的不一致 * **其他**:Redis分布式锁支持多种读写锁模式,可以根据业务需求选择 **5.总结** * 使用Redis还是Zookeeper来实现分布式锁,最终还是要基于业务来决定 * 可以参考京东物流 钟磊来源:京东云开发者社区

正文

1.基于Redis实现分布式锁

Redis分布式锁原理如上图所示,当有多个Set命令发送到Redis时,Redis会串行处理,最终只有一个Set命令执行成功,从而只有一个线程加锁成功

2:SetNx命令加锁

利用_Redis的setNx命令在Redis数据库中创建一个<Key,Value>记录,这条命令只有当Redis中没有这个Key的时候才执行成功,当已经有这个Key的时候会返回失败_

利用如上的_setNx命令便可以简单的实现加锁功能,当多个线程去执行这个加锁命令时,只有一个线程执行成功,然后执行业务逻辑,其他线程加锁失败返回或者重试_

3:死锁问题

上面的_setNx命令实现了基本的加锁功能,但存在一个致命的问题是,当程序在执行业务代码崩溃时,无法再执行到下面的解锁指令,从而导致出现死锁问题_

为了解决死锁问题,这里就需要_引入过期时间的概念,过期时间是给当前这个key设置一定的存活时间,当存活时间到期后,Redis就会自动删除这个过期的Key,从而使得程序在崩溃时也能到期自动释放锁_

如上图所示,使用Redis的_expire命令来为锁设置过期时间,从而实现到期自动解锁的功能,但这里仍然还存在一个问题就是加锁与给锁设置过期时间这两个操作命令并不是原子命令_

考虑下面这种情况:

当程序在加锁完成后,在设置过期时间前崩溃,这时仍然会造成锁无法自动释放,从而产生死锁现象

4:使用原子命令

针对上面加锁与设置过期时间不是原子命令的问题,Redis为我们提供了一个原子命令如下:

通过_SetNx(key,value,timeOut)这个结合加锁与设置过期时间的原子命令_就能完整的实现基于Redis的分布式锁的加锁步骤

5:解锁原理

解锁原理就是基于Redis的_del删除key指令_

6:错误删除锁问题

上面直接删除key来解锁方式会存在一个问题,考虑下面这种情况:

(1)线程1执行业务时间过长导致自己加的锁过期

(2)这时线程2进来加锁成功

(3)然后线程1业务逻辑执行完毕开始执行del key命令

(4)这时就会出现错误删除线程2加的锁

(5)错误删除线程2的锁后,线程3又可以加锁成功,导致有两个线程执行业务代码

7:加入锁标识

为了解决这种错误删除其他线程的锁的问题,在这里需要对加锁命令进行改造,需要在value字段里加入当前线程的id,在这里可以使用uuid来实现。线程在删除锁的时候,用自己的uuid与Redis中锁的uuid进行比较,如果是自己的锁就进行删除,不是则不删除

如上图所示,加锁时_在value字段中存入当前线程的id,然后在解锁时通过比较当前的锁是否是自己的来判断是否加锁成功,这样就解决了错误删除别人的锁的问题,但这里同样存在原子命令问题,比较并删除_这个操作并不是原子命令,考虑下面这种情况

(1)线程1获取uuid并判断锁是自己的

(2)准备解锁时出现GC或者其他原因导致程序卡顿无法立即执行Del命令,导致线程1的锁过期

(3)线程2就会在这个时候加锁成功

(4)线程1卡顿结束继续执行解锁指令,就会错误删除线程2的锁

这个问题出现的根本原因还是_比较并删除这两个操作并不是原子命令,只要两个命令被打断就有可能出现并发问题如果将两个命令变为原子命令就能解决这个问题_

8:引入lua脚本实现原子删除操作

_lua脚本_是一个非常轻量级的脚本语言,Redis底层天生支持lua脚本的执行,一个lua脚本中可以包含多条Redis命令,Redis会将整个lua脚本当作原子操作来执行,从而实现聚合多条Redis指令的原子操作,其原理如下图所示:

这里在解锁时,使用lua脚本将_比较并删除_操作变为原子操作

//lua脚本如下
luaScript =  " if redis.call('get',key) == value then
                  return redis.call('del',key) 
               else 
                  return 0 
               end;"


如上面的lua脚本所示,Redis会将整个lua脚本当作一个单独的命令执行,从而实现多个命令的原子操作,避免多线程竞争问题,最终结合lua脚本实现了一个完整的分布式的加锁和解锁过程,伪代码如下:

uuid = getUUID();
//加锁
lockResut = redisClient.setNx(key,uuid,timeOut);
if(!lockResult){
    return;
}
try{
   //执行业务逻辑
}finally{
    //解锁
    redisClient.eval(delLuaScript,keys,values)
}
//解锁的lua脚本
delLuaScript =  " if redis.call('get',key) == value then
                     return redis.call('del',key) 
                  else 
                     return 0 
                  end;"

到此,我们最终实现了一个加锁和解锁功能较为完整的redis分布式锁了,当然作为一个锁来说,还有一些其他的功能需要进一步完善,例如_考虑锁失效问题,可重入问题等_

9:自动续期功能

在执行业务代码时,由于业务执行时间长,最终可能导致在业务执行过程中,自己的锁超时,然后锁自动释放了,在这种情况下第二个线程就会加锁成功,从而导致数据不一致的情况发生,如下图所示:

对于上述的这种情况,原因是由_于设置的过期时间太短或者业务执行时间太长导致锁过期,但是为了避免死锁问题又必须设置过期时间,那这就需要引入自动续期的功能,即在加锁成功时,开启一个定时任务,自动刷新Redis加锁key的超时时间,_从而避免上诉情况发生,如下图所示:

uuid = getUUID();
//加锁
lockResut = redisClient.setNx(key,uuid,timeOut);
if(!lockResult){
    return;
}
//开启一个定时任务
new Scheduler(key,time,uuid,scheduleTime)
try{
   //执行业务逻辑
}finally{
    //删除锁
    redisClient.eval(delLuaScript,keys,values)
    //取消定时任务
    cancelScheduler(uuid);
}

如上诉代码所示,在加锁成功后可以启动一个定时任务来对锁进行自动续期,定时任务的执行逻辑是:

(1)判断Redis中的锁是否是自己的

(2)如果存在的话就使用expire命令重新设置过期时间

这里由于需要两个Redis的命令,所以也需要使用lua脚本来实现原子操作,代码如下所示:

luaScript = "if redis.call('get',key) == value) then
                return redis.call('expire',key,timeOut);
             else
                return 0;
             end;"

10:可重入锁

对于一个功能完整的锁来说,可重入功能是必不可少的特性,所谓的锁可重入就是同一个线程,第一次加锁成功后,在第二次加锁时,无需进行排队等待,只需要判断是否是自己的锁就行了,可以直接再次获取锁来执行业务逻辑,如下图所示:

实现可重入机制的原理就是_在加锁的时候记录加锁次数,在释放锁的时候减少加锁次数,这个加锁的次数记录可以存在Redis中,如下图所示:_

如上图所示,加入可重入功能后,加锁的步骤就变为如下步骤:

(1)判断锁是否存在

(2)判断锁是否是自己的

(3)增加加锁的次数

由于增加次数以及减少次数是多个操作,这里需要再次使用lua脚本来实现,同时由于这里需要在Redis中存入加锁的次数,所以需要使用到Redis中的Map数据结构_Map(key,uuid,lockCount),_加锁lua脚本如下:

//锁不存在
if (redis.call('exists', key) == 0) then
    redis.call('hset', key, uuid, 1); 
    redis.call('expire', key, time); 
    return 1;
end;
//锁存在,判断是否是自己的锁
if (redis.call('hexists', key, uuid) == 1) then
    redis.call('hincrby', key, uuid, 1); 
    redis.call('expire', key, uuid);
    return 1; 
end; 
//锁不是自己的,返回加锁失败
return 0;

加入可重入功能后的解锁逻辑就变为:

(1)判断锁是否是自己的

(2)如果是自己的则减少加锁次数,否则返回解锁失败

//判断锁是否是自己的,不是自己的直接返回错误
if (redis.call('hexists', key,uuid) == 0) then
    return 0;
end;
//锁是自己的,则对加锁次数-1
local counter = redis.call('hincrby', key, uuid, -1);
if (counter > 0) then 
    //剩余加锁次数大于0,则不能释放锁,重新设置过期时间
    redis.call('expire', key, uuid); 
    return 1;
else
//等于0,代表可以释放锁了
    redis.call('del', key); 
    return 1; 
end; 

到此,我们在实现基本的_加锁与解锁的逻辑上,又加入了可重入和自动续期的功能_,自此一个完整的Redis分布式锁的雏形就实现了,伪代码如下:

uuid = getUUID();
//加锁
lockResut = redisClient.eval(addLockLuaScript,keys,values);
if(!lockResult){
    return;
}
//开启一个定时任务
new Scheduler(key,time,uuid,scheduleTime)
try{
   //执行业务逻辑
}finally{
    //删除锁
    redisClient.eval(delLuaScript,keys,values)
    //取消定时任务
    cancelScheduler(uuid);
}

11:Zookeeper实现分布式锁

Zookeeper是一个分布式协调服务,分布式协调主要是来解决分布式系统中多个应用之间的数据一致性,Zookeeper内部的数据存储方式类似于文件目录形式的存储结构,它的内存结果如下图所示:

12:Zookeeper加锁原理

在Zookeeper中的指定路径下创建节点,然后客户端根据当前路径下的节点状态来判断是否加锁成功,如下图一种情况为例,线程1创建节点成功后,线程2再去创建节点就会创建失败

13:Zookeeper节点类型

持久节点:在Zookeeper中创建后会进行持久储存,直到客户端主动删除

临时节点:以客户端会话Session维度创建节点,一旦客户端会话断开,节点就会自动删除

临时/持久顺序节点:在同一个路径下创建的节点会对每个节点按创建先后顺序编号

zookeeper.exists("/watchpath",new Watcher() {
    @Override
    public void process(WatchedEvent event) {
	System.out.println("进入监听器");
	System.out.println("监听路径Path:"+event.getPath());
	System.out.println("监听事件类型EventType:"+event.getType());				
    }			
});	

14:利用临时顺序节点和监听机制来实现分布式锁

实现分布式锁的方式有多种,我们可以使用临时节点和顺序节点这种方案来实现分布式锁:

1:使用临时节点可以在客户端程序崩溃时自动释放锁,避免死锁问题

2:使用顺序节点的好处是,可以利用锁释放的事件监听机制,来实现_阻塞监听式的分布式锁_

下面将基于这两个特性来实现分布式锁

15:加锁原理

1:首先在Zookeeper上创建临时顺序节点Node01、Node02等

2:第二步客户端拿到加锁路径下所有创建的节点

3:判断自己的序号是否最小,如果最小的话,代表加锁成功,如果不是最小的话,就对前一个节点创建监听器

4:如果前一个节点删除,监听器就会通知客户端来准备重新获取锁

加锁原理和代码入下图所示:

//加锁路径
String lockPath;
//用来阻塞线程
CountDownLatch cc = new CountDownLatch(1);
//创建锁节点的路径
Sting LOCK_ROOT_PATH = "/locks"

//先创建锁
public void createLock(){
    //lockPath = /locks/lock_01 
    lockPath = zkClient.create(LOCK_ROOT_PATH+"/lock_", CreateMode.EPHEMERAL_SEQUENTIAL);
}

//获取锁
public boolean acquireLock(){
    //获取当前加锁路径下所有的节点
    allLocks = zkClient.getChildren("/locks");
    //按节点顺序大小排序
    Collections.sort(allLocks);
    //判断自己是否是第一个节点
    int index = allLocks.indexOf(lockPath.substring(LOCK_ROOT_PATH.length() + 1));
    //如果是第一个节点,则加锁成功
    if (index == 0) {
        System.out.println(Thread.currentThread().getName() + "获得锁成功, lockPath: " + lockPath);
        return true;
    } else {
        //不是序号最小的节点,则监听前一个节点
        String preLock = allLocks.get(index - 1);
        //创建监听器
        Stat status = zkClient.exists(LOCK_ROOT_PATH + "/" + preLockPath, watcher);
        // 前一个节点不存在了,则重新获取锁
        if (status == null) {
            return acquireLock();
        } else { 
            //阻塞当前进程,直到前一个节点释放锁
            System.out.println(" 等待前一个节点锁释放,prelocakPath:"+preLockPath);
            //唤醒当前线程,继续尝试获取锁
            cc.await();
            return acquireLock();
        }
    }
}

private Watcher watcher = new Watcher() {
    @Override
    public void process(WatchedEvent event) {
         //监听到前一个节点释放锁,唤醒当前线程
         cc.countDown();
    }
}

16:可重入锁实现

Zookeeper实现可重入分布式锁的机制是_在本地维护一个Map记录,因为如果在Zookeeper节点维护数据的话,Zookeeper的写操作是很慢,集群内部需要进行投票同步数据,_所以在本地维护一个Map记录来记录当前加锁的次数和加锁状态,在释放锁的时候减少加锁的次数,原理如下图所示:

//利用Map记录线程持有的锁
ConcurrentMap<Thread, LockData> lockMap = Maps.newConcurrentMap();
public Boolean lock(){
    Thread currentThread = Thread.currentThread();
    LockData lockData = lockMap.get(currentThread);
    //LockData不为空则说明已经有锁
    if (lockData != null)    
    {
       //加锁次数加一
       lockData.lockCount.increment();
       return true;
    }
    //没有锁则尝试获取锁
    Boolean lockResult = acquireLock();
    //获取到锁
    if (lockResult)
    {
        LockData newLockData = new LockData(currentThread,1);
        lockMap.put(currentThread, newLockData);
        return true;
    }
    //获取锁失败
    return false;
}

17:解锁原理

解锁的步骤如下:

(1)判断锁是不是自己的

(2)如果是则减少加锁次数

(3)如果加锁次数等于0,则释放锁,删除掉创建的临时节点,下一个监听这个节点的客户端会感知到节点删除事件,从而重新去获取锁

public Boolean releaseLock(){
    LockData lockData = lockMap.get(currentThread);
    //没有锁
    if(lockData == null){
       return false; 
    }
    //有锁则加锁次数减一
    lockCount = lockData.lockCount.decrement();
    if(lockCount > 0){
        return true;
    } 
    //加锁次数为0
    try{
        //删除节点
        zkClient.delete(lockPath);
        //断开连接
        zkClient.close();
    finally{
        //删除加锁记录
        lockMap.remove(currentThread);
    }
    return true;
}

18:Redis和Zookeeper锁对比

|
|

Redis

|

Zookeeper

|
|

读性能

|

基于内存

|

基于内存

|
|

加锁性能

|

直接写内存加锁

|

Master节点创建好后与其他Follower节点进行同步,半数成功后才能返回写入成功

|
|

数据一致性

|

AP架构Redis集群之间的数据同步是存在一定的延迟的,当主节点宕机后,数据如果还没有同步到从节点上,就会导致分布式锁失效,会造成数据的不一致

|

CP架构当Leader节点宕机后,会进行集群重新选举,如果此时只有一部分节点收到了数据的话,会在集群内进行数据同步,保证集群数据的一致性

|

19:总结

使用Redis还是Zookeeper来实现分布式锁,最终还是要基于业务来决定,可以参考以下两种情况:

(1)如果业务并发量很大,Redis分布式锁高效的读写性能更能支持高并发

(2)如果业务要求锁的强一致性,那么使用Zookeeper可能是更好的选择

作者:京东物流 钟磊
来源:京东云开发者社区

与图解Redis和Zookeeper分布式锁相似的内容:

图解Redis和Zookeeper分布式锁

使用Redis还是Zookeeper来实现分布式锁,最终还是要基于业务来决定,可以参考以下两种情况: (1)如果业务并发量很大,Redis分布式锁高效的读写性能更能支持高并发 (2)如果业务要求锁的强一致性,那么使用Zookeeper可能是更好的选择

[转帖]Redis核心技术与实战

https://www.cnblogs.com/strick/p/14851429.html 最近在读一篇关于Redis的专栏,叫做《Redis核心技术与实战》,作者在Redis方面研究颇深,读后非常受益,特在此做记录。 一、Redis基础 1)知识图和问题画像图 Redis知识全景图都包括“两大维

文章导读

Linux系统系列 Redis 初识Redis与桌面客户端 解读Redis常见命令 Redis持久化 (RDB和AOF) 梳理 JumpServer CentOS7下搭建JumpServer(v2.28.6) 堡垒机 JumpServer(v2.28.6) 堡垒机添加Linux资产 (图文教程) J

云小课|云小课教您如何选择Redis实例类型

阅识风云是华为云信息大咖,擅长将复杂信息多元化呈现,其出品的一张图(云图说)、深入浅出的博文(云小课)或短视频(云视厅)总有一款能让您快速上手华为云。更多精彩内容请单击此处。 摘要:购买Redis实例时,实例类型有单机、主备、Proxy集群、Cluster集群和读写分离这么多种,该怎么选?别担心,本

[转帖]一张图搞定redis内存优化及配置

https://www.jianshu.com/p/3195663af83e Redis内存优化及配置.png Redis优化及配置 Redis所有的数据都在内存中,而内存又是非常宝贵的资源。常用的内存优化方案有如下几部分:一、配置优化二、缩减键值对象三、命令处理四、缓存淘汰方案 一、配置优化 Li

[转帖]redis操作 + StrictRedis使用

https://www.cnblogs.com/szhangli/p/9979600.html Redis string类型 字符串类型是 Redis 中最为基础的数据存储类型。 它在 Redis 中是二进制安全的,这便意味着该类型可以接受任何格式的数据。 如JPEG图像数据或Json对象描述信息等

[转帖]MySQL十六:36张图理解Buffer Pool

https://www.cnblogs.com/yunlongn/p/16630257.html 转载~ 在应用系统中,我们为加速数据访问,会把高频的数据放在「缓存」(Redis、MongoDB)里,减轻数据库的压力。 在操作系统中,为了减少磁盘IO,引入了「缓冲池」(buffer pool)机制。

[转帖]【Jmeter】Jmeter压力测试工具安装及使用教程(redis测试)

摘自:https://www.cnblogs.com/monjeo/p/9330464.html 一、Jmeter下载 进入官网:http://jmeter.apache.org/ 1.第一步进入官网如下图 2.选择进行下载,下载下来为一个压缩包,解压即可。 3.我下载的是jmeter4.0版本,对

图解CPU的实模式与保护模式

作者:小牛呼噜噜 大家好,我是呼噜噜,由于x86保护模式是比较复杂晦涩的,所以特地单拉出来,实模式和保护模式一个重要的更新就是对内存的管理与保护,并且随着软件的发展,为了极致地压榨CPU的性能,硬件和软件都做出了许多努力,为了更好的管理内存,引入分段,分页,段页等等。本文会沿着内存的主线,穿插于实模

图解计算机内部的高速公路 —— 总线系统

本文已收录到 GitHub · AndroidFamily,有 Android 进阶知识体系,欢迎 Star。技术和职场问题,请关注公众号 [彭旭锐] 进 Android 面试交流群。 前言 大家好,我是小彭。 在之前的文章中,我们聊到了计算机的冯·诺依曼计算机架构,计算机由五大部件组成。那么,计算