Redis上实现分布式锁以提高性能的方案研究

背景:

在很多互联网产品应用中,有些场景需要加锁处理,比如:秒杀,全局递增ID,楼层生成等等。大部分是解决方案基于DB实现的,Redis为单进程单线程模式,采用队列模式将并发访问变成串行访问,且多客户端对Redis的连接并不存在竞争关系。

项目实践

任务队列用到分布式锁的情况比较多,在将业务逻辑中可以异步处理的操作放入队列,在其他线程中处理后出队,此时队列中使用了分布式锁,保证入队和出队的一致性。关于redis队列这块的逻辑分析,我将在下一次对其进行总结,此处先略过。

接下来对redis实现的分布式锁的逻辑代码进行详细的分析和理解:

1、为避免特殊原因导致锁无法释放, 在加锁成功后, 锁会被赋予一个生存时间(通过 lock 方法的参数设置或者使用默认值), 超出生存时间锁将被自动释放.

2、锁的生存时间默认比较短(秒级, 具体见 lock 方法), 因此若需要长时间加锁, 可以通过 expire 方法延长锁的生存时间为适当的时间. 比如在循环内调用 expire
3、系统级的锁当进程无论因为任何原因出现crash,操作系统会自己回收锁,所以不会出现资源丢失。
4、但分布式锁不同。若一次性设置很长的时间,一旦由于各种原因进程 crash 或其他异常导致 unlock 未被调用,则该锁在剩下的时间就变成了垃圾锁,导致其他进程或进程重启后无法进入加锁区域。

<?php

require_once 'RedisFactory.php';

/**
* 在 Redis 上实现的分布式锁
*/
class RedisLock {

//单例模式
  private static $_instance = null;
  public static function instance() {
    if(self::$_instance == null) {
      self::$_instance = new RedisLock();
    }
    return self::$_instance;
  }

//redis对象变量
  private $redis;

//存放被锁的标志名的数组
  private $lockedNames = array();

  public function __construct() {

//获取一个 RedisString 实例
    $this->redis = RedisFactory::instance()->getString();
  }

/** 

* 加锁

*

* @param string 锁的标识名

* @param int 获取锁失败时的等待超时时间(秒), 在此时间之内会一直尝试获取锁直到超时. 为 0 表示失败后直接返回不等待

* @param int 当前锁的最大生存时间(秒), 必须大于 0 . 如果超过生存时间后锁仍未被释放, 则系统会自动将其强制释放

* @param int 获取锁失败后挂起再试的时间间隔(微秒)

*/
  public function lock($name, $timeout = 0, $expire = 15, $waitIntervalUs = 100000) {
    if(empty($name)) return false;

    $timeout = (int)$timeout;
    $expire = max((int)$expire, 5);
    $now = microtime(true);
    $timeoutAt = $now + $timeout;
    $expireAt = $now + $expire;

    $redisKey = "Lock:$name";
    while(true) {
      $result = $this->redis->setnx($redisKey, (string)$expireAt);
      if($result !== false) {

//对$redisKey设置生存时间
        $this->redis->expire($redisKey, $expire);

//将最大生存时刻记录在一个数组里面
        $this->lockedNames[$name] = $expireAt;
        return true;
      }

//以秒为单位,返回$redisKey 的剩余生存时间
      $ttl = $this->redis->ttl($redisKey);

// TTL 小于 0 表示 key 上没有设置生存时间(key 不会不存在, 因为前面 setnx 会自动创建)

// 如果出现这种情况, 那就是进程在某个实例 setnx 成功后 crash 导致紧跟着的 expire 没有被调用. 这时可以直接设置 expire 并把锁纳为己用
      if($ttl < 0) {
        $this->redis->set($redisKey, (string)$expireAt, $expire);
        $this->lockedNames[$name] = $expireAt;
        return true;
      }

// 设置了不等待或者已超时
      if($timeout <= 0 || microtime(true) > $timeoutAt) break;

// 挂起一段时间再试
      usleep($waitIntervalUs);
    }

    return false;
  }

/**

* 给当前锁增加指定的生存时间(秒), 必须大于 0

*

* @param string 锁的标识名

* @param int 生存时间(秒), 必须大于 0

*/
  public function expire($name, $expire) {
    if($this->isLocking($name)) {
      if($this->redis->expire("Lock:$name", max($expire, 1))) {
        return true;
      }
    }
    return false;
  }

/**

* 判断当前是否拥有指定名称的锁

*

* @param mixed $name

*/
  public function isLocking($name) {
    if(isset($this->lockedNames[$name])) {
      return (string)$this->lockedNames[$name] == (string)$this->redis->get("Lock:$name");
    }
    return false;
  }

/**

* 释放锁

*

* @param string 锁的标识名

*/
  public function unlock($name) {
    if($this->isLocking($name)) {
      if($this->redis->deleteKey("Lock:$name")) {
        unset($this->lockedNames[$name]);
        return true;
      }
    }
    return false;
  }

/** 释放当前已经获取到的所有锁 */
  public function unlockAll() {
    $allSuccess = true;
    foreach($this->lockedNames as $name => $item) {
      if(false === $this->unlock($name)) {
        $allSuccess = false;
      }
    }
    return $allSuccess;
  }
}

