CN110287206A

CN110287206A - 构建用于Redis数据库的分布式锁的方法

Info

Publication number: CN110287206A
Application number: CN201910583604.6A
Authority: CN
Inventors: 李长彬
Original assignee: Sichuan XW Bank Co Ltd
Current assignee: Sichuan XW Bank Co Ltd
Priority date: 2019-07-01
Filing date: 2019-07-01
Publication date: 2019-09-27
Anticipated expiration: 2039-07-01
Also published as: CN110287206B

Abstract

本发明涉及构建用于Redis数据库的分布式锁的方法，包括：A.在RabbitMQ中创建死信交换机和直连交换机，以及创建死信队列和分布式锁队列，将死信队列和死信交换机绑定，分布式锁队列分别与死信交换机分别和直连交换机绑定；B.定义基于Redssion的用于获取分布式锁和释放分布式锁的工具类；C.定义死信队列的消费者类；D.调用工具类中的加锁方法，得到加锁是否成功的结果；E.加锁成功，则执行业务代码；加锁失败，退出执行业务代码；F.锁释放。本发明能够满足高并发场景中的性能诉求，并且解决了基于Redis数据库的锁失效时间机制，以及失效时间设置过长或过短导致锁提前释放等问题，实现了实现高可用性。

Description

构建用于Redis数据库的分布式锁的方法

技术领域

本发明涉及分布式系统中分布式锁的构建方法，具体讲是构建用于Redis数据库的分布式锁的方法。

背景技术

在分布式应用的场景下，有时需要保证一个资源在同一时间内只能被同一个操作方修改，因此就引入了分布式锁的概念和技术。为了实现分布式锁，目前比较常用的几种方式为：

1.基于数据库实现分布式锁：

步骤：

1)在数据库中创建一张锁表，用于记录每个线程对应持有的锁；

2)获取锁的时候，向锁表中增加一条记录；

3)释放锁的时候，删除这条记录；

缺点：

1)性能不能满足高并发场景的诉求；

2)为了提高可用性，解决单点问题，需要两台数据库，并互为主备，运维难度高；

3)为了实现阻塞锁，需要不断尝试直到成功，这种方式验证浪费服务资源；

4)为了实现可重入锁，需要记录机器信息、线程信息，操作繁琐复杂；

5)为了解决死锁，需要记录锁失效时间，做一个定时任务，每隔一定时间把数据库超时的数据清理掉，增量了工作量而且也不能做到即时释放锁资源；

2.基于zookeeper(一种分布式的、开放源码的分布式应用程序协调服务)实现分布式锁：

步骤：

1)在zookeeper对于指定节点的目录下，生成一个唯一的瞬时有序节点；

2)获取锁的时候，只需要判断有序节点中序号最小的一个；

3)释放锁的时候，将这个瞬时节点删除即可；

缺点：

1)性能较低，不能满足高并发场景的诉求；

3.基于Redis(一种开源的数据库)实现分布式锁：

步骤：

1)调用RedissonClient的tryLock方法来实现获取锁；

2)调用RedissonClient的unlock方法实现释放锁；

缺点：

1)基于Redis的失效时间(Time To Live)机制，在服务宕机的情况下，可以自动释放锁。但是失效时间设置多长不好确定，如果设置的时间太短，方法没执行完，锁就自动释放了，那么就会导致并发问题。如果设置的时间太长，其他需要获取锁的线程有可能需要多等一段时间。

发明内容

本发明提供了一种构建用于Redis数据库的分布式锁的方法，以降低死锁风险、解决锁提前释放等问题、提高并发性能、实现高可用性(High Availability)。

本发明构建用于Redis数据库的分布式锁的方法，包括：

A.在RabbitMQ中创建死信交换机和直连交换机，以及创建死信队列和分布式锁队列，将死信队列和死信交换机绑定，分布式锁队列分别与死信交换机分别和直连交换机绑定；

B.定义基于Redssion的用于获取分布式锁和释放分布式锁的工具类；Redisson是一个在Redis的基础上实现的Java驻内存数据网格，还提供了许多分布式服务；

C.定义死信队列的消费者类，该类用于获取死信队列中的消息，并决定是否重置锁失效时间；

