【210期】面试官——说说常用的Redis和zk两种分布式锁的对比

本人花费半年的时间总结的《Java面试指南》已拿腾讯等大厂offer,已开源在github ,欢迎star!

转载声明:转载请注明出处,本技术博客是本人原创文章

本文GitHub https://github.com/OUYANGSIHAI/JavaInterview 已收录,这是我花了6个月总结的一线大厂Java面试总结,本人已拿大厂offer,欢迎star

原文链接:blog.ouyangsihai.cn >> 【210期】面试官——说说常用的Redis和zk两种分布式锁的对比

点击上方“Java面试题精选”,关注公众号

面试刷图,查缺补漏

号外:公众号改版后文章顺序不固定,欢迎大家把我们面试题精选这个公众号设置为星标,感谢大家一年的支持!!

阶段汇总集合:

一、基于数据库实现分布式锁

1. 悲观锁

利用 select … where … for update 排他锁

注意: 其他附加功能与实现一基本一致,这里需要注意的是“where name=lock ”,name字段必须要走索引,否则会锁表。有些情况下,比如表不大,mysql优化器会不走这个索引,导致锁表问题。

2. 乐观锁

所谓乐观锁与前边最大区别在于基于CAS思想,是不具有互斥性,不会产生锁等待而消耗资源,操作过程中认为不存在并发冲突,只有update version失败后才能觉察到。我们的抢购、秒杀就是用了这种实现以防止超卖。

通过增加递增的版本号字段实现乐观锁

二、基于jdk的实现方式

思路:另启一个服务,利用jdk并发工具来控制唯一资源,如在服务中维护一个concurrentHashMap,其他服务对某个key请求锁时,通过该服务暴露的端口,以网络通信的方式发送消息,服务端解析这个消息,将concurrentHashMap中的key对应值设为true,分布式锁请求成功,可以采用基于netty通信调用,当然你想用java的bio、nio或者整合dubbo、spring cloud feign来实现通信也没问题

缺点:这种方式的分布式锁看似简单,但是要考虑可用性、可靠性、效率、扩展性的话,编码难度会比较高。

三、基于缓存(Redis等)实现分布式锁

1、官方叫做 RedLock 算法,是 redis 官方支持的分布式锁算法。

