上篇介绍了redis在集群环境下如何解决session共享的问题。今天来讲一下如何解决分布式锁的问题

什么是分布式锁?

分布式锁就是在多个服务器中,都来争夺某一资源。这时候我们肯定需要一把锁是不是 ,这个锁就是分布式锁,就算不是分布式,单机情况下,多个进程来争夺同一个资源,我们也要一把锁来控制先后顺序不是。分布式锁就是在多个服务器场景中来争夺相同的资源。打个比方,比如调度任务。

比如说,我们一个商城网站,要求每分钟要执行一个定时任务的操作,目的是把下单之后30分钟未付款的,把订单取消,然后把库存还原过去。因为是在多tomcat下,这个定时任务肯定会在同一时刻多个服务器都要执行操作。但是我们需要的是其中一个服务器操作就行了。这时候,就要用到我们的分布式锁啦。

我们在用redis来实现这个分布式锁的功能。我们会用到setnx方法,del方法,expire方法,getset方法  (这些方法的特性自己去百度下最好)

大致原理:我们利用setnx方法来设置一个key(写死的,以后都要用这个key获取锁),value的值(当前时间戳+锁的过期时间),如果设置成功返回1,说明我们已经获取锁,

然后再用expire方法设置key的有效期,因为肯定要有一个有效期的,不然你这一分钟已经执行完了,别人还想利用setnx获取锁,就一直获取不到,就造成了死锁。

设置好有效期之后,然后执行关单的业务逻辑,然后删除key。

其他服务器同时间操作,也是先setnx一下,结果发现别人已经获取到了锁,就返回失败0,然后就不执行关单操作。

上面的方法看似还可以,但是有一些bug,比如说服务器1setnx之后准备设置过期时间勒,服务器重启了,那是不是这个key就一直就消失不了了,那就造成了死锁。后面的永远都获取不到这个锁。细心的你肯定发现了,我们之前setnx的时候value还没用上呢?哈哈,现在就要用上了,我们来稍微改造一下。

我们之前的逻辑是如果获取锁,就执行设置过期时间,关单操作,没有获取锁就不执行关单操作。

我们现在改成如果没有获取锁,再进行一次判断,我们获取当前这个锁的value,因为key是我们写死的常量,我们可以从redis获取value时间戳

我们得到时间戳之后判断一下,这个时间戳和当前时间比那个大,如果当前时间大,说明这个锁已经过期了。因为我们上面已经说了,这个value的值就是当前时间+锁的过期时间

然后我们用getset方法重新设置锁的有效期,然后得到老得时间和再用单纯的get方法再获取老得时间,看是否相等,这点非常重要,因为相等说明中间没有其他线程获取到这个锁。可能有点迷,看代码就不迷了。ok   看代码吧

第一种会出现死锁的场景和第二种双重判断防止死锁的场景都有  注释很清楚

