当前位置： 首页>后端>正文

10. 分布式锁有哪些场景

后端2024-05-06 10:17:29

如何理解分布式锁

为了保证在多线程下处理共享数据的安全性，需要保证同一时刻只有一个线程能处理共享数据
Java 语言提供了线程锁，开放了处理锁机制的 API，比如 Synchronized，Lock 等
当一个锁被某个线程持有时，另一个线程尝试去获取这个锁会失败或者阻塞
直到持有锁的线程释放了该锁
单台服务器内存，可以通过线程加锁的方式来同步，避免并发问题


10. 分布式锁有哪些场景,第1张
20230802102622.jpg

分布式锁的常用实现

10. 分布式锁有哪些场景,第2张
20230802102720.jpg
基于关系型数据库

基于关系型数据库实现分布式锁，是依赖数据库的唯一性来实现资源锁定，比如主键和唯一索引等
以唯一索引为例，创建一张锁表，定义方法或资源名，失效时间等字段
同时针对锁的信息添加唯一索引，比如方法名
当要锁住某个方法或资源时，就在该表中插入对应方法的一条记录
插入成功表示获取了锁，想要释放锁的时候就删除这条记录

  • 创建一张基于数据库的分布式锁表
CREATE TABLE `methodLock` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主键',
  `method_name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的方法或资源',
  PRIMARY KEY (`id`),
  UNIQYE KEY `uidx_method_name` (`method_name`) USIGN BTREE
)ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='对方法加锁';

当希望对某个方法加锁时，执行以下SQL语句

insert into methodLock(method_name) values ('method_name');

如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功
可以认为操作成功的那个线程获得了该方法的锁，可以执行后面的业务逻辑
当方法执行完毕后，想要释放锁，在数据库中删除对应的记录即可

优化
  • 存在单点故障风险
    数据实现方式强依赖数据库的可用性，一旦数据库挂掉，则会导致业务系统不可用
    解决方法：配置数据库主从机器，防止单点故障
  • 超时无法失效
    一旦解锁操作失败，会导致锁记录一直在数据库中，其他线程无法再获得锁
    解决方法：可以添加独立的定时任务，通过时间戳对比等方式，删除超时数据
  • 不可重入
    以Java语言为例，常见的Synchronize，Lock 等都支持可重入
    在数据库实现方式中，同一个线程在没有释放锁
    实现可重入，需要改造加锁方法，额外存储在判断线程信息，不阻塞获得锁的线程再次请求加锁
  • 对阻塞操作不友好
    其他线程在请求对应方法时，插入数据失败会直接返回，不会阻塞线程
    如果需要阻塞其他线程，需要不断的重试 insert 操作，直到数据插入成功

应用 Redis 缓存

缓存的性能更好，各种缓存组件也提供了多种集群方案，可以解决单点问题
常见的开源缓存组件都支持分布式锁，包括 Redis，Memcached 即 Tair
应用 Redis 实现分布式锁，最直接的想法是利用 setnx 和 expire 命令实现加锁
在 Redis 中，setnx 是【set if not exists】如果不存在，则 SET 的意思

  • 当一个线程执行 setnx 返回 1 ，说明 key 不存在，该线程获得锁
  • 当一个线程执行 setnx 返回 0 ，说明key 已存在，获取锁失败
if (setnx(key, value) == 1) {
  expire(key, expireTime)
  try {
    // 业务处理
  } finally {
    // 释放锁
    del(key)
  }
}

在 Redis 版本更新中，添加了 SETEX 命令
SETEX 支持 setnx 和 expire 指令组合的原子操作
解决了加锁过程中失败的问题

基于 ZooKeeper 实现

ZooKeeper 有四种节点类型：

  • 持久节点
  • 持久顺序节点
  • 临时节点
  • 临时顺序节点
利用 ZooKeeper 支持临时顺序节点的特性，可以实现分布式锁
10. 分布式锁有哪些场景,第3张
20230802111918.jpg

当客户端对某个方法加锁时，在 ZooKeeper中该方法对指定节点目录下生成唯一有序节点。
判断是否获取锁，只需要判断持有的节点是否是有序节点中的序号最小的一个
当释放锁的时候，将这个临时节点删除即可
这种方法可以避免服务宕机导致的锁无法释放而产生的死锁问题

使用 Zookeeper 实现分布式锁的算法流程，根节点为 /lock
  • 客户端连接 ZooKeeper ，并在 /lock 下创建临时有序子节点
    第一个客户端对应的子节点为 /lock/lock01/0000001 ,第二个为 /locl/lock01/00000002
  • 其他客户端获取 /lock01 下的子节点列表，判断自己创建的子节点是否为当前列表中序号最小的子节点
  • 如果是则任务获得锁，执行业务代码，否则通过 watch 事件监听 /lock01 的子节点变更消息，获得变更通知后重复此步骤直至获得锁
  • 完成业务流程后，删除对应的子节点，释放分布式锁

在实际开发中，可以应用 Apache Curator 来快速实现分布式锁
Curator 是 Netflix 公司开源的一个 ZooKeeper 客户端
对 ZooKeeper 原生 API 做了抽象和封装


https://www.xamrdz.com/backend/3mf1945462.html

相关文章：