文档章节

分布式锁方案论证与实现

田心双木
 田心双木
发布于 2018/10/31 15:47
字数 1964
阅读 1946
收藏 106

概述

我们在实际的接口或者业务开发中,不管是服务器单点还是服务器集群,都会有分布式锁的使用场景。 比如最常见的接口重复提交(业务重复处理)、商品超卖等问题,通用的解决方案就是本文所使用的“分布式锁”, 在同一个业务中,其中一个请求获取到锁之后,其他请求只有在获取到锁的请求释放锁(或者锁失效)之后才能继续“争抢”锁, 没有获得锁的请求是没有执行业务的权限的。

方案论证

这里我们主要讨论两种方案:基于redis的分布式锁和基于zookeeper的分布式锁

基于redis的分布式锁

redis自身就提供了命令:SET key value NX PX expireTimeMs,专门用于处理分布式锁的场景,效率高且提供锁失效机制, 即使由于某种情况客户端没有发送解锁请求,也不会造成死锁。

但是如果redis跑在集群的情况下,由于redis集群之间采用异步的方式进行数据同步,因此在并发量大的情况下有可能遇到数据同步不及时造成多个请求同时获取到锁, 虽然业界有redlock算法以及redisson客户端实现能基本处理此类问题,也并不能完美解决这个问题,其算法逻辑实现还很复杂, 更有甚者有分布式的专家Martin写了一篇文章《How to do distributed locking》, 质疑redlock的正确性。Martin最后对redlock算法的形容是: neither fish nor fowl (非驴非马)。 本人觉得这篇文章(《基于Redis的分布式锁真的安全吗?》),就redis集群分布式锁的安全问题就讲得非常好。

结论:

  • 优点:性能好
  • 缺点:存在集群数据同步不及时问题;锁失效时间不好控制

因此,要想使用redis分布式锁,最好使用redis单点模式,但是没有人能保证redis单点的高可用性。

基于zookeeper的分布式锁

zookeeper是一个分布式的,开放源码的分布式应用程序协调服务,是一个为分布式应用提供一致性服务的软件, 提供的功能包括:配置维护、域名服务、分布式同步、组服务等。zookeeper机制规定同一个节点下只能有一个唯一名称的节点, zookeeper上的一个znode看作是一把锁,所有客户端都去create同一个znode,最终成功创建的那个客户端也即拥有了这把锁。 zookeeper节点有两大类型:持久化节点和临时节点,客户端创建一个临时节点,当此客户端与zookeeper server断开后,该临时节点会自动删除。 由于zookeeper本身就强一致性的实现机制,因此不存在数据不一致的问题。

zookeeper提供了原生的API方式操作zookeeper,因为这个原生API使用起来并不是让人很舒服,于是出现了zkclient这种方式,以至到后来出现了Curator框架, Curator对zkclient做了进一步的封装,让人使用zookeeper更加方便。有一句话,Guava is to JAVA what Curator is to Zookeeper。 Curator实现zookeeper分布式锁的基本原理如下:

  • 在zookeeper指定节点(${serviceLockName})下创建临时顺序节点node_n
  • 获取${serviceLockName}下所有子节点children
  • 对子节点按节点自增序号从小到大排序,判断本节点是不是第一个子节点
  • 若是,则获取锁;若不是,则监听比该节点小的那个节点的删除事件
  • 若监听事件生效,则回到第二步重新进行判断,直到获取到锁
  • 若超过等待时间,则获取锁失败

就上面的Curator对分布式锁实现的算法还是挺复杂的,效率也不是太高,因为创建节点、获取所有子节点并排序等操作涉及到多个网络IO以及代码逻辑处理,所以效率上会打折扣, 还有释放锁的时候只会删除children节点,并不会删除${serviceLockName}节点,因此zookeeper server中有可能会出现大量的${serviceLockName}节点占用内存空间和Watcher。

因此,本人觉得Curator有些过于复杂了,可以直接利用zookeeper的特性(一个节点下只能有一个唯一名称的节点,客户端创建一个临时节点,当此客户端与zookeeper server断开后,该临时节点会自动删除), 重复创建子节点会抛出KeeperException.NodeExistsException(节点已存在异常)来实现zookeeper分布式锁。

结论:

  • 优点:不存在数据不一致问题;有效的解决单点问题;锁有效时间控制灵活
  • 缺点:性能稍差,因为每次在创建锁和释放锁的过程中,都要动态创建、销毁临时节点来实现锁功能。并且创建和删除节点只能通过Leader服务器来执行,然后将数据同步到其他机器上。

因此,本文强烈推荐使用zookeeper来实现分布式锁,但是又会多引入组件,为项目增加了风险。

项目源码

本项目代码已经托管到github与码云上:
github :distributelock-spring-boot-starter
码云:distributelock-spring-boot-starter

使用方法

  1. 分布式锁starter jar包引用
