聊聊Java三种常见的分布式锁
平时我们在 APP 上抢某件商品时，手指疯狂点击下单，但是只会生成一个订单，为什么呢？
因为对用户下单加了一个锁，避免用户重复下单。而在分布式场景，订单可以看作一个共享资源，所以这个锁可以叫做分布式锁。
一般来讲，分布式锁有三种实现方式：
- 基于数据库的分布式锁
- 基于 redis 的分布式锁
- 基于 Zookeeper 的分布式锁
1 基于数据库的分布式锁
基于数据库实现分布式锁有很多实现，这里介绍其中一种。其核心思想是：
在数据库中创建一个表，表中添加 方法名 等字段，并 对方法名字段添加唯一索引，如果要对某个方法加锁，则使用这个方法名向表中插入数据，成功插入则加锁成功，方法执行完后删除对应的行数据释放锁。[1]
1.1 创建表
CREATE TABLE `t_database_lock` ( `id` bigint NOT NULL COMMENT '主键', `method_name` varchar(50) COLLATE utf8_bin NOT NULL DEFAULT '方法名字', `create_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间', `update_time` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '最近更新时间' PRIMARY KEY(`id`), UNIQUE INDEX `uk_t_database_lock_mname`(`method_name`) USING BTREE COMMENT '方法名唯一索引', INDEX `idx_t_accounting_balance_account_utime`(`update_time`) USING BTREE COMMENT '更新时间索引', INDEX `idx_t_accounting_balance_account_ctime`(`create_time`) USING BTREE COMMENT '创建时间索引' ) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_bin
1.2 伪代码实现
主流程如下：
public void execute(String methodName) {
try {
if (lock(methodName)) { // 加锁
// 你的业务逻辑
run();
}
} finally {
unlock(); // 释放锁
}
}lock() 方法的实现的伪代码如下：
private boolean lock(String methodName) {
try {
// 插入一条数据
int count = "INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '需要加锁的methodName');";
if (count == 1) { // 1 表示插入成功
return true;
}
return false;
} catch (Exception e) {
return false;
}
return false;
}unlock() 方法实现的伪代码如下：
private boolean lock(String methodName) {
try {
// 插入一条数据
int count = "INSERT INTO method_lock (method_name, desc) VALUES ('methodName', '需要加锁的methodName');";
if (count == 1) { // 1 表示插入成功
return true;
}
return false;
} catch (Exception e) {
return false;
}
return false;
}它的优点是实现简单，但是有以下缺点：
- 读取写入性能低，资源开销较大，不适合并发量很高的场景。
- 可靠性较低，因为数据库的可用性会直接影响到分布式锁的可用性，所以数据库需要双机部署、数据同步、主备切换。
- 没有锁失效机制。如果在成功插入一条数据后，服务器宕机了，导致这条数据没有删除，服务恢复后一直获取不到锁。解决方式是可以在表中新增一例失效时间，定时清除这些失效数据。
- 锁逻辑简单，不具备阻塞锁等高级功能。
2 基于 redis 的分布式锁
redis 分布式锁的好处是性能好，实现也较为方便。
2.1 setnx + expire
- setnx 即 Set if Not Exists，如果 redis 存在这个 key，setnx 返回0，加锁失败；否则返回1，加锁成功。
- expire 用来设置 redis key 的过期时间，避免这个锁一直存在，造成无法加锁的问题。
实现伪代码如下：
if (jedis.setnx(key) == 1) { // 加锁成功
expire(key, 100);
try {
doSomething(); //业务处理
} catch (Exception e) {
} finally {
jedis.del(key); // 释放锁
}
}这个是基本的实现，但是会有一个问题：如果 setnx 执行结束，进程中断了，没有执行 expire 代码，导致 key 没有设置过期时间，别的线程就永远获取不到这个锁了。
2.2 setnx 同时设置过期时间
基于以上问题，我们可以将 redis 的 value 利用起来，将 jedis.setnx(key) 改为 jedis.setnx(key, ${过期时间})，加锁的伪代码如下[2]：
public boolean lock(String key, Long expireTime) {
Jedis jedis = new Jedis();
//系统时间 + 设置的过期时间
long expires = System.currentTimeMillis() + expireTime;
String expiresStr = String.valueOf(expires);
// 如果当前锁不存在，返回加锁成功
if (jedis.setnx(key, expiresStr) == 1) {
return true;
}
// 如果锁已经存在，获取锁的过期时间
String currentValueStr = jedis.get(key);
// 锁过期
if (currentValueStr != null && Long.parseLong(currentValueStr) < System.currentTimeMillis()) {
// 锁已过期，获取上一个锁的过期时间，并设置现在锁的过期时间
String oldValueStr = jedis.getSet(key, expiresStr);
if (oldValueStr != null && oldValueStr.equals(currentValueStr)) {
// 只有上一个锁的过期时间和当前过期时间相同才可加锁
return true;
}
}
return false;
}以上的实现方式避免了锁一直存在的问题，但是仍然有缺点：
- 过期时间使用
System.currentTimeMillis()生成，意味着客户端时间必须同步。 - 没有辨别客户端的机制，可能 A 机器加了锁，被 B 机器解锁了。
- 并发情况下，多个机器同时加锁，只有一个会加锁成功。
2.3 将 redis value 设置为客户端标识
通过以上分析，我们既希望 redis 设置 key 和 expire 同时进行，又希望 redis 加锁解锁时能识别客户端。
因此我们将客户端加锁时，生成一个唯一 ID 作为 redis 的 value，在进行锁操作时先校验一下客户端是否一致，在进行锁操作。redis 的 set() 方法可以满足要求。
流程的伪代码如下：
public void execute() {
Jedis jedis = new Jedis();
String key = "key";
String uuid = "uuid";
if ("1".equals(jedis.set(key, uuid, "NX", "EX", 100))) { //加锁
try {
doSomething(); //业务处理
} finally {
//判断是不是当前线程加的锁,是才释放
if (uuid.equals(jedis.get(key))) {
jedis.del(key); //释放锁
}
}
}
}以上实现已经不错了，可以满足大部分场景。但是还有一个问题：过期时间是个不确定因素，你很难设置一个合适的过期时间，使得锁既在业务执行后释放，又不至于太长导致其他线程获取失败。
2.4 Redisson
Redisson 可以解决上面的问题，它的原理是在加锁成功后启动一个看门狗，在线程持有锁期间不断延长 key 的生存时间，如此一来可解决锁在业务执行完之前就释放的问题。
3 Zookeeper 分布式锁
当使用 ZooKeeper 实现分布式锁时，可以按照以下步骤进行操作：
- 每个客户端连接到 ZooKeeper 服务器。
- 每个客户端在 ZooKeeper 上创建一个临时顺序节点作为锁节点。
- 客户端获取锁的方式是判断自己创建的节点是否是当前所有锁节点中最小的。
- 如果客户端创建的节点是最小节点，表示该客户端获得了锁，可以执行关键区域的代码。
- 如果客户端创建的节点不是最小节点，则需要监听比自己创建节点次小的节点。
- 当监听到次小节点被删除时，客户端重新检查自己创建的节点是否是当前所有锁节点中最小的。如果是，则获得了锁，可以执行关键区域的代码。
- 当客户端完成了关键区域的操作后，释放锁，即删除自己创建的节点。
这样，通过 ZooKeeper 的临时顺序节点和监听机制，可以实现一个简单的分布式锁。每个客户端在创建节点时，会根据节点名称的顺序来确定是否获得了锁。如果创建的节点是最小节点，则表示该客户端获得了锁，可以执行关键区域的代码。其他客户端则通过监听比自己创建的节点次小的节点来等待锁的释放，从而实现分布式的互斥访问。
总结
三种分布式锁对比
数据库分布式锁实现
优点：简单，使用方便，不需要引入 Redis、Zookeeper 等中间件。
缺点：
不适合高并发的场景
db 操作性能较差
Redis 分布式锁实现
优点：
性能好，适合高并发场景
较轻量级
有较好的框架支持，如 Redisson
缺点：
过期时间不好控制
需要考虑锁被别的线程误删场景
Zookeeper 分布式锁实现
缺点：
性能不如 Redis 实现的分布式锁
比较重的分布式锁。
优点：
有较好的性能和可靠性
有封装较好的框架，如 Curator
以上实现方式都不是完美的，在实际生产中要合理评估，选择适合自己的方案。
性能
redis > zookeeper >= 数据库
可靠性
zookeeper > redis > 数据库
实现复杂度
zookeeper > redis > 数据库
- [1] 什么是分布式锁？实现分布式锁的三种方式
- [2] 面试官又问我分布式锁。。。
到此这篇关于聊聊Java三种常见的分布式锁的文章就介绍到这了,更多相关Java 分布式锁内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！
相关文章
这篇文章主要介绍了Servlet虚拟路径映射配置详解，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2020-02-02
这篇文章主要介绍了Mybatis通过数据库表自动生成实体类和xml映射文件的操作，具有很好的参考价值，希望对大家有所帮助。如有错误或未考虑完全的地方，望不吝赐教2021-07-07
这篇文章主要为大家详细介绍了java实现九宫格拼图游戏，文中示例代码介绍的非常详细，具有一定的参考价值，感兴趣的小伙伴们可以参考一下2021-07-07
本文主要介绍了java集合框架的相关知识。具有一定的参考价值，下面跟着小编一起来看下吧2017-01-01
下面小编就为大家带来一篇java在文件尾部追加内容的简单实例。小编觉得挺不错的，现在就分享给大家，也给大家做个参考。一起跟随小编过来看看吧2016-12-12
这篇文章主要为大家详细介绍了如何使用Java实现动态生成MySQL数据库,文中的示例代码讲解详细,感兴趣的小伙伴可以跟随小编一起学习一下2024-02-02
这篇文章主要介绍了有关Java垃圾回收机制的知识，文中实例简单易懂，方便大家更好的学习，有兴趣的朋友可以了解下2020-06-06
本文主要介绍了手动部署java项目到k8s中的实现，文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值，需要的朋友们下面随着小编来一起学习学习吧2022-08-08
下面小编就为大家带来一篇使用Homebrew配置Java开发环境操作方法。小编觉得挺不错的，现在就分享给大家，也给大家做个参考。一起跟随小编过来看看吧2017-06-06
这篇文章主要给大家介绍了关于IDEA插件指南之Mybatis log插件安装及使用的相关资料,文中通过图文介绍的非常详细,对大家的学习或者工作具有一定的参考借鉴价值,需要的朋友可以参考下2024-02-02
最新评论