写点什么

一文详解如何用 MySQL/Redis/ZooKeeper 实现分布式锁

作者:一灯架构
  • 2022-10-18
    北京
  • 本文字数:3306 字

    阅读完需:约 1 分钟

一个挺着啤酒肚,身穿格子衫,发际线严重后移的中年男子,手拿着保温杯,胳膊夹着 MacBook 向你走来,看样子是架构师级别。



面试开始, 直入正题。


面试官: 你有没有参与过秒杀系统的设计?


我: 没有,我平时都是开发后台管理系统、OA 办公系统、内部管理系统,从来没有开发过秒杀系统。


面试官: 嗯...,小伙子很实诚。今天就先到这里吧,后面有消息会主动联系你。


后面还可能有消息吗?你们啥时候主动联系过我?实话实说的被拒,八股文背的溜反而被录取。好吧,等我看看一灯怎么总结的秒杀系统的八股文。


我: 参与过秒杀系统,并独立负责过秒杀系统的架构设计(【狗头】是的,都是我设计的)。


面试官: 这样才对,这样我才能接着往下问。你在设计秒杀系统的时候,怎么防止商品超卖?比如活动中只有一台 iPhone,最终卖出 100 台,肯定不行,平台要亏钱。


我: 肯定要加锁,不过由于秒杀系统请求量较大,一般使用分布式集群。而 Java 自带 Synchronized、ReentrantLock 锁只能用在单机系统中,这时候就需要用到分布式锁。


面试官: 你提到分布式锁,分布式锁都有哪些作用?


八股文这就开始了。


我:我觉得分布式锁主要有两个作用:


保证数据的正确性:比如:秒杀的时候防止商品超卖,表单重复提交,接口幂等性。


避免数据重复处理:比如:调度任务在多台机器重复执行,缓存过期所有请求都去加载数据库。


总结八股文,还得是一灯。


面试官: 小伙子总结的挺全,你知道设计一个分布式锁,要具有哪些特性?


我: 我觉得分布式锁要具有以下这些特性:


互斥:同一时刻只能有一个线程获得锁。可重入:当一个线程获取锁后,还可以再次获取这个锁,避免死锁发生。高可用:当小部分节点挂掉后,仍然能够对外提供服务。高性能:要做到高并发、低延迟。支持阻塞和非阻塞:Synchronized 是阻塞的,ReentrantLock.tryLock()就是非阻塞的支持公平锁和非公平锁:Synchronized 是非公平锁,ReentrantLock(boolean fair)可以创建公平锁


面试官: 小伙子,有点东西。你是怎么设计一个分布式锁?


我: 有几种常用的工具都可以实现分布式锁。比如:关系型数据库(例如:MySQL)、分布式数据库(例如:Redis)、分布式协调服务框架(例如:zookeeper)


使用 MySQL 实现分布式锁比较简单,建一张表:


