整合Redission

Redission

• Redisson是架设在Redis基础上的一个Java驻内存数据网格（In-Memory Data Grid）。

• Redisson在基于NIO的Netty框架上，生产环境使用分布式锁。

• Redission 充分的利用了Redis键值数据库提供的一系列优势，基于Java实用工具包中常用接口，为使用者提供了一系列具有分布式特性的常用工具类。使得原本作为协调单机多线程并发程序的工具包获得了协调分布式多机多线程并发系统的能力，大大降低了设计和研发大规模分布式系统的难度。同时结合各富特色的分布式服务，更进一步简化了分布式环境中程序相互之间的协作。

Redisson Jedis Lettuce对比

Redisson

• 优点：

  • 实现了分布式特性和可扩展的 Java 数据结构，适合分布式开发；
  • API线程安全；
  • 基于Netty框架的事件驱动的通信，可异步调用。

• 缺点：

  • API更抽象，学习使用成本高。

Jedis

• 优点：

  • 提供了比较全面的Redis操作特性的API
  • API基本与Redis的指令一一对应，使用简单易理解。

• 缺点:

  • 同步阻塞IO；
  • 不支持异步；
  • 线程不安全。

Lettuce

• 优点：

  • 线程安全;
  • 基于Netty 框架的事件驱动的通信，可异步调用;
  • 适用于分布式缓存。

• 缺点：

  • API更抽象，学习使用成本高。

分布式锁

• 在JVM中，多线程并发的情况下，我们可以使用同步锁或synchronized或者ReentrantLock等，保证在同一时间内，只有一个线程能够修改变量或者执行代码块

• 然而对于一个分布式集群的系统而言，单纯的本地锁已经无法解决问题，所以就需要用到分布式锁了，通常我们都会引入三方组件或者服务来解决这个问题，比如数据库、Redis、Zookeeper等。例如：一个定时发布短信的任务，在分布式集群中，我们只需要保证同一个服务节点发送短信即可，避免多个节点重复发给同一个用户。

• 通常来说，分布式锁要保证互斥性、不死锁、可重入等特点。

  • 互斥性指的是对于同一个资源，任意时刻，都只有一个客户端能持有锁。
  • 不死锁指的是必须要有锁超时这种机制，保证在出现问题的时候释放锁，不会出现死锁的问题。
  • 可重入指的是对于同一个线程，可以多次重复加锁。

• 设计要点

  • 正确获得锁，保证有且只有一个进程获取到。
  • 锁的重入性
  • 未获得锁的超时等待/或者直接返回false
  • 正确的释放锁，对比获取锁的是不是自己，如果是自己才可以释放。
  • 过期自动释放，防止进程崩溃，锁得不到释放，造成死锁。
  • 锁的超时处理

如何选择

• 首先，如果对于并发不高并且比较简单的场景，通过数据库乐观锁或者唯一主键的形式就能解决大部分的问题。

• 然后，对于Redis实现的分布式锁来说性能高，自己去实现的话比较麻烦，要解决锁续租、lua脚本、可重入等一系列复杂的问题。

  • 对于单机模式而言，存在单点问题。

  • 对于主从架构或者哨兵模式，故障转移会发生锁丢失的问题，因此产生了红锁，但是红锁的问题也比较多，并不推荐使用，推荐的使用方式是用Redission。

• 但是，不管选择哪种方式，本身对于Redis来说不是强一致性的，某些极端场景下还是可能会存在问题。

• 对于Zookeeper的实现方式而言，本身就是保证数据一致性的，可靠性更高，所以不存在Redis的各种故障转移带来的问题，自己实现也比较简单，但是性能相比Redis稍差。

• 不过，实际中我们当然是有啥用啥，老板说用什么就用什么，我才不管那么多。

实现原理

常见分布式锁方案对比