D.在需要获取分布式锁的业务里调用工具类中的加锁方法，得到加锁是否成功的结果；

E.如果步骤D加锁成功，则执行业务代码，得到业务结果；如果加锁失败，退出执行业务代码；

F.得到业务结果后，调用工具类中的解锁方法用于释放锁，得到锁释放，整个业务流程完成。

RabbitMQ是一种实现了高级消息队列协议(AMQP)的开源消息代理软件，亦称面向消息的中间件。由于RabbitMQ中不存在延时队列，但是可以通过设置消息的过期时间和死信队列来实现延迟队列，由消费者监听死信交换机绑定的队列，而不需要监听消息发送的队列。

在RabbitMQ中可以对队列和消息分别设置TTL(消息存活时间)，第一种方式是通过队列进行设置，该队列中所有的消息都存在相同的过期时间；第二种方式是通过对消息本身进行设置，使每条消息的过期时间都不一样。如果同时使用了这两种方式，则以过期时间小的那个数值为准。当消息达到过期时间还没有被消费，那么那个消息就成为了一个死信消息。

死信交换机(Dead Letter Exchange)与同普通的交换机基本相同，只是在某一个设置有死信交换机的队列中有消息过期了，会自动触发消息的转发，将消息发送到死信交换机中去。

因此，为了实现基于RabbitMQ的延迟队列，本发明建立了死信队列和分布式锁队列的两个队列，一个用于发送消息，一个用于消息过期后自动转发到目标队列，原理如图1所示。

进一步的，步骤A包括：

A1.在RabbitMQ中创建类型为direct的死信交换机；

A2.创建用于存放死信消息的死信队列，所述的死信交换机与死信队列通过对应的路由键进行绑定；

A3.创建类型为direct的直连交换机；

A4.创建用于存储分布式锁信息的分布式锁队列，并与死信队列通过对应的路由键进行绑定，所述的死信交换机会根据该路由键找到死信消息存放的死信队列；设置消息的存活时间。

进一步的，在步骤B所述的工具类中包含有四个方法，分别为：

tryLock方法：用于尝试获取分布式锁并发送分布式锁名称到分布式锁队列；

unlock方法：用于释放分布式锁；

isExists方法：用于判断分布式锁是否存在；

expire方法：用于重置锁失效时间。

具体的，在tryLock方法中包含四个参数：分布式锁名称、等待锁时间(等待获取锁的时间，如果超过指定的等待时间则认为获取锁失败)、锁失效时间(表示持有这把锁的最长时间，超过该时间后Redis会自动释放锁)和时间单位，调用该方法后如果返回结果为true表示加锁成功，返回结果为false表示加锁失败；

在unlock方法中包含分布式锁名称的参数；

在isExists方法中包含分布式锁名称的参数，该方法返回结果如果为true表示锁存在，如果为false表示锁不存在；

在expire方法有三个参数：分布式锁名称、锁失效时间和锁失效时间单位。

进一步的，步骤C所述的消费者类先获取死信队列中的消息，通过调用工具类中的方法判断锁是否释放，如没有被释放，向日志文件打印告警日志，然后再通过工具类进行重置锁失效时间，并将所述死信队列中的消息投递回分布锁队列，当该消息过期后会重新投递回死信队列进入步骤C，直到锁释放；如锁已释放不做任何处理。由此便解决了基于Redis数据库的锁失效时间机制，以及失效时间设置过长导致假象死锁问题和失效时间设置过短导致锁提前释放等问题。

本发明构建用于Redis数据库的分布式锁的方法能够满足高并发场景中的性能诉求，并且解决了基于Redis数据库的锁失效时间机制，以及失效时间设置过长导致假象死锁问题或失效时间设置过短导致锁提前释放等问题，同时还提供了锁释放超时告警机制，实现了实现高可用性。

以下结合实施例的具体实施方式，对本发明的上述内容再作进一步的详细说明。但不应将此理解为本发明上述主题的范围仅限于以下的实例。在不脱离本发明上述技术思想情况下，根据本领域普通技术知识和惯用手段做出的各种替换或变更，均应包括在本发明的范围内。

附图说明

图1为本发明中RabbitMQ延迟队列消息流转过程示意图。

图2为本发明构建用于Redis数据库的分布式锁的方法的流程图。

