实现分布式锁的常用三种方式
创作小达人 2024-09-19 09:05:03 阅读 89
分布式锁概述
我们的系统都是分布式部署的，日常开发中，秒杀下单、抢购商品等等业务场景，为了防⽌库存超卖，都需要用到分布式锁。
分布式锁其实就是，控制分布式系统不同进程共同访问共享资源的一种锁的实现。如果不同的系统或同一个系统的不同主机之间共享了某个临界资源，往往需要互斥来防止彼此干扰，以保证一致性。
业界流行的分布式锁实现，一般有这3种方式：
基于数据库实现的分布式锁
基于Redis实现的分布式锁
基于Zookeeper实现的分布式锁
分布式锁：基于数据库实现
主要有两种方式：
1、悲观锁
2、乐观锁
A. 悲观锁（排他锁）
利用select … where xx=yy for update排他锁
注意：这里需要注意的是where xx=yy，xx字段必须要走索引，否则会锁表。有些情况下，比如表不大，mysql优化器会不走这个索引，导致锁表问题。
核心思想：以「悲观的心态」操作资源，无法获得锁成功，就一直阻塞着等待。
注意：该方式有很多缺陷，一般不建议使用。
实现：
创建一张资源锁表：
<code>
CREATE TABLE `resource_lock` (
`id` int(4) NOT NULL AUTO_INCREMENT COMMENT '主键',
`resource_name` varchar(64) NOT NULL DEFAULT '' COMMENT '锁定的资源名',
`owner` varchar(64) NOT NULL DEFAULT '' COMMENT '锁拥有者',
`desc` varchar(1024) NOT NULL DEFAULT '备注信息',
`update_time` timestamp NOT NULL DEFAULT '' COMMENT '保存数据时间，自动生成',
PRIMARY KEY (`id`),
UNIQUE KEY `uidx_resource_name` (`resource_name `) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='锁定中的资源';code>
注意：resource_name 锁资源名称必须有唯一索引
使用事务查询更新：
@Transaction
public void lock(String name) {
ResourceLock rlock = exeSql("select * from resource_lock where resource_name = name for update");
if (rlock == null) {
exeSql("insert into resource_lock(reosurce_name,owner,count) values (name, 'ip',0)");
}
}
使用 for update 锁定的资源。如果执行成功，会立即返回，执行插入数据库，后续再执行一些其他业务逻辑，直到事务提交，执行结束；如果执行失败，就会一直阻塞着。
可以在数据库客户端工具上测试出来这个效果，当在一个终端执行了 for update，不提交事务。在另外的终端上执行相同条件的 for update，会一直卡着
虽然也能实现分布式锁的效果，但是会存在性能瓶颈。
优点：
简单易用，好理解，保障数据强一致性。
缺点：
1）在 RR 事务级别，select 的 for update 操作是基于间隙锁（gap lock） 实现的，是一种悲观锁的实现方式，所以存在阻塞问题。
2）高并发情况下，大量请求进来，会导致大部分请求进行排队，影响数据库稳定性，也会耗费服务的CPU等资源。
当获得锁的客户端等待时间过长时，会提示：
[40001][1205] Lock wait timeout exceeded; try restarting transaction
高并发情况下，也会造成占用过多的应用线程，导致业务无法正常响应。
3）如果优先获得锁的线程因为某些原因，一直没有释放掉锁，可能会导致死锁的发生。
4）锁的长时间不释放，会一直占用数据库连接，可能会将数据库连接池撑爆，影响其他服务。
5）MySql数据库会做查询优化，即便使用了索引，优化时发现全表扫效率更高，则可能会将行锁升级为表锁，此时可能就更悲剧了。
6）不支持可重入特性，并且超时等待时间是全局的，不能随便改动。
B. 乐观锁
所谓乐观锁与悲观锁最大区别在于基于CAS思想，表中添加一个时间戳或者是版本号的字段来实现，update xx set version=new_version where xx=yy and version=Old_version，通过增加递增的版本号字段实现乐观锁。
不具有互斥性，不会产生锁等待而消耗资源，操作过程中认为不存在并发冲突，只有update version失败后才能觉察到。
抢购、秒杀就是用了这种实现以防止超卖。
实现：
创建一张资源锁表：
CREATE TABLE `resource` (
`id` int(4) NOT NULL AUTO_INCREMENT COMMENT '主键',
`resource_name` varchar(64) NOT NULL DEFAULT '' COMMENT '资源名',
`share` varchar(64) NOT NULL DEFAULT '' COMMENT '状态',
`version` int(4) NOT NULL DEFAULT '' COMMENT '版本号',
`desc` varchar(1024) NOT NULL DEFAULT '备注信息',
`update_time` timestamp NOT NULL DEFAULT '' COMMENT '保存数据时间，自动生成',
PRIMARY KEY (`id`),
UNIQUE KEY `uidx_resource_name` (`resource_name `) USING BTREE
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='资源';code>
为表添加一个字段，版本号或者时间戳都可以。通过版本号或者时间戳，来保证多线程同时间操作共享资源的有序性和正确性。
伪代码实现：
Resrouce resource = exeSql("select * from resource where resource_name = xxx");
boolean succ = exeSql("update resource set version= 'newVersion' ... where resource_name = xxx and version = 'oldVersion'");
if (!succ) {
// 发起重试
}
实际代码中可以写个while循环不断重试，版本号不一致，更新失败，重新获取新的版本号，直到更新成功。
优点：
实现简单，复杂度低
保障数据一致性
缺点：
性能低，并且有锁表的风险
可靠性差
非阻塞操作失败后，需要轮询，占用CPU资源
长时间不commit或者是长时间轮询，可能会占用较多的连接资源
分布式锁：基于Redis实现
原理与实现
Redis提供了多种命令支持实现分布式锁，其中最常用的是SETNX（Set if Not eXists）和GETSET结合使用，或者使用更高级的SET命令配合NX（Only set the key if it does not already exist）和PX或EX（为key设置过期时间）选项。
优点：
性能高效，Redis本身为内存数据库，操作速度快。
实现简单，通过几个命令即可完成锁的获取与释放。
支持自动过期，降低死锁风险。
缺点：
单点问题，依赖单一Redis实例可能成为瓶颈。
网络分区可能导致锁的不一致状态。
示例代码（伪代码）:
import redis.clients.jedis.Jedis;
public class RedisDistributedLock {
private Jedis jedis;
private static final String LOCK_SUCCESS = "OK";
private static final Long RELEASE_SUCCESS = 1L;
public RedisDistributedLock(Jedis jedis) {
this.jedis = jedis;
}
public boolean lock(String lockKey, int expireTime) {
String result = jedis.set(lockKey, "locked", "NX", "PX", expireTime * 1000);
return LOCK_SUCCESS.equals(result);
}
public boolean unlock(String lockKey) {
String script = "if redis.call('get', KEYS[1]) == ARGV[1] then return redis.call('del', KEYS[1]) else return 0 end";
Object result = jedis.eval(script, 1, lockKey, "locked");
return RELEASE_SUCCESS.equals(result);
}
}
代码注解：上例中，lock方法尝试使用NX（只在键不存在时设置）和PX（设置过期时间，单位毫秒）参数设置锁，返回OK表示成功获取锁。unlock方法使用Lua脚本确保解锁操作的原子性，只有当锁的持有者与当前客户端匹配时才执行删除操作。
分布式锁：基于Zookeeper实现
在学习Zookeeper分布式锁之前，我们复习一下Zookeeper的节点哈。
Zookeeper的节点Znode有四种类型：
持久节点：默认的节点类型。创建节点的客户端与zookeeper断开连接后，该节点依旧存在。
持久节点顺序节点：所谓顺序节点，就是在创建节点时，Zookeeper根据创建的时间顺序给该节点名称进行编号，持久节点顺序节点就是有顺序的持久节点。
临时节点：和持久节点相反，当创建节点的客户端与zookeeper断开连接后，临时节点会被删除。
临时顺序节点：有顺序的临时节点。
Zookeeper分布式锁实现应用了临时顺序节点。这里不贴代码啦，来讲下zk分布式锁的实现原理吧。
zk获取锁过程
当第一个客户端请求过来时，Zookeeper客户端会创建一个持久节点locks。如果它（Client1）想获得锁，需要在locks节点下创建一个顺序节点lock1.如图
接着，客户端Client1会查找<code>locks下面的所有临时顺序子节点，判断自己的节点lock1是不是排序最小的那一个，如果是，则成功获得锁。
这时候如果又来一个客户端client2前来尝试获得锁，它会在locks下再创建一个临时节点<code>lock2
客户端client2一样也会查找locks下面的所有临时顺序子节点，判断自己的节点lock2是不是最小的，此时，发现lock1才是最小的，于是获取锁失败。获取锁失败，它是不会甘心的，client2向它排序靠前的节点lock1注册Watcher事件，用来监听lock1是否存在，也就是说client2抢锁失败进入等待状态。
此时，如果再来一个客户端Client3来尝试获取锁，它会在locks下再创建一个临时节点lock3
同样的，client3一样也会查找locks下面的所有临时顺序子节点，判断自己的节点lock3是不是最小的，发现自己不是最小的，就获取锁失败。它也是不会甘心的，它会向在它前面的节点lock2注册Watcher事件，以监听lock2节点是否存在。
释放锁
我们再来看看释放锁的流程，Zookeeper的客户端业务完成或者发生故障，都会删除临时节点，释放锁。如果是任务完成，Client1会显式调用删除lock1的指令
如果是客户端故障了，根据临时节点得特性，lock1是会自动删除的
lock1节点被删除后，Client2可开心了，因为它一直监听着lock1。lock1节点删除，Client2立刻收到通知，也会查找locks下面的所有临时顺序子节点，发下lock2是最小，就获得锁。
同理，Client2获得锁之后，Client3也对它虎视眈眈，啊哈哈~
Zookeeper设计定位就是分布式协调，简单易用。如果获取不到锁，只需添加一个监听器即可，很适合做分布式锁。
Zookeeper作为分布式锁也缺点：如果有很多的客户端频繁的申请加锁、释放锁，对于Zookeeper集群的压力会比较大。
声明
本文内容仅代表作者观点，或转载于其他网站，本站不以此文作为商业用途
如有涉及侵权，请联系本站进行删除
转载本站原创文章，请注明来源及作者。