目前几乎很多大型网站及应用都是分布式部署的,分布式场景中的数据一致性问题一直是一个比较重要的话题。分布式的CAP理论告诉我们“任何一个分布式系统都无法同时满足一致性(Consistency)、可用性(Availability)和分区容错性(Partition tolerance),最多只能同时满足两项。”所以,很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中,都需要牺牲强一致性来换取系统的高可用性,系统往往只需要保证“最终一致性”,只要这个最终时间是在用户可以接受的范围内即可。

  在很多场景中,我们为了保证数据的最终一致性,需要很多的技术方案来支持,比如分布式事务、分布式锁等。有的时候,我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中,Java中其实提供了很多并发处理相关的API,但是这些API在分布式场景中就无能为力了。也就是说单纯的Java Api并不能提供分布式锁的能力。所以针对分布式锁的实现目前有多种方案。

  针对分布式锁的实现,目前比较常用的有以下几种方案:

  基于数据库实现分布式锁、基于缓存(redis,memcached)、实现分布式锁 基于Zookeeper实现分布式锁。

  在分析这几种实现方案之前我们先来想一下,我们需要的分布式锁应该是怎么样的?(这里以方法锁为例,资源锁同理)

  可以保证在分布式部署的应用集群中,同一个方法在同一时间只能被一台机器上的一个线程执行。

  这把锁要是一把可重入锁(避免死锁)。

  这把锁最好是一把阻塞锁(根据业务需求考虑要不要这条)。

  有高可用的获取锁和释放锁功能。

  获取锁和释放锁的性能要好。

  基于Redis锁实现

  加锁

  private static final String LOCK_SUCCESS = OK;

  private static final String SET_IF_NOT_EXIST = NX;

  private static final String SET_WITH_EXPIRE_TIME = PX;

  /**

  * 尝试获取分布式锁

  * @param jedis Redis客户端

  * @param lockKey 锁

  * @param requestId 请求标识

  * @param expireTime 超期时间

  * @return 是否获取成功

  */

  public static boolean tryGetDistributedLock(Jedis jedis, String lockKey, String requestId, int expireTime) {

  String result = jedis.set(lockKey, requestId, SET_IF_NOT_EXIST, SET_WITH_EXPIRE_TIME, expireTime);

  if (LOCK_SUCCESS.equals(result)) {

  return true;

  }

  return false;

  }

  可以看到,我们加锁就一行代码:jedis.set(String key, String value, String nxxx, String expx, int time),这个set()方法一共有五个形参:

  第一个为key,我们使用key来当锁,因为key是唯一的。

  第二个为value,我们传的是requestId,很多童鞋可能不明白,有key作为锁不就够了吗,为什么还要用到value?原因就是我们在上面讲到可靠性时,分布式锁要满足第四个条件解铃还须系铃人,通过给value赋值为requestId,我们就知道这把锁是哪个请求加的了,在解锁的时候就可以有依据。requestId可以使用UUID.randomUUID().toString()方法生成。

  第三个为nxxx,这个参数我们填的是NX,意思是SET IF NOT EXIST,即当key不存在时,我们进行set操作;若key已经存在,则不做任何操作;

  第四个为expx,这个参数我们传的是PX,意思是我们要给这个key加一个过期的设置,具体时间由第五个参数决定。

  第五个为time,与第四个参数相呼应,代表key的过期时间。

  总的来说,执行上面的set()方法就只会导致两种结果:1. 当前没有锁(key不存在),那么就进行加锁操作,并对锁设置个有效期,同时value表示加锁的客户端。2. 已有锁存在,不做任何操作。

  心细的童鞋就会发现了,我们的加锁代码满足我们可靠性里描述的三个条件。首先,set()加入了NX参数,可以保证如果已有key存在,则函数不会调用成功,也就是只有一个客户端能持有锁,满足互斥性。其次,由于我们对锁设置了过期时间,即使锁的持有者后续发生崩溃而没有解锁,锁也会因为到了过期时间而自动解锁(即key被删除),不会发生死锁。最后,因为我们将value赋值为requestId,代表加锁的客户端请求标识,那么在客户端在解锁的时候就可以进行校验是否是同一个客户端。由于我们只考虑Redis单机部署的场景,所以容错性我们暂不考虑。

  解锁

  private static final Long RELEASE_SUCCESS = 1L;

  /**

  * 释放分布式锁

  * @param jedis Redis客户端

  * @param lockKey 锁

  * @param requestId 请求标识

  * @return 是否释放成功

  */

  public static boolean releaseDistributedLock(Jedis jedis, String lockKey, String requestId) {

  String script = if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end;

  Object result = jedis.eval(script, Collections.singletonList(lockKey), Collections.singletonList(requestId));

  if (RELEASE_SUCCESS.equals(result)) {

  return true;

  }

  return false;

  }

  可以看到,我们解锁只需要两行代码就搞定了!第一行代码,我们写了一个简单的Lua脚本代码,上一次见到这个编程语言还是在《黑客与画家》里,没想到这次居然用上了。第二行代码,我们将Lua代码传到jedis.eval()方法里,并使参数KEYS[1]赋值为lockKey,ARGV[1]赋值为requestId。eval()方法是将Lua代码交给Redis服务端执行。

  无论加锁还是解锁,必须是原子操作。

  分布式锁的异常问题

  如果一个获取到锁的client因为某种原因导致没能及时释放锁,并且Redis因为超时释放了锁,另外一个client获取到了锁,此时情况如下图所示:

  

  那么如何解决这个问题呢?

  一种方案是引入锁续约机制,也就是获取锁之后,释放锁之前,会定时进行锁续约,比如以锁超时时间的1/3为间隔周期进行锁续约。

  关于开源的Redis的分布式锁实现有很多,比较出名的有redisson、百度的dlock。

  对于高可用性,一般可以通过集群或者master-slave来解决,Redis锁优势是性能出色,劣势就是由于数据在内存中,一旦缓存服务宕机,锁数据就丢失了。

  像Redis自带复制功能,可以对数据可靠性有一定的保证,但是由于复制也是异步完成的,因此依然可能出现master节点写入锁数据而未同步到slave节点的时候宕机,锁数据丢失问题。这个暂时没有好的解决办法。