具体实施方式

如图2所示本发明构建用于Redis数据库的分布式锁的方法，包括：

A.创建延迟队列：

A1.在RabbitMQ中创建类型为direct的死信交换机；

A3.创建类型为direct的直连交换机；

A4.创建用于存储分布式锁信息的分布式锁队列，并与死信队列通过对应的路由键进行绑定，所述的死信交换机会根据该路由键找到死信消息存放的死信队列；设置消息的存活时间为30秒。

B.定义基于Redssion的用于获取分布式锁和释放分布式锁的工具类。在所述的工具类中包含有四个方法，分别为：

tryLock方法：用于尝试获取分布式锁并发送分布式锁名称到分布式锁队列。该方法有四个参数，第一个参数是分布式锁名称，第二个参数是等待锁时间(等待获取锁时间，如果超过指定的等待时间认为获取锁失败)，第三个参数是锁失效时间(表示持有这把锁的最长时间，超过该时间后Redis数据库会自动释放锁)，第四个参数是时间单位，调用该方法如果返回结果为true表示加锁成功，如果返回结果为false表示加锁失败。

unlock方法：用于释放分布式锁。该方法只有一个参数，是分布式锁名称。

isExists方法：用于判断分布式锁是否存在。该方法只有一个参数，是分布式锁名称，该方法如果返回结果为true表示锁存在，返回结果为false表示锁不存在。

expire方法：用于重置锁失效时间。该方法有三个参数，第一个参数是分布式锁名称，第二个参数是锁失效时间，第三个参数是锁失效时间单位。

C.定义死信队列的消费者类，该类用于获取死信队列中的消息，并决定是否重置锁失效时间。消费者类中只有一个方法，该方法只有一个参数，就是分布式锁名称。该方法首先获取死信队列中的消息，通过调用步骤C所述工具类的isExists方法判断锁是否释放，如没有被释放，打印告警日志到日志文件，用于锁释放超时告警。然后调用工具类的expire方法重置锁失效时间，并将死信队列中的消息投递回分布锁队列，当该消息过期后会重新投递回死信队列进入步骤C，直到锁释放；如锁已释放则不做任何处理。由此就解决了基于Redis的锁失效时间机制，以及失效时间设置过长导致假象死锁问题和失效时间设置过短导致锁提前释放等问题。

D.在需要获取分布式锁的业务里调用工具类中的tryLock方法，得到加锁是否成功的结果，返回结果为true表示加锁成功，结果为false表示加锁失败。

F.得到业务结果后，调用工具类中的unlock方法释放锁，得到锁释放，整个业务流程完成。

Claims

1.构建用于Redis数据库的分布式锁的方法，其特征包括：

B.定义基于Redssion的用于获取分布式锁和释放分布式锁的工具类；

2.如权利要求1所述的构建用于Redis数据库的分布式锁的方法，其特征为：步骤A包括：

A1.在RabbitMQ中创建类型为direct的死信交换机；

A3.创建类型为direct的直连交换机；

A4.创建用于存储分布式锁信息的分布式锁队列，并与死信队列通过对应的路由键进行绑定；设置消息的存活时间。

3.如权利要求1所述的构建用于Redis数据库的分布式锁的方法，其特征为：在步骤B所述的工具类中包含有四个方法，分别为：

unlock方法：用于释放分布式锁；

isExists方法：用于判断分布式锁是否存在；

expire方法：用于重置锁失效时间。

4.如权利要求3所述的构建用于Redis数据库的分布式锁的方法，其特征为：在tryLock方法中包含四个参数：分布式锁名称、等待锁时间、锁失效时间和时间单位，调用该方法后如果返回结果为true表示加锁成功，返回结果为false表示加锁失败；

在unlock方法中包含分布式锁名称的参数；

5.如权利要求1所述的构建用于Redis数据库的分布式锁的方法，其特征为：步骤C所述的消费者类先获取死信队列中的消息，通过调用工具类中的方法判断锁是否释放，如没有被释放，向日志文件打印告警日志，然后再通过工具类进行重置锁失效时间，并将所述死信队列中的消息投递回分布锁队列，当该消息过期后会重新投递回死信队列进入步骤C，直到锁释放；如锁已释放不做任何处理。