网站搭建流程负责人,泰兴网站建设价格,如何制作网站和软件,企业邮箱怎么找Redis分布式锁 - 胤凯 (oyto.github.io)
分布式锁
1、什么是分布式锁#xff1f;
在分布式场景下的锁#xff0c;比如在多台不同机器上的进程#xff0c;去竞争同一项资源#xff0c;就是分布式锁。
2、分布式锁有哪些特性#xff1f; 互斥性#xff1a;只能让一个竞…Redis分布式锁 - 胤凯 (oyto.github.io)
分布式锁
1、什么是分布式锁
在分布式场景下的锁比如在多台不同机器上的进程去竞争同一项资源就是分布式锁。
2、分布式锁有哪些特性 互斥性只能让一个竞争者持有锁 安全性避免锁因为异常永远不被释放当一个竞争者在持有锁期间由于意外崩溃而导致未能主动解锁其持有的锁也能够被兜底释放并保证后续其它竞争者也能加锁 对称性同一个锁加锁和解锁必须是一个竞争者不能把其他竞争者持有的锁给释放了 可靠性需要有一定程度的异常处理能力、容灾能力。
3、分布式锁的实现方式
最简化版本
直接用 Redis 的 setnx 命令语法setnx key value如果 key 不存在则会将 key 设置为 value并返回 1如果 key 存在不会有任务影响返回 0。
通过 setnx 加锁其他服务无法加锁进而阻塞用完之后通过 delete 解锁其他服务再去竞争锁。
支持过期时间
最简化版本有一个问题如果获取锁的服务挂掉了那么锁就一直得不到释放就会导致其他服务无法获取到锁影响到其他服务所以这里需要一个过期时间来进行兜底。
Redis 中有 expire 命令用来设置一个 key 的过期时间。但是 setnx 和 expire 不具备原子性如果 setnx 获取锁之后服务挂掉还没来得及设置过期时间照样石沉大海。
于是使用 set 和 expire 的原子操作set key value nx ex seconds nx 标识 setnx 特性ex 标识过期时间最后一个参数就是过期时间的值。
加上过期时间基本上这个锁就能用了。但存在一个问题会存在服务 A 释放掉 服务 B 的锁的可能。
加上 owner
在特殊的场景服务 A 获取到了锁由于业务流程比较长或者网络延迟、GC卡顿等原因导致锁过期而业务还会继续进行这时候业务 B 已经拿到了锁准备去执行。这个时候服务 A 恢复过来并做完了任务就会释放锁而 B 还在继续就会导致服务 A 释放掉了 服务 B 的锁。
在真实的分布式场景中可能存在几十个竞争者上述情况发生的概率就会很高导致同一份资源频繁被不同竞争者同时访问分布式锁也就失去了意义。
发生这个问题的关键在于竞争者可以释放掉其他竞争者的锁。所以我们可以给出进一步的解决方案分布式锁需要满足谁申请谁释放原则不能释放别人的锁也就是说分布式锁是要有归属的。
引入 lua
加入 owner 后的版本也还有一点点小问题。完整的流程是竞争者获取到锁执行任务执行完毕后检查锁是不是自己的最后释放。
这些操作都不是原子化的可能锁获取的时候还是自己的删除的时候已经是别人的了。
这里就需要引入 Lua。
Redis Lua可以说是专门为解决原子问题而生的。
到了这里分布式锁的前三个特性已经满足对称性、安全性、互斥性。可以是一个可以用的分布式锁了能满足大多数场景。
4、可靠性如何保证
还剩下可靠性没有解决。
针对一些异常情景包括 Redis 挂掉、业务执行时间过长、网络波动等情况。
容灾考虑
前面我们谈及的内容基本是基于单机考虑的如果Redis挂掉了那锁就不能获取了。这个问题该如何解决呢? 一般来说有两种方法:主从容灾和多级部署。
主从容灾
最简单的方式就是为 Redis 配置从节点当主节点挂掉了从节点顶包。
主从切换的话需要人工参与会提高人力成本。不过 Redis 已经有成熟的解决方案也就是哨兵模式可以灵活自动切换不再需要人工介入。
虽然一定程度解决了单点的容灾问题但并不是尽善尽美的由于同步有时延slave通过增加从节点的方式可能会损失掉部分数据分布式锁可能失效这就会发生短暂的多机获取到执行权限
有没有更可靠的办法呢?
多机部署
如果对一致性高一些可以尝试多机部署。比如 Redis 的 RedLock大概思路就是多个机器通常是奇数达到一半以上同意才能算加锁成功这样可靠性会向 ETCD 靠近。 ETCDetcd在前面的回答中已经介绍过etcd是一个分布式键值存储系统用于配置管理、服务发现和分布式协调。它是一个独立的开源项目由CNCF维护具有强一致性和高可用性用于构建分布式系统的基础设施。 现在假设有5个Redis主节点基本保证它们不会同时宕掉获取锁和释放锁的过程中客户端会执行以下操作: 向5个Redis申请加锁; 只要超过一半也就是3个Redis返回成功那么就是获取到了锁。如果超过一半失败需要向每个Redis发送解锁命令; 由于向5个Redis发送请求会有一定时耗所以锁剩余持有时间需要减去请求时间。这个可以作为判断依据如果剩余时间已经为0那么也是获取锁失败; 使用完成之后向5个Redis发送解锁请求。
这种模式的好处在于如果挂了2台Redis整个集群还是可用的给了运维更多时间来修复。
另外多说一句单点Redis的所有手段这种多机模式都可以使用比如为每个节点配置哨兵模式由于加锁是一半以上同意就成功那么如果单个节点进行了主从切换单个节点数据的丢失就不会让锁失效了。这样增强了可靠性。 没有完全可靠的分布式锁
由于分布式系统中的三大困境简称 NPC。 NNetwork Delay 网络延迟网络延迟导致锁过期。 PProcess Pause进程暂停比如发生 GC导致锁超时。 CClock Drift时钟漂移