CREATE TABLE `distributed_lock` (  `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',  `resource_name` varchar(200) NOT NULL DEFAULT '' COMMENT '资源名称(唯一索引)',  PRIMARY KEY (`id`),  UNIQUE KEY `uk_resource_name` (`resource_name`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='分布式锁';
复制代码


获取锁的时候,就插入一条记录。插入成功就代表获取到锁,插入失败就代表获取锁失败。


INSERT INTO distributed_lock (`resource_name`) VALUES ('资源1');
复制代码


释放锁的时候,就删除这条记录。


DELETE FROM distributed_lock WHERE resource_name = '资源1';
复制代码


实现比较简单,不过还不能用于实际生产中,有几个问题没有解决:


  1. 这把锁不支持阻塞,insert 失败立即就返回了。当然可以用 while 循环直到插入成功,不过自旋也会占用 CPU。

  2. 这把锁不是可重入的,已经获取到锁的线程再次插入也会失败,我们可以增加两列,一列记录获取到锁的节点和线程,另一列记录加锁次数。获取锁,次数加一,释放锁,次数减一,次数为零就删除这把锁。

  3. 这把锁没有过期时间,如果业务处理失败或者机器宕机,导致没有释放锁,锁就会一直存在,其他线程也无法获取到锁。我们可以增加一列锁过期时间,再启动一个异步任务扫描过期时间大于当前时间的锁就删除。


就是这么麻烦,我们看一下优化之后的锁变成什么样了:


CREATE TABLE `distributed_lock` (  `id` bigint unsigned NOT NULL AUTO_INCREMENT COMMENT '主键ID',  `resource_name` varchar(200) NOT NULL DEFAULT '' COMMENT '资源名称(唯一索引)',  `owner` varchar(200) NOT NULL DEFAULT '' COMMENT '锁持有者(机器码+线程名称)',  `lock_count` int NOT NULL DEFAULT '0' COMMENT '加锁次数',  `expire_time` datetime NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '锁过期时间',  PRIMARY KEY (`id`),  UNIQUE KEY `uk_resource_name` (`resource_name`)) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='分布式锁';
复制代码


这下应该完美了吧?不行,还有个问题:


业务逻辑没处理完,锁过期了怎么办?


假如我们设置锁过期时间是 6 秒,正常情况下业务逻辑可以在 6 秒内处理完成,但是当 JVM 发生 FullGC 或者调用第三方服务出现网络延迟,业务逻辑还没处理完,锁已经过期,被删掉,然后被其他线程获取到锁,岂不是要出问题?


这就引入了另一个知识点“锁续期”:


获取锁的同时,启动一个异步任务,每当业务执行到三分之一时间,也就是 6 秒中的第 2 秒的时候,就自动延长锁过期时间,继续延长到 6 秒,这样就能保证业务逻辑处理完成之前锁不会过期。


面试官: 小伙子,分布式锁算是让你玩明白了。我还想继续问,生产中一般很少用 MySQL 做分布式锁,因为 MySQL 并发性能跟不上。刚才提到 Redis 也可以实现分布式锁,你知道该怎么实现吗?


我当然知道,八股文就要背全套。


我: 使用 Redis 实现分布式锁,跟使用 MySQL 类似,也需要解决实现过程中遇到的各种问题,不过解决方案稍有不同。


最简单的获取锁方式:


// 1. 获取锁redis.setnx('resource_name1', 'owner1')// 2. 释放锁redis.del('resource_name1')
复制代码


当“resource_name1”不存在时,set 成功,也就是获取锁成功。


不过还需要加上过期时间,防止没有释放锁。


// 1. 获取锁redis.setnx('resource_name1', 'owner1')// 2. 增加锁过期时间redis.exprire('resource_name1', 6, TimeUnit.SECONDS)
复制代码


又引入新问题了,两条命令不是原子的,可能获取锁之后还没来得及设置过期时间就宕机了,这该怎么办?


好办,在 Redis 2.6.12 之后,提供一条复合命令:


redis.set('resource_name1', 'owner1',"NX" "EX", 6)
复制代码


还有一个问题,释放锁的时候,并没有判断锁的持有者,有可能把其他线程持有的锁给释放了,这可不行,可以这样做:


// 释放锁if ('owner1'.equals(redis.get('resource_name1'))){  redis.del('resource_name1')}
复制代码


这样行不行呢?还不行,因为 get 和 del 两条命令不是原子操作,需要引入 Lua 脚本把两条命令打包成一条发给 Redis 执行:


String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";redis.eval(script, Collections.singletonList('resource_name1'), Collections.singletonList('owner1'))
复制代码


这样总行了吧?还不行,还有个“锁续期”的问题没有解决。


更简单了,Redis 客户端 Redisson 已经帮我们实现续期的功能,叫“WatchDog”(看门狗),在我们调用 lock 自动唤醒“看门狗”。


面试官: 小伙子,你可真行啊。你再讲一下使用 zookeeper 怎么实现分布式锁?


我: zookeeper 采用树形节点,类似 Linux 目录文件结构,同一目录下的节点名称不能重复。



节点有分为四种类型:


持久节点: 一旦创建,永久存储在服务器上,除非手动删除。临时节点: 生命周期与客户端绑定,客户端断开连接,节点就被自动删除。持久顺序节点: 特性同持久节点,只是在节点名称后面追加自增有序数字。临时顺序节点: 特性同临时节点,只是在节点名称后面追加自增有序数字。


zookeeper 还有个监听-通知机制,客户端可以在资源节点上创建 watch 事件。当节点发生变化,会通知客户端,客户端可以根据变化做相应的业务处理。


我们可以利用临时顺序节点的特性创建分布式锁,分以下三步:


  1. 在资源/resource1 目录下创建临时顺序节点 node

  2. 获取/resource1 目录下的所有节点,如果当前节点序号最小,代表加锁成功

  3. 如果不是,就是 watch 监听序号最小的节点


实现逻辑很简单,我们来分析一下 zookeeper 实现分布式锁的优点:


  1. 由于创建的临时节点,断开连接后自动删除,所以无需设置锁超时时间,也就不用考虑不释放和锁续期

  2. 由于节点上存储的创建人信息,锁也就支持可重入

  3. 由于可以监听节点,也就实现了可阻塞


面试官: 小伙子,升级加薪的机会就是留给你这样的人。薪资 double,明天就来上班吧。


总结:


关于分布式锁的所有知识点,虽然很多,但都已经总结在这张图上了,欢迎点赞收藏转发评论。



用户头像

一灯架构

关注

公众号:「一灯架构」 2020-11-20 加入

公众号:「一灯架构」,开发专家,只分享有趣的技术干货。

评论

发布
暂无评论
一文详解如何用MySQL/Redis/ZooKeeper实现分布式锁_Java_一灯架构_InfoQ写作社区