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

【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

待更新

http://www.xdnf.cn/news/2635.html

相关文章:

  • 搭建speak yarn集群:从零开始的详细指南
  • 关于健身房管理系统前后端软件开发主要功能需求分析
  • 深入理解网络原理:TCP协议详解
  • MCP Servers玩玩WebUI自动化
  • 如何在idea 中写spark程序
  • UARA串口开发基础
  • Dify+DeepSeek实战教程!企业级 AI 文档库本地化部署,数据安全与智能检索我都要
  • OpenResty技术深度解析:原理、应用与生态对比-优雅草卓伊凡
  • 基于 BERT 微调一个意图识别(Intent Classification)模型
  • LinuxAgent开源程序是一款智能运维助手,通过接入 DeepSeek API 实现对 Linux 终端的自然语言控制,帮助用户更高效地进行系统运维工作
  • astrbot_plugin_composting_bucket开源程序是一个用于降低AstrBot的deepseek api调用费用的插件
  • AI大模型:(二)2.4 微调自己的模型
  • 蒋新松:中国机器人之父
  • 解构编程语言的基因密码:论数据类型如何被语言系统定义与重塑
  • 达梦数据库官方迁移工具SQLark:支持Oracle/MySQL/PostgreSQL迁移至达梦数据库!
  • 使用exdp 备份数据库
  • Scratch——第20课 辗转相除法/绳子算法
  • GitLab CVE-2024-12444 安全漏洞解决方案
  • 劳动节ppt免费下载,劳动节ppt模板,劳动节课件
  • 配置电子邮件服务
  • LabVIEW开发之困境中逼出成长力
  • MCP之二_服务器与客户端实现
  • 抱佛脚之学SSMAOP
  • 【AI News | 20250428】每日AI进展
  • 国内比较好用的代理IP测评
  • C++——哈希表
  • Debian10系统安装,磁盘分区和扩容
  • redis未授权访问漏洞学习
  • 38、Python协程与任务调度高级技巧:从异步IO到分布式实践
  • 《Windows系统Java环境安装指南:从JDK17下载到环境变量配置》