分类	方案	实现原理	优点	缺点
基于数据库	基于mysql 表唯一索引	1.表增加唯一索引 2.加锁：执行insert语句，若报错，则表明加锁失败 3.解锁：执行delete语句	完全利用DB现有能力，实现简单	1.锁无超时自动失效机制，有死锁风险 2.不支持锁重入，不支持阻塞等待 3.操作数据库开销大，性能不高
基于MongoDB findAndModify原子操作	1.加锁：执行findAndModify原子命令查找document，若不存在则新增 2.解锁：删除document	实现也很容易，较基于MySQL唯一索引的方案，性能要好很多	1.大部分公司数据库用MySQL，可能缺乏相应的MongoDB运维、开发人员 2.锁无超时自动失效机制
基于分布式协调系统	基于ZooKeeper	1.加锁：在/lock目录下创建临时有序节点，判断创建的节点序号是否最小。若是，则表示获取到锁；否，则则watch /lock目录下序号比自身小的前一个节点 2.解锁：删除节点	1.由zk保障系统高可用 2.Curator框架已原生支持系列分布式锁命令，使用简单	需单独维护一套zk集群，维保成本高
基于缓存	基于redis命令	1. 加锁：执行setnx，若成功再执行expire添加过期时间 2. 解锁：执行delete命令	实现简单，相比数据库和分布式系统的实现，该方案最轻，性能最好	1.setnx和expire分2步执行，非原子操作；若setnx执行成功，但expire执行失败，就可能出现死锁 2.delete命令存在误删除非当前线程持有的锁的可能 3.不支持阻塞等待、不可重入
基于redis Lua脚本能力	1. 加锁：执行SET lock_name random_value EX seconds NX 命令 2. 解锁：执行Lua脚本，释放锁时验证random_value – ARGV[1]为random_value, KEYS[1]为lock_nameif redis.call(“get”, KEYS[1]) == ARGV[1] then return redis.call(“del”,KEYS[1])else return 0end	同上；实现逻辑上也更严谨，除了单点问题，生产环境采用用这种方案，问题也不大。	不支持锁重入，不支持阻塞等待

数据库方式

• 数据库的话可以使用乐观锁或者悲观锁的实现方式。
• 乐观锁通常就是数据库中我们会有一个版本号，更新数据的时候通过版本号来更新，这样的话效率会比较高
• 悲观锁则是通过for update的方式，但是会带来很多问题，因为他是一个行级锁，高并发的情况下可能会导致死锁、客户端连接超时等问题，一般不推荐使用这种方式。

redis

• Redis是通过set命令来实现，在2.6.2版本之前，实现方式可能是这样：

  sexNX(key, value);
  expire(key, seconds);

• setNX 命令代表当key不存在时返回成功，否则返回失败。

• 但是这种实现方式把加锁和设置过期时间的步骤分成两步，他们并不是原子操作，如果加锁成功之后程序崩溃、服务宕机等异常情况，导致没有设置过期时间，那么就会导致死锁的问题，其他线程永远都无法获取这个锁。

• 之后的版本中，Redis提供了原生的set命令，相当于两命令合二为一，不存在原子性的问题，当然也可以通过lua脚本来解决。set命令如下格式：

  set key value NX EX 10
  # key 为分布式锁的key
  # value 为分布式锁的值，一般为不同的客户端设置不同的值
  # NX 代表如果要设置的key已存在，则取消设置
  # EX 代表过期时间为秒，PX则为毫秒，比如上面示例中为10秒过期

set方式的问题

• 虽然set解决了原子性的问题，但是还是会存在两个问题。

• 锁超时问题

  • 比如客户端A加锁同时设置超时时间是3秒，结果3s之后程序逻辑还没有执行完成，锁已经释放。客户端B此时也来尝试加锁，那么客户端B也会加锁成功。这样的话，就导致了并发的问题，如果代码幂等性没有处理好，就会导致问题产生。

    

• 锁误删除

  • 还是类似的问题，客户端A加锁同时设置超时时间3秒，结果3s之后程序逻辑还没有执行完成，锁已经释放。客户端B此时也来尝试加锁，这时客户端A代码执行完成，执行释放锁，结果释放了客户端B的锁。

    

解决方案

• 锁超时问题，有两个解决方案。

  1. 针对锁超时的问题，我们可以根据平时业务执行时间做大致的评估，然后根据评估的时间设置一个较为合理的超时时间，这样能一大部分程度上避免问题。
  2. 自动续租，通过其他的线程为将要过期的锁延长持有时间

• 锁误删除

  • 每个客户端的锁只能自己解锁，一般我们可以在使用set命令的时候生成随机的value，解锁使用lua脚本判断当前锁是否自己持有的，是自己的锁才能释放。

    #加锁
    SET key random_value NX EX 10
    #解锁
    if redis.call("get",KEYS[1]) == ARGV[1] then
        return redis.call("del",KEYS[1])
    else
        return 0
    end

Zookeeper方式

• 通过创建临时顺序节点的方式来实现。

  