<dependency>
   <groupId>cn.dslcode</groupId>
   <artifactId>distributelock-spring-boot-starter</artifactId>
   <version>1.0.0</version>
</dependency>
  1. spring-data-redis或zookeeper的jar包引用,使用redis的话需要依赖RedisTemplate
<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-data-redis</artifactId>
</dependency>

<dependency>
    <groupId>org.apache.zookeeper</groupId>
    <artifactId>zookeeper</artifactId>
    <version>${zookeeper.version}</version>
    <exclusions>
        <exclusion>
            <groupId>org.slf4j</groupId>
            <artifactId>slf4j-log4j12</artifactId>
        </exclusion>
        <exclusion>
            <groupId>log4j</groupId>
            <artifactId>log4j</artifactId>
        </exclusion>
    </exclusions>
</dependency>
  1. 配置参数
# 分布式锁方式:redis或zookeeper
#distributelock.type=redis
distributelock.type=zookeeper
# 使用redis分布式锁,配置redis连接
# spring.redis.host=127.0.0.1
# spring.redis.port=6379
# 使用zookeeper分布式锁,配置zookeeper连接
distributelock.zookeeper.connect-string=127.0.0.1:2181,127.0.0.1:2182,127.0.0.1:2183
  1. 在需要进行分布式锁控制的方法添加@Lockable注解,注解字段如下
public @interface Lockable {

    /** lock key前缀,每一个业务一个key */
    String key();

    /** 等待时间/毫秒 */
    int waitTimeMs() default 0;

    /** 锁过期时间/毫秒,只对redis有效 */
    int timeoutMs() default 5000;

    /**
     * 方法参数field名称,支持多级,如:方法参数名 或 方法参数名.对象名.对象名。
     * 利用反射取值,用于和key组合起来组成新的lockKey
     */
    String[] fields() default {};

    /** 获取锁失败提示消息,可将此消息抛出RuntimeException,然后用全局异常处理器处理 */
    String failMsg() default "请勿重复提交|2101";

}

使用示例

  1. 使用注解的方式,starter已配置AOP自动拦截带有该注解的方法
@PostMapping("createOrder")
@Lockable(key = "order.addOder", waitTimeMs = 5000, timeoutMs = 5000, fields = {"product.id", "token"})
public RestResponse createOrder(@RequestBody Product product, @RequestParam(name = "token") String token) {
    // TODO createOrder
    return RestResponse.success();
}

@Transactional
@Lockable(key = "product.minusStock", waitTimeMs = 5000, timeoutMs = 5000, fields = "product.id")
public void minusStock(Product product) {
    // TODO 商品扣减库存

}
  1. 不使用注解,直接使用DistributeLock.tryLock和DistributeLock.releaseLock方法。注意释放锁代码必须要在获得锁的情况下才能执行,并且需要用try finally,如下:
@Transactional
public void minusStock(Product product) {
   // TODO 商品扣减库存
   String lockValue = UUID.randomUUID().toString();
   boolean getLock = false;
   try {
       if (getLock = distributeLock.tryLock(lockKey, lockValue, waitTimeMs, timeoutMs)) {
           // TODO 获取锁成功,执行商品扣减库存业务逻辑

       }
       // 获取锁失败,执行失败业务逻辑
       if (!getLock) {
           throw new RuntimeException("当前操作用户过多,请稍后重试|2201");
       }
   } finally {
       // 获取锁成功才释放锁
       if (getLock) {
           distributeLock.releaseLock(lockKey, lockValue);
       }
   }
}

© 著作权归作者所有

共有 人打赏支持
田心双木
粉丝 30
博文 111
码字总数 80698
作品 0
成都
高级程序员
私信 提问
加载中

评论(17)

田心双木
田心双木

引用来自“sEvEnnn”的评论

redis集群会把slots分散到各个redis节点, setnx的key也只会在一个节点进行, 数据同步只是在master跟slave之间进行吧, 为什么master跟slave之间的数据同步会影响到多个请求获得锁? 请求同样的key只会请求到同一个redis节点, redis又是单核处理的, 不会同时多个请求得到锁吧?
看这篇文章,写的很清楚:http://www.sohu.com/a/128396689_487514
sEvEnnn
sEvEnnn
redis集群会把slots分散到各个redis节点, setnx的key也只会在一个节点进行, 数据同步只是在master跟slave之间进行吧, 为什么master跟slave之间的数据同步会影响到多个请求获得锁? 请求同样的key只会请求到同一个redis节点, redis又是单核处理的, 不会同时多个请求得到锁吧?
田心双木
田心双木

引用来自“Texl”的评论

引用来自“田心双木”的评论

引用来自“Texl”的评论

redis轮询去查看锁是否释放,性能也不高吧。zk用临时顺序节点,是为了排队吧
争抢严重的情况下,redis轮询是会消耗性能,我不是做了Thread.yield()与Thread.sleep(20 + 10*yieldTimes)的吗,会有所优化;zk用临时顺序节点不是为了排队,是利用“节点的唯一性与断开自动删除”特性。不知道有没有解答你的问题?

