国外h5网站模板下载,广州自适应网站建设,网站打开显示域名错误,一号网站建设目录 一、什么是分布式锁 二、分布式锁的基础实现 三、引入过期时间 四、引入校验 id 五、引入lua 六、引入 watch dog (看门狗) 七、引入 Redlock 算法 八、其他功能 redis学习#x1f973; 一、什么是分布式锁
在一个分布式的系统中#xff0c;也会涉及到多个节点访问同一… 目录 一、什么是分布式锁 二、分布式锁的基础实现 三、引入过期时间 四、引入校验 id 五、引入lua 六、引入 watch dog (看门狗) 七、引入 Redlock 算法 八、其他功能 redis学习 一、什么是分布式锁
在一个分布式的系统中也会涉及到多个节点访问同一个公共资源的情况. 此时就需要通过 锁 来做互
斥控制避免出现类似于 线程安全 的问题.
而 java 的 synchronized 或者 C 的 std::mutex这样的锁都是只能在当前进程中生效在分布式
系统中是有很多进程的每个服务器都是独立的进程因此之前的锁就难以对现在分布式系
统中的多个进程之间产生制约。分布式系统中多个进程之间的执行顺序也是不确定的 随机性此
时就需要使用到 “分布式锁”. ✍ 本质上就是使用一个公共的服务器来记录 加锁状态. 这个公共的服务器可以是 Redis也可以是其他组件(比如 MySQL 或者 ZooKeeper 等)还可以是我们自己写的一个服务. 二、分布式锁的基础实现
思路非常简单. 本质上就是通过一个键值对来标识锁的状态.
举个例子: 考虑买票的场景现在存在多个服务器节点每个车次的票数都是固定的.
现在车站提供了若干个车次都可能需要处理这个买票的逻辑: 先查询指定车次的余票如果余票 0,
则设置余票值 - 1. 显然上述的场景是存在 线程安全 问题的需要使用锁来控制.
否则就可能出现 超卖 的情况.
此时如何进行加锁呢我们可以在上述架构中引入一个 Redis 作为分布式锁的管理器. 此时如果 买票服务器1 尝试买票就需要先访问 Redis在 Redis 上设置一个键值对. 比如 key 就是车次value 随便设置个值 (比如 1).
如果这个操作设置成功就视为当前没有节点对该 001 车次加锁就可以进行数据库的读写操作. 操作
完成之后再把 Redis 上刚才的这个键值对给删除掉.
如果在买票服务器1 操作数据库的过程中买票服务器2 也想买票也会尝试给 Redis 上写一个键值对
key 同样是车次. 但是此时设置的时候发现该车次的 key 已经存在了则认为已经有其他服务器正在持
有锁此时 服务器2 就需要等待或者暂时放弃. Redis 中提供了 setnx 操作正好适合这个场景. 即: key 不存在就设置存在则直接失败. 但是上述方案并不完整.
三、引入过期时间
当 服务器1 加锁之后开始处理买票的过程中如果 服务器1 意外宕机了就会导致解锁操作 (删除该
key) 不能执行. 就可能引起其他服务器始终无法获取到锁的情况.
为了解决这个问题可以在设置 key 的同时引入过期时间. 即这个锁最多持有多久就应该被释放. 可以使用 set ex nx 的方式在设置锁的同时把过期时间设置进去. 注意! 此处的过期时间只能使用一个命令的方式设置. 如果分开多个操作比如 setnx 之后再来一个单独的 expire由于 Redis 的多个指令之间不存在关联并且即使使用了事务也不能保证这两个操作都一定成功因此就可能出现 setnx 成功但是 expire 失败的情况. 此时仍然会出现无法正确释放锁的问题. 四、引入校验 id
对于 Redis 中写入的加锁键值对其他的节点也是可以删除的. 比如 服务器1 写入一个 001: 1 这样的键值对服务器2 是完全可以把 001 给删除掉的. 当然服务器2 不会进行这样的 恶意删除 操作不过不能保证因为一些 bug 导致 服务器2 把锁误删除. 为了解决上述问题我们可以引入一个校验 id.
比如可以把设置的键值对的 value不再是简单的设为一个 1而是设成服务器的编号.
形如 001:服务器1 .
这样就可以在删除 key (解锁)的时候先校验当前删除 key 的服务器是否是当初加锁的服务器如果
是才能真正删除不是则不能删除。逻辑用伪代码描述如下:
String key [要加锁的资源 id];
String serverId [服务器的编号];// 加锁, 设置过期时间为 10s
redis.set(key, serverId, NX, EX, 10s);// 执行各种业务逻辑, 比如修改数据库数据.
doSomeThing();// 解锁, 删除 key. 但是删除前要检验下 serverId 是否匹配.
if (redis.get(key) serverId) {redis.del(key);
}
但是很明显解锁逻辑是两步操作 get 和 del这样做并非是原子的.
五、引入lua
为了使解锁操作原子可以使用 Redis 的 Lua 脚本功能. Lua 也是一个编程语言. 读作 撸啊. 是葡萄牙语中的 月亮 的意思. (出自于 Lua 官方文档https://www.lua.org/about.html) Lua 的语法类似于 JS是一个动态弱类型的语言. Lua 的解释器一般使用 C 语言实现. Lua 语法 简单精炼执行速度快解释器也比较轻量 (Lua 解释器的可执行程序体积只有 200KB 左右). 因此 Lua 经常作为其他程序内部嵌入的脚本语言. Redis 本身就支持 Lua 作为内嵌脚本. 很多程序都支持内嵌脚本比如 MySQL 8 支持 JS 作为内嵌脚本比如 Vim 支持 VimScript 和 Python 作为内嵌脚本.... 通过内嵌脚本来实现更复杂的功能提供更强的扩展性. Lua 除了和 Redis 搭伙之外在很多场景也会作为内嵌脚本. 比如在游戏开发领域常常作为编写逻辑的语言. (比如魔兽世界、大话西游等) 使用 Lua 脚本完成上述解锁功能
if redis.call(get,KEYS[1]) ARGV[1] thenreturn redis.call(del,KEYS[1])
elsereturn 0
end;
上述代码可以编写成一个 .lua 后缀的文件由 redis-cli 或者 redis-plus-plus 或者 jedis 等客户端加载并发送给 Redis 服务器由 Redis 服务器来执行这段逻辑.
一个 lua 脚本会被 Redis 服务器以原子的方式来执行.
redis-plus-plus 和 jedis 如何调用 lua 咱们此处不做过多介绍. 具体 api 的写法大家可以自行研究.
六、引入 watch dog (看门狗)
上述方案仍然存在一个重要问题. 当我们设置了 key 过期时间之后 (比如 10s)仍然存在一定的可能
性当任务还没执行完key 就先过期了. 这就导致锁提前失效. 把这个过期时间设置的足够长比如 30s, 是否能解决这个问题呢很明显设置多长时间合适是无止境的. 即使设置再长也不能完全保证就没有提前失效的情况. 而且如果设置的太长了万一对应的服务器挂了此时其他服务器也不能及时的获取到锁. 因此相比于设置一个固定的长时间不如动态的调整时间更合适. 所谓 watch dog本质上是加锁的服务器上的一个单独的线程通过这个线程来对锁过期时间进行 续
约.
注意这个线程是业务服务器上的不是 Redis 服务器的. ❤ 举个具体的例子: 初始情况下设置过期时间为 10s. 同时设定看门狗线程每隔 3s 检测一次. 那么当 3s 时间到的时候看门狗就会判定当前任务是否完成. • 如果任务已经完成则直接通过 lua 脚本的方式释放锁(删除 key). • 如果任务未完成则把过期时间重写设置为 10s. (即 续约) 这样就不担心锁提前失效的问题了. 而且另一方面如果该服务器挂了看门狗线程也就随之挂了此
时无人续约这个 key 自然就可以迅速过期让其他服务器能够获取到锁了.
七、引入 Redlock 算法
实践中的 Redis 一般是以集群的方式部署的 (至少是主从的形式而不是单机). 那么就可能出现以下比
较极端的大冤种情况: 服务器1 向 master 节点进行加锁操作. 这个写入 key 的过程刚刚完成master 挂了slave节点升级成了新的 master 节点. 但是由于刚才写入的这个 key 尚未来得及同步给 slave 呢此时就相当于 服务器1 的加锁操作形同虚设了服务器2 仍然可以进行加锁 (即给新的 master 写入 key. 因为新的 master 不包含刚才的 key). 因此之前学的 哨兵分布式场景中涉及的数据量不大和集群更多解决的是存储空间不足的问
题模式 是不可取的为了解决这个问题Redis 的作者提出了 Redlock 算法.
我们引入一组 Redis 节点. 其中每一组 Redis 节点都包含一个主节点和若干从节点. 并且组和组之间存
储的数据都是一致的,相互之间是备份关系 (而并非是数据集合的一部分这点有别于 Redis cluster).
加锁的时候按照一定的顺序写多个 master 节点. 在写锁的时候需要设定操作的 超时时间. 比如
50ms. 即如果 setnx 操作超过了 50ms 还没有成功就视为加锁失败. 如果给某个节点加锁失败就立即再尝试下一个节点.
当加锁成功的节点数超过总节点数的一半才视为加锁成功.
如上图一共五个节点三个加锁成功两个失败此时视为加锁成功.
这样的话即使有某些节点挂了也不影响锁的正确性. 那么是否可能出现上述节点都同时遇到了 大冤种 情况呢理论上这件事是可能发生的但是概率太小了. 工程上就可以忽略不计了. 同理释放锁的时候也需要把所有节点都进行解锁操作. (即使是之前超时的节点也要尝试解锁尽
量保证逻辑严密).
简而言之Redlock 算法的核心就是加锁操作不能只写给一个 Redis 节点而要写个多个分布式
系统中任何一个节点都是不可靠的. 最终的加锁成功结论是 少数服从多数的.
由于一个分布式系统不至于大部分节点都同时出现故障, 因此这样的可靠性要比单个节点来说靠谱不少.
八、其他功能
上述描述中我们解释了基于 Redis 的分布式锁的基本实现原理.
上述锁只是一个简单的互斥锁. 但是实际上我们在一些特定场景中还有一些其他特殊的锁比如:
• 可重入锁
• 公平锁遵循先来后到原则
• 读写锁
• ......
基于 Redis 的分布式锁也可以实现上述特性. (当然了对应的实现逻辑也会更复杂).
此处我们不做过多讨论了.
实际开发中我们也并不会真的自己实现一个分布式锁. 已经有很多现成的库帮我们封装好了我们直
接使用即可. 比如 Java 中的 RedissonC 中的 redis-plus-plus. 当然有些大厂也会有自己版本的分布式锁的实现. redis学习打卡