1. 当需要对资源进行加锁时，实际上就是在父节点之下创建一个临时顺序节点。
2. 客户端A来对资源加锁，首先判断当前创建的节点是否为最小节点，如果是，那么加锁成功，后续加锁线程阻塞等待
3. 此时，客户端B也来尝试加锁，由于客户端A已经加锁成功，所以客户端B发现自己的节点并不是最小节点，就会去取到上一个节点，并且对上一节点注册监听
4. 当客户端A操作完成，释放锁的操作就是删除这个节点，这样就可以触发监听事件，客户端B就会得到通知，同样，客户端B判断自己是否为最小节点，如果是，那么则加锁成功

RedLock算法

• 因为在Redis的主从架构下，主从同步是异步的，如果在Master节点加锁成功后，指令还没有同步到Slave节点，此时Master挂掉，Slave被提升为Master，新的Master上并没有锁的数据，其他的客户端仍然可以加锁成功。

• 对于这种问题，Redis作者提出了RedLock红锁的概念。

• RedLock的理念下需要至少2个Master节点，多个Master节点之间完全互相独立，彼此之间不存在主从同步和数据复制。

• 主要步骤如下：

  1. 获取当前Unix时间

  2. 按照顺序依次尝试从多个节点锁，如果获取锁的时间小于超时时间，并且超过半数的节点获取成功，那么加锁成功。

     • 这样做的目的就是为了避免某些节点已经宕机的情况下，客户端还在一直等待响应结果。

     • 举个例子，假设现在有5个节点，过期时间=100ms，第一个节点获取锁花费10ms，第二个节点花费20ms，第三个节点花费30ms，那么最后锁的过期时间就是100-(10+20+30)，这样就是加锁成功，反之如果最后时间<0，那么加锁失败

  3. 如果加锁失败，那么要释放所有节点上的锁

RedLock缺点

• RedLock存在不少问题，所以现在其实一般不推荐使用这种方式，而是推荐使用Redission的方案，他的问题主要如下几点。

• 性能、资源：因为需要对多个节点分别加锁和解锁，而一般分布式锁的应用场景都是在高并发的情况下，所以耗时较长，对性能有一定的影响。此外因为需要多个节点，使用的资源也比较多，简单来说就是费钱。

• 节点崩溃重启

  • 比如有1~5号五个节点，并且没有开启持久化

    • 客户端A在1，2，3号节点加锁成功，此时3号节点崩溃宕机后发生重启，就丢失了加锁信息，
    • 客户端B在3，4，5号节点加锁成功。

  • 那么，两个客户端A\B同时获取到了同一个锁，问题产生了，怎么解决？

    • Redis作者建议的方式就是延时重启，比如3号节点宕机之后不要立刻重启，而是等待一段时间后再重启，这个时间必须大于锁的有效时间，也就是锁失效后再重启，这种人为干预的措施真正实施起来就比较困难了

    • 第二个方案那么就是开启持久化，但是这样对性能又造成了影响。比如如果开启AOF默认每秒一次刷盘，那么最多丢失一秒的数据，如果想完全不丢失的话就对性能造成较大的影响。

• GC、网络延迟

  • 对于RedLock，Martin Kleppmann提出了很多质疑，我就只举这样一个GC或者网络导致的例子。

  • 文章地址：https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html

  • 从图中我们可以看出，client1线获取到锁，然后发生GC停顿，超过了锁的有效时间导致锁被释放，然后锁被client2拿到，然后两个客户端同时拿到锁在写数据，问题产生。

    

• 时钟跳跃

  • 同样的例子，假设发生网络分区，4、5号节点变为一个独立的子网，3号节点发生始终跳跃（不管人为操作还是同步导致）导致锁过期，这时候另外的客户端就可以从3、4、5号节点加锁成功，问题又发生了。

解决方案

• 比较好的方式是使用Redission，它是一个开源的Java版本的Redis客户端，无论单机、哨兵、集群环境都能支持，另外还很好地解决了锁超时、公平非公平锁、可重入等问题，也实现了RedLock，同时也是官方推荐的客户端版本。

Redission实现原理

加锁、可重入

• 首先，加锁和解锁都是通过lua脚本去实现的，这样做的好处是为了兼容老版本的redis同时保证原子性。

• KEYS[1]为锁的key，ARGV[2]为锁的value，格式为uuid+线程ID，ARGV[1]为过期时间。

