分布式锁简介

是一种用来解决多个执行线程 访问共享资源 错误或数据不一致问题的工具。

如果 把一台服务器比作一个房子,那么 线程就好比里面的住户,当他们想要共同访问一个共享资源,例如厕所的时候,如果厕所门上没有锁…更甚者厕所没装门…这是会出原则性的问题的..

​ 装上了锁,大家用起来就安心多了,本质也就是 同一时间只允许一个住户使用

而随着互联网世界的发展,单体应用已经越来越无法满足复杂互联网的高并发需求,转而慢慢朝着分布式方向发展,慢慢进化成了 更大一些的住户。所以同样,我们需要引入分布式锁来解决分布式应用之间访问共享资源的并发问题。

为什么要使用分布式锁

一般情况下,我们使用分布式锁主要有两个场景:

  1. 避免不同节点重复相同的工作:比如用户执行了某个操作有可能不同节点会发送多封邮件;
  2. 避免破坏数据的正确性:如果两个节点在同一条数据上同时进行操作,可能会造成数据错误或不一致的情况出现;

Java 中实现的常见方式

上面我们用简单的比喻说明了锁的本质:同一时间只允许一个用户操作。所以理论上,能够满足这个需求的工具我们都能够使用 *(就是其他应用能帮我们加锁的)*:

  1. 基于 MySQL 中的锁:MySQL 本身有自带的悲观锁 for update 关键字,也可以自己实现悲观/乐观锁来达到目的;
  2. 基于 Zookeeper 有序节点:Zookeeper 允许临时创建有序的子节点,这样客户端获取节点列表时,就能够当前子节点列表中的序号判断是否能够获得锁;
  3. 基于 Redis 的单线程:由于 Redis 是单线程,所以命令会以串行的方式执行,并且本身提供了像 SETNX(set if not exists) 这样的指令,本身具有互斥性;

每个方案都有各自的优缺点,例如 MySQL 虽然直观理解容易,但是实现起来却需要额外考虑锁超时加事务 等,并且性能局限于数据库,诸如此类我们在此不作讨论,重点关注 Redis。

Redis 分布式锁的问题

锁超时

​ 假设现在我们有两台平行的服务 A B,其中 A 服务在 获取锁之后 由于未知神秘力量突然 挂了,那么 B 服务就永远无法获取到锁了:

image-20210328162040242

所以我们需要额外设置一个超时时间,来保证服务的可用性。

但是另一个问题随即而来:如果在加锁和释放锁之间的逻辑执行得太长,以至于超出了锁的超时限制,也会出现问题。因为这时候第一个线程持有锁过期了,而临界区的逻辑还没有执行完,与此同时第二个线程就提前拥有了这把锁,导致临界区的代码不能得到严格的串行执行。

为了避免这个问题,Redis 分布式锁不要用于较长时间的任务。如果真的偶尔出现了问题,造成的数据小错乱可能就需要人工的干预。

有一个稍微安全一点的方案是 将锁的 value 值设置为一个随机数,释放锁时先匹配随机数是否一致,然后再删除 key,这是为了 确保当前线程占有的锁不会被其他线程释放,除非这个锁是因为过期了而被服务器自动释放的。

但是匹配 value 和删除 key 在 Redis 中并不是一个原子性的操作,也没有类似保证原子性的指令,所以可能需要使用像 Lua 这样的脚本来处理了,因为 Lua 脚本可以 保证多个指令的原子性执行

集群问题

如果 Redis 采用单机部署模式,那就意味着当 Redis 故障了,就会导致整个服务不可用。

而如果采用主从模式部署,我们想象一个这样的场景:服务 A 申请到一把锁之后,如果作为主机的 Redis 宕机了,那么 服务 B 在申请锁的时候就会从从机那里获取到这把锁,为了解决这个问题,Redis 作者提出了一种 RedLock算法

代码实现

@RestController
public class GoodController {

private static final String REDIS_LOCK_KEY = "lockOneby";

@Autowired
private StringRedisTemplate stringRedisTemplate;

@Value("${server.port}")
private String serverPort;

@Autowired
private Redisson redisson;

@GetMapping("/buy_goods")
public String buy_Goods() throws Exception {
// 当前请求的 UUID + 线程名
String value = UUID.randomUUID().toString() + Thread.currentThread().getName();
// 获取锁
RLock redissonLock = redisson.getLock(REDIS_LOCK_KEY);
// 上锁
redissonLock.lock();

try {
// 从 redis 中获取商品的剩余数量
String result = stringRedisTemplate.opsForValue().get("goods:001");
int goodsNumber = result == null ? 0 : Integer.parseInt(result);
String retStr = null;

// 商品数量大于零才能出售
if (goodsNumber > 0) {
int realNumber = goodsNumber - 1;
stringRedisTemplate.opsForValue().set("goods:001", realNumber + "");
retStr = "你已经成功秒杀商品,此时还剩余:" + realNumber + "件" + "\t 服务器端口: " + serverPort;
} else {
retStr = "商品已经售罄/活动结束/调用超时,欢迎下次光临" + "\t 服务器端口: " + serverPort;
}
System.out.println(retStr);
return retStr;
} finally {
// 还在持有锁的状态,并且是当前线程持有的锁再解锁
if (redissonLock.isLocked() && redissonLock.isHeldByCurrentThread()){
redissonLock.unlock();
}
}
}

}

总结

synchronized 锁:单机版 OK,上 nginx分布式微服务,单机锁就不 OK,
分布式锁:取消单机锁,上 redis 分布式锁 SETNX
如果出异常的话,可能无法释放锁, 必须要在 finally 代码块中释放锁
如果宕机了,部署了微服务代码层面根本没有走到 finally 这块,也没办法保证解锁,因此需要有设置锁的过期时间
除了增加过期时间之外,还必须要 SETNX 操作和设置过期时间的操作必须为原子性操作
规定只能自己删除自己的锁,你不能把别人的锁删除了,防止张冠李戴,可使用 lua 脚本或者事务
判断锁所属业务与删除锁的操作也需要是原子性操作
redis 集群环境下,我们自己写的也不 OK,直接上 RedLock 之 Redisson 落地实现