临时节点就可以保证唯一性和自动删除,加了个顺序就是为了实现公平性
其实这里顺序与否都无所谓,因为只有一个节点存在,节点唯一
T
Texl

引用来自“田心双木”的评论

引用来自“Texl”的评论

redis轮询去查看锁是否释放,性能也不高吧。zk用临时顺序节点,是为了排队吧
争抢严重的情况下,redis轮询是会消耗性能,我不是做了Thread.yield()与Thread.sleep(20 + 10*yieldTimes)的吗,会有所优化;zk用临时顺序节点不是为了排队,是利用“节点的唯一性与断开自动删除”特性。不知道有没有解答你的问题?

临时节点就可以保证唯一性和自动删除,加了个顺序就是为了实现公平性
田心双木
田心双木

引用来自“Texl”的评论

redis轮询去查看锁是否释放,性能也不高吧。zk用临时顺序节点,是为了排队吧
争抢严重的情况下,redis轮询是会消耗性能,我不是做了Thread.yield()与Thread.sleep(20 + 10*yieldTimes)的吗,会有所优化;zk用临时顺序节点不是为了排队,是利用“节点的唯一性与断开自动删除”特性。不知道有没有解答你的问题?
T
Texl
redis轮询去查看锁是否释放,性能也不高吧。zk用临时顺序节点,是为了排队吧
田心双木
田心双木

引用来自“抠你私处没商量”的评论

redis何来单点问题?老铁你想多了

单点问题就在于down机
田心双木
田心双木

引用来自“抠你私处没商量”的评论

就这种代码还能上推荐?笑话

说说你的理由呢?
田心双木
田心双木

引用来自“金贞花”的评论

这都能上推荐,真的服了

老铁,说说你的理由
抠你私处没商量
redis何来单点问题?老铁你想多了
基于Redis的分布式锁真的安全吗?(下)

自从我写完这个话题的上半部分之后,就感觉头脑中出现了许多细小的声音,久久挥之不去。它们就像是在为了一些鸡毛蒜皮的小事而相互争吵个不停。的确,有关分布式的话题就是这样,琐碎异常,而...

张铁蕾
2017/03/17
0
0
分布式锁总结

0 前言 可以先看下之前写的实现分布式锁的方案 分布式锁的实现 然后再来看下下面的总结。 1 设置锁超时时间 redis、数据库等实现的分布式锁,需要设置锁超时时间的原因在于:其他客户端无法得...

乒乓狂魔
2016/11/09
1K
0
Spring-data-redis + redis 分布式锁(一)

分布式锁的解决方式 基于数据库表做乐观锁,用于分布式锁。(适用于小并发) 使用memcached的add()方法,用于分布式锁。 使用memcached的cas()方法,用于分布式锁。(不常用) 使用redis的setnx...

xiaolyuh
2017/11/15
0
0
node.js 中使用redis实现分布式事物锁

在node项目中,我们常会跑一些定时任务,比如定时发送通知、定时发送邮件等,项目部署的时候,我们往往是多机多实例部署,这就导致每个实例都会跑一次同样的任务,所以我们需要一个分布式事物...

小黎也
2018/06/09
0
0
分布式锁的实现原理和三种实现方式

首先说一下锁的理解,是指对资源的独占使用,具有排他性,在某些业务情景是必要条件,但不能乱用,因为比如会对性能有很大的影响。 用java举例子,在单机器的情况下可以通过Synchronized或者...

小海bug
2018/07/06
0
0

没有更多内容

加载失败,请刷新页面

加载更多

RabbitMQ入门

RabbitMQ是一个由erlang开发的基于AMQP(Advanced Message Queue)协议的开源实现。用于在分布式系统中存储转发消息,在易用性、扩展性、高可用性等方面都非常的优秀。是当前最主流的消息中间...

watermelon11
今天
14
0
今天的学习

自动加载:方法一 function __autoload( $className ){在这里,完成加载B这个类文件的工作。}class A{} //这是一个类$a1 = new A(); //这里没有自动加载的发生,因为A这个类...

墨冥
今天
2
0
印刷工艺步骤

印刷厂从收到订单到交付整个流程,一般涉及到以下步骤 1.设计(经过软件如cdr,psd,ai等等设计需要印刷的名片,宣传单,画册等物料); 2.排版拼版(在电脑软件这区域完成); 3.出版、出硫...

focusone
昨天
2
0
virtualbox中安装ubuntu

virtualbox+ubuntu 安装virtualbox,当前版本是6.0.4 下载ubuntu安装盘,建议lubuntu,链接是http://mirrors.ustc.edu.cn/ubuntu-cdimage/lubuntu/releases/18.04.2/release/lubuntu-18.04.......

chuqq
昨天
5
0
exists 谓词的子查询

https://blog.csdn.net/qq_19782019/article/details/78730882

仟昭
昨天
4
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部