• 主要的加锁逻辑也比较容易看懂，如果key不存在，通过hash的方式保存，同时设置过期时间，反之如果存在就是+1。

• 对应的就是hincrby', KEYS[1], ARGV[2], 1这段命令，对hash结构的锁重入次数+1。

  

解锁

1. 如果key都不存在了，那么就直接返回

2. 如果key、field不匹配，那么说明不是自己的锁，不能释放，返回空

3. 释放锁，重入次数-1，如果还大于0那么久刷新过期时间，反之那么久删除锁

   

watchdog

• 也叫做看门狗，也就是解决了锁超时导致的问题，实际上就是一个后台线程，默认每隔10秒自动延长锁的过期时间。

• 默认的时间就是internalLockLeaseTime / 3，internalLockLeaseTime默认为30秒。

  

整合Redisson

• redission官网文档

• springboot与redission

添加Maven依赖

<!-- redisson-springboot -->
<dependency>
    <groupId>org.redisson</groupId>
    <artifactId>redisson-spring-boot-starter</artifactId>
    <version>3.15.4</version>
</dependency>

配置文件

spring:
  redis:
    host: 127.0.0.1
    port: 6379
    database: 0
    timeout: 5000

添加配置类

package tk.fulsun.demo.config;

import org.redisson.Redisson;
import org.redisson.api.RedissonClient;
import org.redisson.config.Config;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.autoconfigure.data.redis.RedisProperties;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;

/**
 * @author fulsun
 * @description: RedissonConfig
 * @date 6/1/2021 10:25 AM
 */
@Configuration
public class RedissonConfig {

  @Autowired private RedisProperties redisProperties;
  /** redisson 连接地址格式 */
  private static final String REDISSON_FORMAT = "redis://%s:%s";

  private String format(String hostname, int port) {
    return String.format(REDISSON_FORMAT, hostname, port);
  }

  private String format(String url) {
    return String.format("redis://%s", url);
  }

  @Bean
  public RedissonClient redissonClient() {
    Config config = new Config();
    String[] addSentinelAddress =
        redisProperties.getSentinel().getNodes().stream()
            .map(i -> format(i))
            .toArray(String[]::new);
    config
        .useSentinelServers()
        .setMasterName(redisProperties.getSentinel().getMaster())
        .setPassword(redisProperties.getPassword())
        .setTimeout(30000)
        .addSentinelAddress(addSentinelAddress);

    // single 模式
    // config
    //     .useSingleServer()
    //     .setAddress(format(factory.getHostName(), factory.getPort()))
    //     .setPassword(factory.getPassword());
    return Redisson.create(config);
  }
}

代码测试(简单的存取)

import org.redisson.api.RedissonClient;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.data.redis.core.StringRedisTemplate;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RequestMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RequestMapping("/redisson")
public class RedissonController {

    @Autowired
    private StringRedisTemplate stringRedisTemplate;

    @GetMapping("/save")
    public String save(){
        stringRedisTemplate.opsForValue().set("key","redisson");
        return "save ok";
    }

    @GetMapping("/get")
    public String get(){
        return stringRedisTemplate.opsForValue().get("key");
    }

}

Redisson 分布式重入锁用法

• Redisson 支持单点模式、主从模式、哨兵模式、集群模式，这里以单点模式为例：

  // 1.构造redisson实现分布式锁必要的Config
  Config config = new Config();
  config.useSingleServer().setAddress("redis://127.0.0.1:5379").setPassword("123456").setDatabase(0);
  // 2.构造RedissonClient
  RedissonClient redissonClient = Redisson.create(config);
  // 3.获取锁对象实例（无法保证是按线程的顺序获取到）
  RLock rLock = redissonClient.getLock(lockKey);
  try {
      /**
       * 4.尝试获取锁
       * waitTimeout 尝试获取锁的最大等待时间，超过这个值，则认为获取锁失败
       * leaseTime   锁的持有时间,超过这个时间锁会自动失效（值应设置为大于业务处理的时间，确保在锁有效期内业务能处理完）
       */
      boolean res = rLock.tryLock((long)waitTimeout, (long)leaseTime, TimeUnit.SECONDS);
      if (res) {
          //成功获得锁，在这里处理业务
      }
  } catch (Exception e) {
      throw new RuntimeException("aquire lock fail");
  }finally{
      //无论如何, 最后都要解锁
      rLock.unlock();
  }