/**
* 可能出现死锁,虽然在执行close的时候有防死锁,但是还是会出现,继续演进V3
*/
// @Scheduled(cron="0 */1 * * * ?")//每1分钟(每个1分钟的整数倍)
public void closeOrderTaskV2() throws InterruptedException {
long lockTimeout = Long.parseLong(PropertiesUtil.getProperty("lock.timeout","5000"));//锁5秒有效期
//这个时间如何用呢,看下面。和时间戳结合起来用。
Long setnxResult = RedisShardedPoolUtil.setnx(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK, String.valueOf(System.currentTimeMillis()+lockTimeout));
if(setnxResult != null && setnxResult.intValue() == 1){
//如果返回值是1,代表设置成功,获取锁
closeOrder(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
}else{
log.info("没有获得分布式锁:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
}
} /**
* 防死锁之分布式锁
* @throws InterruptedException
*/
// @Scheduled(cron="0 */1 * * * ?")//每1分钟(每个1分钟的整数倍)
public void closeOrderTaskV3() throws InterruptedException {
//防死锁分布式锁
long lockTimeout = Long.parseLong(PropertiesUtil.getProperty("lock.timeout","50000"));//锁50秒有效期
//项目由于历史数据关单订单比较多,需要处理,初次用50s时间,后续改成5s即可.同时50s也为了讲课debug的时候时间长而设置。
//大家可以根据实际情况,如果历史订单都处理完毕,或者在外部进行洗数据ok,这里的lock的时间应该设置小一些,例如1s 2s 3s 4s 5s就足够啦。 //这个时间如何用呢,看下面。和时间戳结合起来用。
Long setnxResult = RedisShardedPoolUtil.setnx(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK, String.valueOf(System.currentTimeMillis()+lockTimeout));
if(setnxResult != null && setnxResult.intValue() == 1){
//如果返回值是1,代表设置成功,获取锁
closeOrder(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
}else{
//如果setnxResult==null 或 setnxResult.intValue() ==0 即 != 1的时候
//未获取到锁,继续判断,判断时间戳,看是否可以重置获取到锁
String lockValueStr = RedisShardedPoolUtil.get(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK); //如果lockValue不是空,并且当前时间大于锁的有效期,说明之前的lock的时间已超时,执行getset命令.
if(lockValueStr != null && System.currentTimeMillis() > Long.parseLong(lockValueStr)){
String getSetResult = RedisShardedPoolUtil.getSet(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK,String.valueOf(System.currentTimeMillis()+lockTimeout));
//再次用当前时间戳getset,
//返回给定 key 的旧值。 ->旧值判断,是否可以获取锁
// 当 key 没有旧值时,即 key 不存在时,返回 nil 。 ->获取锁
//这里我们set了一个新的value值,获取旧的值。
if(getSetResult == null || (getSetResult !=null && StringUtils.equals(lockValueStr,getSetResult))){
//获取到锁
closeOrder(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
}else{
log.info("没有获得分布式锁:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
}
}else{
log.info("没有获得分布式锁:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
}
}
} /**
* Redisson分布式锁实现
* @throws InterruptedException
*/
// @Scheduled(cron="0 */1 * * * ?")//每1分钟(每个1分钟的整数倍)
public void closeOrderTaskV4() throws InterruptedException {
RLock lock = redissonManager.getRedisson().getLock(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
boolean getLock = false;
try {
if(getLock = lock.tryLock(2,50, TimeUnit.SECONDS)){//trylock增加锁
log.info("===获取{},ThreadName:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK,Thread.currentThread().getName());
int hour = Integer.parseInt(PropertiesUtil.getProperty("close.order.task.time.hour","2"));
iOrderService.closeOrder(hour);
}else{
log.info("===没有获得分布式锁:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
}
}finally {
if(!getLock){
return;
}
log.info("===释放分布式锁:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
lock.unlock();
}
} private void closeOrder(String lockName){
// expire命令用于给该锁设定一个过期时间,用于防止线程crash,导致锁一直有效,从而导致死锁。
RedisShardedPoolUtil.expire(lockName,50);//有效期50秒,防死锁
log.info("获取{},ThreadName:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK,Thread.currentThread().getName());
int hour = Integer.parseInt(PropertiesUtil.getProperty("close.order.task.time.hour","2"));
iOrderService.closeOrder(hour);
RedisShardedPoolUtil.del(lockName);//释放锁
log.info("释放{},ThreadName:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK,Thread.currentThread().getName());
log.info("=============================");
}

#2018-04-10 21:57:01 再来填坑

再解释一下上面的逻辑,注意:上面有两个时间,一个key的过期时间,一个锁的过期时间。都是为了避免死锁的发生。

为毛要设置两个呢?任意一个都可以避免死锁啊?因为当我们setnx的时候是不能设置过期时间的,如果刚好setnx之后突然断电还没来得及设置key的过期时间,那岂不是会发生死锁。所以我们要再来个锁的过期时间来进一步判断。最根本原因是得到锁和设置key的过期时间没有同步,下面介绍一个redis分布式锁的框架。轻松解决分布式锁的问题,原理和上面一样,不过代码更为简单。不用过多的判断,框架已经帮我们做好了。

注意:Redisson这个框架不支持分布式就是只能一个redis,但是支持主从模式。和spring的session框架一样。切记

pom.xml     这个是Redisson所需的依赖

<dependency>
<groupId>org.redisson</groupId>
<artifactId>redisson</artifactId>
<version>2.9.0</version>
</dependency>
<!--com.fasterxml.jackson.dataformat.avro.PackageVersion-->
<dependency>
<groupId>com.fasterxml.jackson.dataformat</groupId>
<artifactId>jackson-dataformat-avro</artifactId>
<version>2.9.0</version>
</dependency>

RedissonManager.java

package com.mmall.common;

import com.mmall.util.PropertiesUtil;
import lombok.extern.slf4j.Slf4j;
import org.redisson.Redisson;
import org.redisson.config.Config;
import org.springframework.stereotype.Component; import javax.annotation.PostConstruct; /**
* Created by geely
*/
@Slf4j
@Component
public class RedissonManager {
//在redis环境没有搭建起来之前,这里先注释上,否则项目启动不起来。 private Config config = new Config(); private Redisson redisson = null; private final static String redis1Ip = PropertiesUtil.getProperty("redis1.ip");
private final static Integer redis1Port = Integer.parseInt(PropertiesUtil.getProperty("redis1.port")); //注入到Spring容器的话,使用@PostConstruct或者静态块初始化,效果是一样的{} @PostConstruct
private void init() {
try {
//在redis环境没有搭建起来之前,这里先注释上,否则项目启动不起来。 ////127.0.0.1:6379
config.useSingleServer().setAddress(new StringBuilder().append(redis1Ip).append(":").append(redis1Port).toString()); //单主模式
// config.useMasterSlaveServers().setMasterAddress(new StringBuilder().append(redis1Ip).append(":").append(redis1Port).toString()); //主从模式
// config.useMasterSlaveServers().setMasterAddress("10.211.55.6:6379").addSlaveAddress("10.211.55.6:6380"); // redisson = (Redisson) Redisson.create(config);
log.info("初始化Redisson结束");
} catch (Exception e) {
log.error("redisson init error", e);
}
} // {
// init();
// } public Redisson getRedisson() {
return redisson;
} }

下面是具体实现代码,原理一样,只不过简化操作。切记:一定要把tryLock的第一个参数等待获取锁的时间设置为0.有坑

/**
* Redisson分布式锁实现
* @throws InterruptedException
*/
// @Scheduled(cron="0 */1 * * * ?")//每1分钟(每个1分钟的整数倍)
public void closeOrderTaskV4() throws InterruptedException {
//意思是把Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK这个常量当成key
RLock lock = redissonManager.getRedisson().getLock(Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
boolean getLock = false;
try {
if(getLock = lock.tryLock(2,50, TimeUnit.SECONDS)){//trylock试着获取锁,2的意思是等待获取锁的时间为2s,要设为0,不然会出现一些意想不到的错误,50的意思就是锁的过期时间(同样也是key的过期时间)
log.info("===获取{},ThreadName:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK,Thread.currentThread().getName());
int hour = Integer.parseInt(PropertiesUtil.getProperty("close.order.task.time.hour","2"));
iOrderService.closeOrder(hour);
}else{
log.info("===没有获得分布式锁:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
}
}finally {
if(!getLock){
return;
}
log.info("===释放分布式锁:{}",Const.REDIS_LOCK.CLOSE_ORDER_TASK_LOCK);
lock.unlock();
}
}

ok,原生的方法有了,框架的也有了。点个赞吧。

在tomcat集群环境下redis实现分布式锁的更多相关文章

  1. Tomcat集群环境下session共享方案 通过memcached 方法实现

    对于web应用集群的技术实现而言,最大的难点就是:如何能在集群中的多个节点之间保持数据的一致性,会话(Session)信息是这些数据中最重要的一块.要实现这一点, 大体上有两种方式:一种是把所有Ses ...

  2. 【原创】Tomcat集群环境下对session进行外部缓存的方法(2)

    Session对象的持久化比较麻烦,虽然有序列化,但是并不确定Session对象中保存的其他信息是否可以序列化,这可能是网上很多解决方案摒弃此种做法的原因,网上的很多做法都是将Session中的att ...

  3. 【分布式缓存系列】集群环境下Redis分布式锁的正确姿势

    一.前言 在上一篇文章中,已经介绍了基于Redis实现分布式锁的正确姿势,但是上篇文章存在一定的缺陷——它加锁只作用在一个Redis节点上,如果通过sentinel保证高可用,如果master节点由于 ...

  4. 【原创】Tomcat集群环境下对session进行外部缓存的方法(1)

    BJJC网改版, 计划将应用部署在tomcat集群上,集群的部署方案为Apache+Tomcat6,连接件为mod_jk,其中开启了session复制和粘性session.计划节点数为3个. 到这,或 ...

  5. 分布式集群环境下,如何实现session共享五(spring-session+redis 实现session共享)

    这是分布式集群环境下,如何实现session共享系列的第五篇.在上一篇:分布式集群环境下,如何实现session共享四(部署项目测试)中,针对nginx不同的负载均衡策略:轮询.ip_hash方式,测 ...

  6. redis内存分配管理与集群环境下Session管理

    ##################内存管理############### 1.Redis的内存管理 .与memcache不同,没有实现自己的内存池 .在2..4以前,默认使用标准的内存分配函数(li ...

  7. redis 与java的连接 和集群环境下Session管理

    redis 的安装与设置开机自启(https://www.cnblogs.com/zhulina-917/p/11746993.html)  第一步: a) 搭建环境 引入 jedis jar包 co ...

  8. Redis集群环境下的键值空间监听事件实现方案

    一直想记录工作中遇到的问题和解决的方法,奈何没有找到一方乐土,最近经常反思,是否需要记录平时的点滴,后台还是决定下定决心记录一些,以便以后用到的时候找不着,实现这样的一个功能主要也是业务所需要的. 需 ...

  9. CAS服务器集群和客户端集群环境下的单点登录和单点注销解决方案

    CAS的集群环境,包括CAS的客户应用是集群环境,以及CAS服务本身是集群环境这两种情况.在集群环境下使用CAS,要解决两个问题,一是单点退出(注销)时,CAS如何将退出请求正确转发到用户sessio ...

随机推荐

  1. 让 VAGRANT 启动并运行起来

    这是一个帮助你快速入门Vagrant的初级教程.官方文档也可以很好的帮助你入门,但是本文更针对完全零基础的初学者并且会对某些问题直接切入正题. 本文在任何方面都不会取代官方文档,而且我建议读完本文的人 ...

  2. 软件工程_6th weeks

    一.上次博客时说的UI,拖拉到现在才展示,完成了“登录,普通匹配,做题界面,做题结果”四项 功能: 二.单元测试工具 1.python单元测试工具   最近因为论文原因一直在用Python,Pytho ...

  3. 自省 另外一种python 生成随机在base36 之间的兑换码生成。

    放假无聊,翻看自己博客的时候发现自己前面写的 那个base36兑换码在翻阅的时候 想到一个更简单的办法实现.但是随机上来说可能没有前者那么高 但是觉得也没有多大的问题 发上来 自己再想想 import ...

  4. 软件破解入门(暴力破解CrackMe)

    ---恢复内容开始--- 所谓暴力破解,就是通过修改汇编代码进而控制程序的运行流程,达到不需注册码也能正常使用软件的目的.相对于解出算法进而编写注册机,暴破的技术含量是比较低的.但也正是因为一本05年 ...

  5. delphi property read writer 如何使用

    type TMyClass = class(TObject) private FMyName: string; FMyAge: Integer; procedure SetAge(age: Integ ...

  6. Java之Array(数组)说明

    代码说明: package array; import java.util.ArrayList; import java.util.Arrays; import java.util.List; /** ...

  7. golang的interface剖析

      背景: golang的interface是一种satisfied式的.A类只要实现了IA interface定义的方法,A就satisfied了接口IA.更抽象一层,如果某些设计上需要一些更抽象的 ...

  8. BZOJ5338 [TJOI2018] Xor 【可持久化Trie树】【dfs序】

    题目分析: 很无聊的一道题目.首先区间内单点对应异或值的询问容易想到trie树.由于题目在树上进行,case1将路径分成两段,然后dfs的时候顺便可持久化trie树做询问.case2维护dfs序,对d ...

  9. Linux 配置Samba服务

    查看系统下是否已经安装了sambarpm -qa |grep samba 安装sambayum -y install samba 配置samba创建目录sambamkdir -p /home/samb ...

  10. 【刷题】BZOJ 2069 [POI2004]ZAW

    Description 在Byte山的山脚下有一个洞穴入口. 这个洞穴由复杂的洞室经过隧道连接构成. 洞穴的入口是一条笔直通向"前面洞口"的道路. 隧道互相都不交叉(他们只在洞室相 ...