redis分布式锁使用方式

为什么使用锁？

锁的作用是要解决多线程对共享资源的访问而产生的线程安全问题。

当多个线程并发操作某个对象时，可以通过synchronized来保证同一时刻只能有一个线程获取到对象锁进而处理synchronized关键字修饰的代码块或方法。

为什么使用分布式锁？

现在系统基本是分布式部署，一个应用会被部署到多台服务器，synchronized只能控制当前服务器自身的线程安全，并不能跨服务器控制并发安全。

什么是分布式锁？

分布式锁，就是控制分布式系统中不同进程共同访问同一共享资源的一种锁的实现。如果不同系统或同一系统的不同主机之间共享了某个临界资源，往往需要互斥来防止彼此干扰，以保证一致性。

分布式锁的特征

1. 互斥性 ：任意时刻，只有一个客户端能持有锁。
2. 锁超时释放：持有锁超时，可以释放，防止死锁。防止资源浪费。
3. 可重入性：一个线程如果获取了锁之后，可以再次对其请求加锁。
4. 高性能和高可用：加锁和解锁需要开销尽可能低，同时也要保证高可用，避免分布式锁失效。
5. 安全性：锁只能被持有的客户端删除，不能被其他客户端删除。

什么情况下使用分布式锁？

秒杀下单、抢红包等等业务场景，都需要用到分布式锁。而Redis非常适合作为分布式锁使用。

实现分布式锁的方式

• 一：SETNX + EXPIRE
• 二：SETNX + value值是（系统时间+过期时间）
• 三：使用Lua脚本(包含SETNX + EXPIRE两条指令)
• 四：SET的扩展命令（SET EX PX NX）
• 五：SET EX PX NX + 校验唯一随机值,再释放锁
• 六: 开源框架~Redisson
• 七：多机实现的分布式锁Redlock

方式一：SETNX + EXPIRE

setnx来枪锁，抢到之后，用expire给锁设置过期时间。防止锁忘记释放。

setnx是set if not exists的简写。格式 setnx key value，如果key不存在，则setnx成功返回1，如果key已经存在，则返回。

if（jedis.setnx(key_resource_id,lock_value) == 1）{ //加锁
    expire（key_resource_id，100）; //设置过期时间
    try {
        do something  //业务请求
    }catch(){
  }
  finally {
       jedis.del(key_resource_id); //释放锁
    }
}

1
2
3
4
5
6
7
8
9
10
11

缺点：两条命令分开，非原子操作。有可能产生第一条命令执行了，第二条命令因一些原因未执行，而别的线程永远获取不到锁。

方式二：SETNX + value值是(系统时间+过期时间)

可以把过期时间放到setnx的value值里面。如果加锁失败，再拿出value值校验一下即可

long expires = System.currentTimeMillis() + expireTime; //系统时间+设置的过期时间
String expiresStr = String.valueOf(expires);

// 如果当前锁不存在，返回加锁成功
if (jedis.setnx(key_resource_id, expiresStr) == 1) {
        return true;
} 
// 如果锁已经存在，获取锁的过期时间
String currentValueStr = jedis.get(key_resource_id);

// 如果获取到的过期时间，小于系统当前时间，表示已经过期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {

     // 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间（不了解redis的getSet命令的小伙伴，可以去官网看下哈）
    String oldValueStr = jedis.getSet(key_resource_id, expiresStr);
    
    if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
         // 考虑多线程并发的情况，只有一个线程的设置值和当前值相同，它才可以加锁
         return true;
    }
}
        
//其他情况，均返回加锁失败
return false;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

优点：原子性

缺点：

• 过期时间是客户端自己生成的（System.currentTimeMillis()是当前系统的时间），必须要求分布式环境下，每个客户端的时间必须同步。
• 如果锁过期的时候，并发多个客户端同时请求过来，都执行jedis.getSet()，最终只能有一个客户端加锁成功，但是该客户端锁的过期时间，可能被别的客户端覆盖
• 该锁没有保存持有者的唯一标识，可能被别的客户端释放/解锁。

方式三：使用Lua脚本（包含SETNX + EXPIRE两条指令）

if redis.call('setnx',KEYS[1],ARGV[1]) == 1 then
   redis.call('expire',KEYS[1],ARGV[2])
else
   return 0
end;
1
2
3
4
5

方式四：set的扩展命令（set ex px nx）

SET key value[EX seconds][PX milliseconds][NX|XX]

• NX :表示key不存在的时候，才能set成功，也即保证只有第一个客户端请求才能获得锁，而其他客户端请求只能等其释放锁，才能获取。
• EX seconds :设定key的过期时间，时间单位是秒。
• PX milliseconds: 设定key的过期时间，单位为毫秒
• XX: 仅当key存在时设置值

if（jedis.set(key_resource_id, lock_value, "NX", "EX", 100s) == 1）{ //加锁
    try {
        do something  //业务处理
    }catch(){
  }
  finally {
       jedis.del(key_resource_id); //释放锁
    }
}

1
2
3
4
5
6
7
8
9
10

优点：原子性

缺点：

• 问题一：「锁过期释放了，业务还没执行完」。假设线程a获取锁成功，一直在执行临界区的代码。但是100s过去后，它还没执行完。但是，这时候锁已经过期了，此时线程b又请求过来。显然线程b就可以获得锁成功，也开始执行临界区的代码。那么问题就来了，临界区的业务代码都不是严格串行执行的啦。

• 问题二：「锁被别的线程误删」。假设线程a执行完后，去释放锁。但是它不知道当前的锁可能是线程b持有的（线程a去释放锁时，有可能过期时间已经到了，此时线程b进来占有了锁）。那线程a就把线程b的锁释放掉了，但是线程b临界区业务代码可能都还没执行完呢。

  方式五：SET EX PX NX + 校验唯一随机值,再删除

  if（jedis.set(key_resource_id, uni_request_id, "NX", "EX", 100s) == 1）{ //加锁
      try {
          do something  //业务处理
      }catch(){
    }
    finally {
         //判断是不是当前线程加的锁,是才释放
         if (uni_request_id.equals(jedis.get(key_resource_id))) {
          jedis.del(lockKey); //释放锁
          }
      }
  }
  
  1
  2
  3
  4
  5
  6
  7
  8
  9
  10
  11
  12
  13

  在这里，**「判断是不是当前线程加的锁」和「释放锁」**不是一个原子操作。如果调用jedis.del()释放锁的时候，可能这把锁已经不属于当前客户端，会解除他人加的锁。可以使用lua脚本代替

  if redis.call('get',KEYS[1]) == ARGV[1] then 
     return redis.call('del',KEYS[1]) 
  else
     return 0
  end;
  
  1
  2
  3
  4
  5
  6

  稍微把锁过期时间设置长一些就可以啦。其实我们设想一下，是否可以给获得锁的线程，开启一个定时守护线程，每隔一段时间检查锁是否还存在，存在则对锁的过期时间延长，防止锁过期提前释放。

  方案六：Redisson框架

只要线程一加锁成功，就会启动一个watch dog看门狗，它是一个后台线程，会每隔10秒检查一下，如果线程1还持有锁，那么就会不断的延长锁key的生存时间。因此，Redisson就是使用Redisson解决了**「锁过期释放，业务没执行完」**问题。