三种分布式锁的实现方式

最新推荐文章于 2024-04-26 00:14:47 发布

听风听雨听世界

最新推荐文章于 2024-04-26 00:14:47 发布

阅读量91

点赞数

分类专栏： blog 文章标签：分布式 java 后端

blog 专栏收录该内容

45 篇文章 0 订阅

订阅专栏

文章目录

前言
- 什么是分布式锁
分布式锁的特性
分类
- 自旋方式
- 监听方式
实现方式
总结

前言

全文字数 : 1W+
⏳ 阅读时长 : 15min
关键词 : 分布式锁、Redis、ZooKeeper
作者：小许code
转载：https://zhuanlan.zhihu.com/p/642030393

今天我们讲讲分布式锁，网上相关的内容有很多，但是比较分散，刚好自己刚学习完总结下，分享给大家，文章内容会比较多，我们先从思维导图中了解要讲的内容。

什么是分布式锁

分布式锁是控制分布式系统之间同步访问共享资源的一种方式，通过互斥来保持一致性。

了解分布式锁之前先了解下线程锁和进程锁：

线程锁：主要用来给方法、代码块加锁。当某个方法或代码使用锁，在同一时刻仅有一个线程执行该方法或该代码段。线程锁只在同一JVM中有效果，因为线程锁的实现在根本上是依靠线程之间共享内存实现的，比如Synchronized、Lock等

进程锁：控制同一操作系统中多个进程访问某个共享资源，因为进程具有独立性，各个进程无法访问其他进程的资源，因此无法通过synchronized等线程锁实现进程锁

比如Golang语言中的sync包就提供了基本的同步基元，如互斥锁

但是以上两种适合在单体架构应用，但是分布式系统中多个服务节点，多个进程分散部署在不同节点机器中，此时对于资源的竞争，上诉两种对节点本地资源的锁就无效了。

这个时候就需要分布式锁来对分布式系统多进程访问资源进行控制，因此分布式锁是为了解决分布式互斥问题！

分布式锁的特性

互斥

互斥性很好理解，这也是最基本功能，就是在任意时刻，只能有一个客户端才能获取锁，不能同时有两个客户端获取到锁。

避免死锁

为什么会出现死锁，因为获取锁的客户端因为某些原因(如down机等)而未能释放锁，其它客户端再也无法获取到该锁，从而导致整个流程无法继续进行。

面对这种情况，当然有解决办法啦！

引入过期时间：通常情况下我们会设置一个 TTL(Time To Live，存活时间) 来避免死锁，但是这并不能完全避免。

比如TTL为5秒，进程A获得锁
问题是5秒内进程A并未释放锁，被系统自动释放，进程B获得锁
刚好第6秒时进程A执行完，又会释放锁，也就是进程A释放了进程B的锁

仅仅加个过期时间会设计到两个问题：锁过期和释放别人的锁问题

锁附加唯一性：针对释放别人锁这种问题，我们可以给每个客户端进程设置【唯一ID】，这样我们就可以在应用层就进行检查唯一ID。

自动续期：锁过期问题的出现，是我们对持有锁的时间不好进行预估，设置较短的话会有【提前过期】风险，但是过期时间设置过长，可能锁长时间得不到释放。

这种情况同样有处理方式，可以开启一个守护进程（watch dog）,检测失效时间进行续租，比如Java技术栈可以用Redisson来处理。

可重入：

一个线程获取了锁，但是在执行时，又再次尝试获取锁会发生什么情况？

是的，导致了重复获取锁，占用了锁资源，造成了死锁问题。

我们了解下什么是【可重入】：指的是同一个线程在持有锁的情况下，可以多次获取该锁而不会造成死锁，也就是一个线程可以在获取锁之后再次获取同一个锁，而不需要等待锁释放。

解决方式：比如实现Redis分布式锁的可重入，在实现时，需要借助Redis的Lua脚本语言，并使用引用计数器技术，保证同一线程可重入锁的正确性。

容错

容错性是为了当部分节点(redis节点等)宕机时，客户端仍然能够获取锁和释放锁，一般来说会有以下两种处理方式：

一种像etcd/zookeeper这种作为锁服务能够自动进行故障切换，因为它本身就是个集群，另一种可以提供多个独立的锁服务，客户端向多个独立锁服务进行请求，某个锁服务故障时，也可以从其他服务获取到锁信息，但是这种缺点很明显，客户端需要去请求多个锁服务。

实现方式

分布式锁的实现方式有数据库、基于Redis缓存、ZooKeeper、Etcd等，文章主要从这几种实现方式并结合问题的方式展开叙述！

基于MySQL

利用数据库表来实现实现分布式锁，是不是感觉有点疑惑，是的，我再写之前收集资料的时候也有点疑问，虽然这种方式我们并不推崇，但是我们也可以作为一个方案来进行了解，我们看看到底怎么做的：

比如在数据库中创建一个表，表中包含方法名等字段，并在方法名name字段上创建唯一索引，想要执行某个方法，就使用这个方法名向表中插入一条记录，成功插入则获取锁，删除对应的行就是锁释放。

//锁记录表
CREATE TABLE `lock_info` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT COMMENT '主键',
  `name` varchar(64) NOT NULL COMMENT '方法名',
  PRIMARY KEY (`id`),
  UNIQUE KEY `idx_name` (`method_name`) 
) ENGINE=InnoD