此类很多代码都写上了注释,只要认真理解下,就很容易懂得如何在redis实现分布式锁了。

(0)

相关推荐

  • redis中使用java脚本实现分布式锁

    redis被大量用在分布式的环境中,自然而然分布式环境下的锁如何解决,立马成为一个问题.例如我们当前的手游项目,服务器端是按业务模块划分服务器的,有应用服,战斗服等,但是这两个vm都有可能同时改变玩家的属性,这如果在同一个vm下面,就很容易加锁,但如果在分布式环境下就没那么容易了,当然利用redis现有的功能也有解决办法,比如redis的脚本. redis在2.6以后的版本中增加了Lua脚本的功能,可以通过eval命令,直接在RedisServer环境中执行Lua脚本,并且可以在Lua脚本中调用

  • redisson实现分布式锁原理

    Redisson分布式锁 之前的基于注解的锁有一种锁是基本redis的分布式锁,锁的实现我是基于redisson组件提供的RLock,这篇来看看redisson是如何实现锁的. 不同版本实现锁的机制并不相同 引用的redisson最近发布的版本3.2.3,不同的版本可能实现锁的机制并不相同,早期版本好像是采用简单的setnx,getset等常规命令来配置完成,而后期由于redis支持了脚本Lua变更了实现原理. <dependency> <groupId>org.redisson&

  • 详细解读分布式锁原理及三种实现方式

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

  • 基于Redis实现分布式锁以及任务队列

    一.前言 双十一刚过不久,大家都知道在天猫.京东.苏宁等等电商网站上有很多秒杀活动,例如在某一个时刻抢购一个原价1999现在秒杀价只要999的手机时,会迎来一个用户请求的高峰期,可能会有几十万几百万的并发量,来抢这个手机,在高并发的情形下会对数据库服务器或者是文件服务器应用服务器造成巨大的压力,严重时说不定就宕机了,另一个问题是,秒杀的东西都是有量的,例如一款手机只有10台的量秒杀,那么,在高并发的情况下,成千上万条数据更新数据库(例如10台的量被人抢一台就会在数据集某些记录下 减1),那次这个

  • Redis上实现分布式锁以提高性能的方案研究

    背景: 在很多互联网产品应用中,有些场景需要加锁处理,比如:秒杀,全局递增ID,楼层生成等等.大部分是解决方案基于DB实现的,Redis为单进程单线程模式,采用队列模式将并发访问变成串行访问,且多客户端对Redis的连接并不存在竞争关系. 项目实践 任务队列用到分布式锁的情况比较多,在将业务逻辑中可以异步处理的操作放入队列,在其他线程中处理后出队,此时队列中使用了分布式锁,保证入队和出队的一致性.关于redis队列这块的逻辑分析,我将在下一次对其进行总结,此处先略过. 接下来对redis实现的分

  • Redis Template实现分布式锁的实例代码

    前言 分布式锁一般有三种实现方式:1. 数据库乐观锁:2. 基于Redis的分布式锁:3. 基于ZooKeeper的分布式锁.本篇博客将介绍第二种方式,基于Redis实现分布式锁.虽然网上已经有各种介绍Redis分布式锁实现的博客,然而他们的实现却有着各种各样的问题,为了避免误人子弟,本篇博客将详细介绍如何正确地实现Redis分布式锁. 可靠性 首先,为了确保分布式锁可用,我们至少要确保锁的实现同时满足以下四个条件: 1.互斥性.在任意时刻,只有一个客户端能持有锁. 2.不会发生死锁.即使有一个

  • Redis如何实现分布式锁详解

    一.前言 在Java的并发编程中,我们通过锁,来避免由于竞争而造成的数据不一致问题.通常,我们以synchronized .Lock来使用它. 但是Java中的锁,只能保证在同一个JVM进程内中执行.如果在分布式集群环境下,就需要分布式锁了. 通常的分布式锁的实现方式有redis,zookeeper,但是一般我们的程序中都会用到redis,用redis做分布式锁,也能够降低成本. 二.实现原理 2.1 加锁 加锁实际上就是在redis中,给Key键设置一个值,为避免死锁,并给定一个过期时间. 在

  • Redis如何实现分布式锁

    目录 一.前言 二.正文 今天我们来聊一聊分布式锁的那些事. 相信大家对锁已经不陌生了,我们在多线程环境中,如果需要对同一个资源进行操作,为了避免数据不一致,我们需要在操作共享资源之前进行加锁操作.在计算机科学中,锁(lock)或互斥(mutex)是一种同步机制,用于在有许多执行线程的环境中强制对资源的访问限制. 比如你去相亲,发现你和一大哥同时和一个女的相亲,那怎么行呢...,搞不好还要被揍一顿. 那什么是分布式锁呢.当多个客户端需要争抢锁时,我们就需要分布式锁.这把锁不能是某个客户端本地的锁

  • Redis的setNX分布式锁超时时间失效 -1问题及解决

    目录 Redis setNX分布式锁超时时间失效 -1 使用SETNX加锁 使用 RedisTemplate 操作Redis 解决死锁 Redis分布式锁,超时问题的处理 分布式可能会出现的超时问题 总结 Redis setNX分布式锁超时时间失效 -1 使用SETNX加锁 加锁的思路: 如果 key 不存在,将 key 设置为 value,如果 key 已存在,则 SETNX 不做任何动作. 使用 RedisTemplate 操作Redis     @Autowired     private

  • Java分布式锁的三种实现方案

    方案一:数据库乐观锁 乐观锁通常实现基于数据版本(version)的记录机制实现的,比如有一张红包表(t_bonus),有一个字段(left_count)记录礼物的剩余个数,用户每领取一个奖品,对应的left_count减1,在并发的情况下如何要保证left_count不为负数,乐观锁的实现方式为在红包表上添加一个版本号字段(version),默认为0. 异常实现流程 -- 可能会发生的异常情况 -- 线程1查询,当前left_count为1,则有记录 select * from t_bonus

  • 浅谈分布式锁的几种使用方式(redis、zookeeper、数据库)

    Q:一个业务服务器,一个数据库,操作:查询用户当前余额,扣除当前余额的3%作为手续费 synchronized lock dblock Q:两个业务服务器,一个数据库,操作:查询用户当前余额,扣除当前余额的3%作为手续费 分布式锁 我们需要怎么样的分布式锁? 可以保证在分布式部署的应用集群中,同一个方法在同一时间只能被一台机器上的一个线程执行. 这把锁要是一把可重入锁(避免死锁) 这把锁最好是一把阻塞锁(根据业务需求考虑要不要这条) 这把锁最好是一把公平锁(根据业务需求考虑要不要这条) 有高可用

  • Redis实现分布式锁的方法示例

    之前我们使用的定时任务都是只部署在了单台机器上,为了解决单点的问题,为了保证一个任务,只被一台机器执行,就需要考虑锁的问题,于是就花时间研究了这个问题.到底怎样实现一个分布式锁呢? 锁的本质就是互斥,保证任何时候能有一个客户端持有同一个锁,如果考虑使用redis来实现一个分布式锁,最简单的方案就是在实例里面创建一个键值,释放锁的时候,将键值删除.但是一个可靠完善的分布式锁需要考虑的细节比较多,我们就来看看如何写一个正确的分布式锁. 单机版分布式锁 SETNX 所以我们直接基于 redis 的 s

  • Redis实现分布式锁和等待序列的方法示例

    在集群下,经常会因为同时处理发生资源争抢和并发问题,但是我们都知道同步锁 synchronized . cas . ReentrankLock 这些锁的作用范围都是 JVM ,说白了在集群下没啥用.这时我们就需要能在多台 JVM 之间决定执行顺序的锁了,现在分布式锁主要有 redis . Zookeeper 实现的,还有数据库的方式,不过性能太差,也就是需要一个第三方的监管. 背景 最近在做一个消费 Kafka 消息的时候发现,由于线上的消费者过多,经常会遇到,多个机器同时处理一个主键类型的数据

随机推荐