当前位置: 首页 > news >正文

【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 存在的问题

  1. 锁不可重入。可重入锁的场景:在递归代码中访问临界资源会重复请求锁,可重入锁可以重复请求锁阻塞;在复杂的调用关系中使用可重入锁来防范死锁问题。
  2. 没有过期时间,当释放锁失败时会带来死锁问题。
  3. 申请锁失败时不会阻塞。
  4. 高度依赖数据库的可用性。

2.1.2 解决方案

  1. 可重入:给表lock_table新增count字段和请求id字段,当同样的请求到来时只增加count而不是新增记录。
  2. 给表lock_table新增expire_time字段,通过定时任务定期清理过期的lock
  3. 使用while循环来创造阻塞效果。
  4. 创建备用数据,避免单节点数据库,提高可用性。

评价:大量事务经常竞争锁影响性能,一般不使用这个方法。

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

待更新

相关文章:

  • 克隆/备份后的虚拟机无法获取IP地址(FQA)
  • 微软编程一小时:探索 AI 世界
  • Prometheus 实战教程-搭建 Prometheus 环境
  • 现代c++获取linux系统指定网络接口的ip地址
  • 数字化时代软件检测机构如何保障软件质量、安全与合规性?
  • 【Linux实践系列】:进程间通信:万字详解命名管道实现通信
  • NGINX ngx_http_addition_module 模块响应体前后注入内容
  • NVIDIA新模型DAM-3B:描述一切,图像视频局部描述新突破
  • vue3+ts+pinia+vite实战后台管理系统一(框架搭建和配置)
  • IBM Engineering Lifecycle Management 创建用户
  • 迈瑞医疗:国际业务增长21.28% 发展中国家成重要增长引擎
  • C语言中的指针详解
  • 单元测试总结
  • Vue3 项目中 Pinia 与 JavaScript 循环依赖问题深度解析
  • 【前缀和 差分数组 数论】P6042 「ACOI2020」学园祭|省选-
  • 经典数仓架构深度解析与演进:从离线处理到新型架构对比
  • 为什么执行了删除语句后mysql内存无变化?
  • 介绍下Nginx的作用与请求转发机制
  • 初识c++
  • 【Java学习笔记】克隆对象
  • 初步结果显示,卡尼领导的加拿大自由党在联邦众议院选举中获胜
  • 民生访谈|宝妈宝爸、毕业生、骑手……上海如何为不同人群提供就业保障
  • “中国游”带火“中国购”,“即买即退”让外国游客购物更丝滑
  • 下任美联储主席热门人选沃什:美联储犯下“系统性错误”,未能控制一代人以来最严重的通胀
  • 六朝文物草连空——丹阳句容南朝石刻考察纪
  • 梅花画与咏梅诗