【Redis】基础4:作为分布式锁
文章目录
- 1. 一些概念
- 2. MySQL方案
- 2.1 方案一:事务特性
- 2.1.1 存在的问题
- 2.1.2 解决方案
- 2.2 方案二:乐观锁
- 2.3 方案三:悲观锁
- 3. Redis
- 3.1 实现原理
- 3.2 实现细节
- 3.2.1 问题1:持有期间锁过期问题
- 3.2.2 问题2:判断和释放锁间隙中锁过期
- 4. Zookeeper
1. 一些概念
分布式锁的要求:互斥(同一时刻只能一个服务实例的一个线程持有),高可用(单节点挂了其他结点顶上),高性能(读取速度快),安全性(避免死锁)
分布式锁的实现:mysql(本身具备互斥性,具备高可用,读写性能一般,断开连接自动释放锁),redis(使用setnx实现互斥,具备高可用,读写性能高,使用过期时间来释放锁),zookeeper(使用结点唯一性或者顺序性实现互斥,具备高可用,读写性能一般,断开连接释放锁)。综合来看redis性能好可用性高,安全性略差,mysql和zookeeper安全性好,性能略差。
2. MySQL方案
2.1 方案一:事务特性
MySQL默认开启自动提交模式,即客户端执行的每一条 SQL 语句都会被当作一个独立的事务,一旦语句执行完毕,就会自动提交。事务具有ACID特性,因而可以使用MySQL实现分布式锁。
create table lock_table
(id int auto_increment comment 'primary key',value varchar(64) null comment 'resource which need be locked',constraint lock_table_pk primary key (id)
);create unique index lock_table_value_uindex
on lock_table (value);-- 注意:value字段是临界资源。插入成功则获得锁,删除记录则释放锁。一个事务在执行插入时,其他事务插入时失败。
update lock_table set value = #{newValue} where id = #{id};
2.1.1 存在的问题
- 锁不可重入。可重入锁的场景:在递归代码中访问临界资源会重复请求锁,可重入锁可以重复请求锁阻塞;在复杂的调用关系中使用可重入锁来防范死锁问题。
- 没有过期时间,当释放锁失败时会带来死锁问题。
- 申请锁失败时不会阻塞。
- 高度依赖数据库的可用性。
2.1.2 解决方案
- 可重入:给表lock_table新增count字段和请求id字段,当同样的请求到来时只增加count而不是新增记录。
- 给表lock_table新增expire_time字段,通过定时任务定期清理过期的lock
- 使用while循环来创造阻塞效果。
- 创建备用数据,避免单节点数据库,提高可用性。
评价:大量事务经常竞争锁影响性能,一般不使用这个方法。
2.2 方案二:乐观锁
乐观锁:假设取数据时其他人不会修改数据,修改数据时检查是否已经有人修改数据。乐观锁可以使用CAS(Compare And Set)算法实现。
create table lock_table
(id int auto_increment comment 'primary key',value varchar(64) null comment 'locked resource',version int default 0 null comment 'version'constraint lock_table_pk primary key (id)
);
/*
update loss
MySQL默认隔离等级为repeatable read,同一事务内并发的其他事务不能修改数据,因而可以多次读出相同的数据。但是修改数据时,其他并发事务可能抢先一步修改了数据(已经提交),这导致从"old_value"到“new_value”的修改实际上是从"unkonwn_value"到"new_value"的修改。
*/-- 乐观锁应对update loss
update lock_table set value = #{newValue}, version = #{version} + 1 where id = #{id} and version = #{version};
评价:不依赖数据库本身的设计,性能差;需要version字段,造成数据库冗余设计;高并发场景下version字段频繁变动,系统可用性受到影响。适合于多读少些低并发的场景。
2.3 方案三:悲观锁
# 注意关闭自动提交:autocommit=0# 实现1:使用S锁,并发事务可以通过加S锁实现共读,临界资源上有S锁则不许加X锁。并发事务更新临界资源时需要加X锁(update操作默认加X锁),只有有一个事务得到X锁。允许共读,有读不写,写不可读,只有一写。
select id, value from lock_table where id = #{id} lock in share mode;
update lock_table set value = #{newValue} where id = #{id};# 实现2:使用X锁,只有拿到X锁才能读,只有拿到X锁才能写。每次只许一个事务读写。
select id, value from lock_table where id = #{id} for update;
update lock_table set value = #{newValue} where id = #{id};
评价:每个数据请求都加锁,高并发环境下大量请求获取不到锁会陷入阻塞,影响系统性能。表数据量小,MySQL查询不走索引,因而可能触发表锁而不是行锁,影响并发性能。
3. Redis
3.1 实现原理
setnx只有在key不存在的时候才执行,key存在则执行失败。这意味着多个并发执行只会有一个成功,这个特点适合用来实现分布式锁。
# Set the string value of a key only when the key doesn't exist.
SETNX key value# setnx and set expire time are two operations, use set command instead can do all stuff with one operation
SET key value [EX seconds][PX milliseconds][NX|XX]# parameter type
EX seconds: Set expiration time in seconds
PX milliseconds: Set expiration time in milliseconds
NX: Set the value only when the key does not exist
XX: Set the value only when the key exists# release lock
DEL key
3.2 实现细节
3.2.1 问题1:持有期间锁过期问题
例如,线程1获取了锁,其因业务阻塞而长时间持有,结果锁超时释放,线程2随后成功获取锁,线程1业务指向完毕会释放线程2的锁。
解决1:延长锁的expire time。使用redis工具Redisson,它可以使用watchdog技术来延时释放锁。
解决2:线程释放锁时先判断要释放的锁是否是自己的锁,是再释放。
KEY_PREFIX = 'lock'
ID_PREFIX = uuid;
LOCK_NAME = bussiness_name # 和业务相关key = KEY_PREFIX + ':' + LOCK_NAME # lock和业务相关,建议key为lock:name形式def get_current_reqt_id():cur_reqt_id = get_thread_id()reqt_id = ID_PREFIX + '-' + thread_iddef try_lock(key):reqt_id= get_current_reqt_id(reqt_id) # value为持有者唯一标识,此处用uuid + 线程id作为值r = redis_client.get(key)if r:return Truereturn Falsedef unlock(key):cur_reqt_id = get_current_reqt_id()reqt_id = redis_client.get(key)result = Falseif cur_reqt_id == reqt_id:redis_client.del(key)result = Truereturn result
3.2.2 问题2:判断和释放锁间隙中锁过期
例如,线程1要释放锁,先判断锁是否为线程1持有,判断为真,然后线程1执行释放锁操作。判断操作和释放操作间隔较长,锁自动释放。线程2在线程1判断操作后,且锁被自动释放后成功获取了锁。接着线程1执行释放锁操作,则线程1释放掉线程2的锁。
解决:使用lua脚本将判断锁和释放锁打包成原子操作。注意最好将lua脚本加载到内存,方便每次调用直接使用而不是读文件后再操作。
# 使用redis的EVAL命令来执行lua脚本
# Executes a server-side Lua script.
EVAL script numkeys [key [key ...]] [arg [arg ...]]'''
脚本中
KEYS[1] 代表传递给脚本的第一个键名参数
ARGS[1] 代表传递给脚本的第一个参数值
命令中
1 指示参数个数
name 实际传递给脚本的第一个键名参数
xxx 实际代表传递给脚本的第一个
'''
EVAL "return redis.call('set', KEYS[1], ARGS[1])" 1 name xxx# 释放锁lua脚本
if(redis.call('get', KEYS[1]) == ARGS[1]) thenreturn redis.call('del', KEYS[1])
end
return 0
4. Zookeeper
待更新