这里主要是用name字段作为唯一索引来实现，唯一索引保证了该记录的唯一性，锁释放就直接删掉该条记录就行了。

缺点也很多：

数据库是单点，非常依赖数据库的可用性
需要额外自己维护TTL
在高并发常见下数据库读写是非常缓慢

这里我们就不用过多的文字了，现实中我们更多的是用基于内存存储来实现分布式锁。

基于Redis

面试官问：你了解分布式锁吗？想必绝大部分面试者都会说关于Redis实现分布式锁的方式，OK，进入正题【基于Redis分布式锁】

Redis 的分布式锁， setnx 命令并设置过期时间就行吗？

setnx lkey lvalue expire lockKey 30

正常情况下是可以的，但是这里有个问题，虽然setnx是原子性的，但是setnx + expire就不是了，也就是说setnx和expire是分两步执行的，【加锁和超时】两个操作是分开的，如果expire执行失败了，那么锁同样得不到释放。

关于为什么要加锁和超时时间的设定在文章开头【避免死锁】有提到，不明白的可以多看看。

Redis正确的加锁命令是什么？

//保证原子性执行命令
SET lKey randId NX PX 30000

randId是由客户端生成的一个随机字符串，该客户端加锁时具有唯一性，主要是为了避免释放别人的锁。

我们来看这么一样流程，如下图：

Client1 获取锁成功。
由于Client1 业务处理时间过长，锁过期时间到了，锁自动释放了
Client2 获取到了对应同一个资源的锁。
Client1 业务处理完成，释放锁，但是释放掉了Client2 持有的锁。
而Client3此时还能获得锁，同样Client2此时持有锁，都乱套了。

而这个randId就可以在释放锁的时候避免了释放别人的锁，因为在释放锁的时候，Client需要先获取到该锁的值（randId）,判断是否相同后才能删除。

if (redis.get(lKey).equals(randId)) {
    redis.del(lockKey);
}

加锁的时候需要原子性，释放锁的时候该怎么做到原子性？

这个问题很好，我们在加锁的时候通过原子性命令避免了潜在的设置过期时间失败问题，释放锁同样是Get + Del两条命令，这里同样存在释放别人锁的问题。

脑瓜嗡嗡的，咋那么多需要考虑的问题呀，看累了休息会，咋们继续往下看！

这里问题的根源在于：锁的判断在客户端，释放在服务端，如下图：

所以应该将锁的判断和删除都在redis服务端进行，可以借助lua脚本保证原子性，释放锁的核心逻辑【GET、判断、DEL】，写成 Lua 脚，让Redis执行，这样实现能保证这三步的原子性。

// 判断锁是自己的，才释放
if redis.call("GET",KEYS[1]) == ARGV[1]
then
    return redis.call("DEL",KEYS[1])
else
    return 0
end

如果Client1获取到锁后，因为业务问题需要较长的处理时间，超过了锁过期时间，该怎么办？

既然业务执行时间超过了锁过期时间，那么我们可以给锁续期呀，比如开启一个守护进程，定时监测锁的失效时间，在快要过期的时候，对锁进行自动续期，重新设置过期时间。

Redisson框架中就实现了这个，就要WatchDog（看门狗）:加锁时没有指定加锁时间时会启用 watchdog 机制，默认加锁 30 秒，每 10 秒钟检查一次，如果存在就重新设置过期时间为 30 秒（即 30 秒之后它就不再续期了）

嗯嗯，这应该就比较稳健了吧！

嘿嘿，以上这些都是锁在「单个」Redis 实例中可能产生的问题，确实单节点分布式锁能解决大部分人的需求。但是通常都是用【Redis Cluster】或者【哨兵模式】这两种方式实现 Redis 的高可用，这就有主从同步问题发生。

试想这样的场景：

Client1请求Master加锁成功
然而Master异常宕机，加锁信息还未同步到从库上（主从复制是异步的）
此时从库Slave1被哨兵提升为新主库，锁信息不在新的主库上（未同步到Slave1）

面对这种问题，Redis 的作者提出一种解决方 Redlock，是基于多个 Redis 节点（都是 Master）的一种实现，该方案基于 2 个前提：

不再需要部署从库和哨兵实例，只部署主库
但主库要部署多个，官方推荐至少 5 个实例

Redlock加锁流程：

Client先获取「当前时间戳T1」
Client依次向这 5 个 Redis 实例发起加锁请求（用前面讲到的 SET 命令），且每个请求会设置超时时间（毫秒级，要远小于锁的有效时间），如果某一个实例加锁失败（包括网络超时、锁被其它人持有等各种异常情况），就立即向下一个 Redis 实例申请加锁
如果Client从 >=3 个（大多数）以上 Redis 实例加锁成功，则再次获取「当前时间戳T2」，如果 T2 - T1 < 锁的过期时间，此时，认为客户端加锁成功，否则认为加锁失败
加锁成功，去操作共享资源（例如修改 MySQL 某一行，或发起一个 API 请求）
加锁失败，Client向「全部节点」发起释放锁请求（前面讲到的 Lua 脚本释放锁）

Redlock释放锁:

客户端向所有 Redis 节点发起释放锁的操作