基于Redis分布式锁(获取锁及解锁)的更多相关文章

  1. RedLock.Net - 基于Redis分布式锁的开源实现

    工作中,经常会遇到分布式环境中资源访问冲突问题,比如商城的库存数量处理,或者某个事件的原子性操作,都需要确保某个时间段内只有一个线程在访问或处理资源. 因此现在网上也有很多的分布式锁的解决方案,有数据 ...

  2. 基于redis分布式缓存实现

    Redis的复制功能是完全建立在之前我们讨论过的基 于内存快照的持久化策略基础上的,也就是说无论你的持久化策略选择的是什么,只要用到了Redis的复制功能,就一定会有内存快照发生,那么首先要注意你 的 ...

  3. 基于redis分布式缓存实现(新浪微博案例)

    第一:Redis 是什么? Redis是基于内存.可持久化的日志型.Key-Value数据库 高性能存储系统,并提供多种语言的API. 第二:出现背景 数据结构(Data Structure)需求越来 ...

  4. 基于redis分布式缓存实现(新浪微博案例)转

    第一:Redis 是什么? Redis是基于内存.可持久化的日志型.Key-Value数据库 高性能存储系统,并提供多种语言的API. 第二:出现背景 数据结构(Data Structure)需求越来 ...

  5. 基于Redis分布式锁的正确打开方式

    分布式锁是在分布式环境下(多个JVM进程)控制多个客户端对某一资源的同步访问的一种实现,与之相对应的是线程锁,线程锁控制的是同一个JVM进程内多个线程之间的同步.分布式锁的一般实现方法是在应用服务器之 ...

  6. c# 基于redis分布式锁

    在单进程的系统中,当存在多个线程可以同时改变某个变量(可变共享变量)时,就需要对变量或代码块做同步,使其在修改这种变量时能够线性执行消除并发修改变量. 而同步的本质是通过锁来实现的.为了实现多个线程在 ...

  7. 基于 Redis 分布式锁

    1.主流分布式锁实现方案 基于数据库实现分布式锁 基于缓存(redis 等) 基于 Zookeeper 2.根据实现方式分类 : 类 CAS 自旋式分布式锁:询问的方式,类似 java 并发编程中的线 ...

  8. 基于Redis分布式BitMap的应用

    一.序言 在实际开发中常常遇到如下需求:判断当前元素是否存在于已知的集合中,将已知集合中的元素维护一个HashSet,使用时只需耗时O(1)的时间复杂度便可判断出结果,Java内部或者Redis均提供 ...

  9. 多线程编程-- part5.1 互斥锁之公平锁-获取锁

    基本概念 1.AQS:AbstractQueuedSynchronizer类 AQS是java中管理“锁”的抽象类,锁的许多公共方法都是在这个类中实现.AQS是独占锁(例如,ReentrantLock ...

随机推荐

  1. http接口自动化测试框架实现

    一.测试需求描述 对服务后台一系列的http接口功能测试. 输入:根据接口描述构造不同的参数输入值 输出:XML文件 eg:http://xxx.com/xxx_product/test/conten ...

  2. APB总线

    APB(Advance Peripheral Bus)是AMBA总线的一部分,从1998年第一版至今共有3个版本. AMBA 2 APB Specfication:定义最基本的信号interface, ...

  3. Java HTTP通信--Get与POST请求

    一.JDK自带的http通信机制--java.net.URL package com.wjy; import java.io.BufferedReader; import java.io.Buffer ...

  4. C++提供了四个转换运算符

    const_cast <new_type> (expression) static_cast <new_type> (expression) reinterpret_cast ...

  5. 2D 2 3D 开源项目

    http://www.cvlibs.net/projects.php http://www.cvlibs.net/software/libelas/

  6. jackson 常用注解,比如忽略某些属性,驼峰和下划线互转

    一般情况下使用JSON只使用了java对象与字符串的转换,但是,开发APP时候,我们经常使用实体类来做转换:这样,就需要用到注解: Jackson默认是针对get方法来生成JSON字符串的,可以使用注 ...

  7. (GO_GTD_3)基于OpenCV和QT,建立Android图像处理程序

    一.解决权限问题     图片采集了,处理了,如何保存?最直接的方法是使用imwrite,但是如果现在直接使用的话,比如会出现这样或那样的错误,因为我们现在是在android的环境下进行图像处理,所以 ...

  8. duilib中edit获得鼠标焦点后右边框被覆盖

    转载:http://www.cnblogs.com/minggong/p/6457734.html 用duilib做了一个窗口,窗口内有一个供用户输入使用的是edit控件. XML中是这样写的: &l ...

  9. deepin linux java开发环境搭建全系列

    一.jdk安装 下载并解压到Java文件,这个文件是我自己放的位置 配置环境变量 第一次使用终端需要设置管理员密码 之后开始设置环境变量 sudo vim /etc/profile :wq 保存并退出 ...

  10. AS不能在手机上现在调试软件

    这两天遇到的一个问题,(android studio2.0以上的版本),在在线调试应用的时候,将手机上的此程序卸载了,然后准备重新再AS中将这个程序推送到手机上,可是这时候发现不能推送,Log显示什么 ...