这个分布式锁有 3 个重要的考量点:

  • 1.互斥(只能有一个客户端获取锁)
  • 2.不能死锁
  • 3.容错(只要大部分 redis 节点创建了这把锁就可以)
  • 2、下面是redis分布式锁的各种实现方式和缺点,按照时间的发展排序

    1、直接setnx

    直接利用setnx,执行完业务逻辑后调用del释放锁,简单粗暴

    缺点:如果setnx成功,还没来得及释放,服务挂了,那么这个key永远都不会被获取到

    2、setnx设置一个过期时间

    为了改正第一个方法的缺陷,我们用setnx获取锁,然后用expire对其设置一个过期时间,如果服务挂了,过期时间一到自动释放

    缺点:setnx和expire是两个方法,不能保证原子性,如果在setnx之后,还没来得及expire,服务挂了,还是会出现锁不释放的问题

    3、set nx px

    redis官方为了解决第二种方式存在的缺点,在2.8版本为set指令添加了扩展参数nx和ex,保证了setnx+expire的原子性,使用方法: set key value ex 5 nx

    缺点

  • 如果在过期时间内,事务还没有执行完,锁提前被自动释放,其他的线程还是可以拿到锁
  • 上面所说的那个缺点还会导致当前的线程释放其他线程占有的锁
  • 4、加一个事务id

    上面所说的第一个缺点,没有特别好的解决方法,只能把过期时间尽量设置的长一点,并且最好不要执行耗时任务

    第二个缺点,可以理解为当前线程有可能会释放其他线程的锁,那么问题就转换为保证线程只能释放当前线程持有的锁,即setnx的时候将value设为任务的唯一id,释放的时候先get key比较一下value是否与当前的id相同,是则释放,否则抛异常回滚,其实也是变相地解决了第一个问题

    缺点:get key和将value与id比较是两个步骤,不能保证原子性

    5、set nx px + 事务id + lua

    我们可以用lua来写一个getkey并比较的脚本,jedis/luttce/redisson对lua脚本都有很好的支持

    缺点:集群环境下,对master节点申请了分布式锁,由于redis的主从同步是异步进行的,master在内存中写入了nx之后直接返回,客户端获取锁成功,此时master节点挂了,并且数据还没来得及同步,另一个节点被升级为master,这样其他的线程依然可以获取锁

    6、redlock

    为了解决上面提到的redis集群中的分布式锁问题,redis的作者antirez的提出了red lock的概念,假设集群中所有的n个master节点完全独立,并且没有主从同步,此时对所有的节点都去setnx,并且设置一个请求过期时间re和锁的过期时间le,同时re必须小于le(可以理解,不然请求3秒才拿到锁,而锁的过期时间只有1秒也太蠢了),此时如果有n / 2 + 1个节点成功拿到锁,此次分布式锁就算申请成功

    缺点:可靠性还没有被广泛验证,并且严重依赖时间,好的分布式系统应该是异步的,并不能以时间为担保,程序暂停、系统延迟等都可能会导致时间错误(网上还有很多人都对这个方法提出了质疑,比如full gc发生的锁的正确性问题,但是antirez都一一作出了解答,感兴趣的同学可以参考一下:

    https://www.xilidou.com/2017/10/23/Redis实现分布式锁/

    四、基于zookeeper实现的分布式锁

    1. 实现方式

    ZooKeeper是一个为分布式应用提供一致性服务的开源组件,它内部是一个分层的文件系统目录树结构,规定同一个目录下只能有一个唯一文件名。基于ZooKeeper实现分布式锁的步骤如下:

  • 创建一个目录mylock;
  • 线程A想获取锁就在mylock目录下创建临时顺序节点;
  • 获取mylock目录下所有的子节点,然后获取比自己小的兄弟节点,如果不存在,则说明当前线程顺序号最小,获得锁;
  • 线程B获取所有节点,判断自己不是最小节点,设置监听比自己次小的节点;
  • 线程A处理完,删除自己的节点,线程B监听到变更事件,判断自己是不是最小的节点,如果是则获得锁。
  • 这里推荐一个Apache的开源库Curator,它是一个ZooKeeper客户端,Curator提供的InterProcessMutex是分布式锁的实现,acquire方法用于获取锁,release方法用于释放锁。

    优点:具备高可用、可重入、阻塞锁特性,可解决失效死锁问题。

    缺点:因为需要频繁的创建和删除节点,性能上不如Redis方式。

    2. 两种利用特性实现原理:

    1、利用临时节点特性

    zookeeper的临时节点有两个特性,一是节点名称不能重复,二是会随着客户端退出而销毁,因此直接将key作为节点名称,能够成功创建的客户端则获取成功,失败的客户端监听成功的节点的删除事件

    缺点:所有客户端监听同一个节点,但是同时只有一个节点的事件触发是有效的,造成资源的无效调度

    2、利用顺序临时节点特性

    zookeeper的顺序临时节点拥有临时节点的特性,同时,在一个父节点下创建创建的子临时顺序节点,会根据节点创建的先后顺序,用一个32位的数字作为后缀,我们可以用key创建一个根节点,然后每次申请锁的时候在其下创建顺序节点,接着获取根节点下所有的顺序节点并排序,获取顺序最小的节点,如果该节点的名称与当前添加的名称相同,则表示能够获取锁,否则监听根节点下面的处于当前节点之前的节点的删除事件,如果监听生效,则回到上一步重新判断顺序,直到获取锁。

    总结

    基于数据库分布式锁实现

    优点:直接使用数据库,实现方式简单。
    缺点

  • db操作性能较差,并且有锁表的风险
  • 非阻塞操作失败后,需要轮询,占用cpu资源;
  • 长时间不commit或者长时间轮询,可能会占用较多连接资源
  • 基于jdk的并发工具自己实现的锁

    优点:不需要引入中间件,架构简单

    缺点:编写一个可靠、高可用、高效率的分布式锁服务,难度较大

    基于redis缓存

    1. redis set px nx + 唯一id + lua脚本

    优点:redis本身的读写性能很高,因此基于redis的分布式锁效率比较高

    缺点:依赖中间件,分布式环境下可能会有节点数据同步问题,可靠性有一定的影响,如果发生则需要人工介入

    2. 基于redis的redlock

    优点:可以解决redis集群的同步可用性问题

    缺点

  • 依赖中间件,并没有被广泛验证,维护成本高,需要多个独立的master节点;需要同时对多个节点申请锁,降低了一些效率
  • 锁删除失败 过期时间不好控制
  • 非阻塞,操作失败后,需要轮询,占用cpu资源;
  • 基于zookeeper的分布式锁

    优点:不存在redis的超时、数据同步(zookeeper是同步完以后才返回)、主从切换(zookeeper主从切换的过程中服务是不可用的)的问题,可靠性很高

    缺点:依赖中间件,保证了可靠性的同时牺牲了一部分效率(但是依然很高)。性能不如redis。

    jdk的方式不太推荐。

  • 从理解的难易程度角度(从低到高)数据库 缓存 Zookeeper
  • 从实现的复杂性角度(从低到高)Zookeeper = 缓存 数据库
  • 从性能角度(从高到低)缓存 Zookeeper = 数据库
  • 从可靠性角度(从高到低)Zookeeper 缓存 数据库
  • 没有绝对完美的实现方式,具体要选择哪一种分布式锁,需要结合每一种锁的优缺点和业务特点而定。

    END

    来源:cnblogs.com/owenma/p/12355262.html

    十期推荐

    与其在网上拼命找题?** 不如马上关注我们~**

    【210期】面试官:说说常用的Redis和zk两种分布式锁的对比

    原文始发于微信公众号(Java面试题精选):

    本人花费半年的时间总结的《Java面试指南》已拿腾讯等大厂offer,已开源在github ,欢迎star!

    转载声明:转载请注明出处,本技术博客是本人原创文章

    本文GitHub https://github.com/OUYANGSIHAI/JavaInterview 已收录,这是我花了6个月总结的一线大厂Java面试总结,本人已拿大厂offer,欢迎star

    原文链接:blog.ouyangsihai.cn >> 【210期】面试官——说说常用的Redis和zk两种分布式锁的对比


     上一篇
    【207期】19张图带你梳理SpringCloud体系中的重要知识点! 【207期】19张图带你梳理SpringCloud体系中的重要知识点!
    点击上方“Java面试题精选”,关注公众号 面试刷图,查缺补漏 号外:公众号改版后文章顺序不固定,欢迎大家把我们面试题精选这个公众号设置为星标,感谢大家一年的支持!! 阶段汇总集合: 1、什么是微服务1.1、架构演进架构的发展历程是从单体式
    2021-04-05
    下一篇 
    【208期】敲黑板,也来谈如何设计一个秒杀系统(重点) 【208期】敲黑板,也来谈如何设计一个秒杀系统(重点)
    点击上方“Java面试题精选”,关注公众号 面试刷图,查缺补漏 号外:公众号改版后文章顺序不固定,欢迎大家把我们面试题精选这个公众号设置为星标,感谢大家一年的支持!! 阶段汇总集合: 1. Overview1.1 并发读写秒杀要解决的主要问
    2021-04-05