网络公司给别人做网站的cms是买的授权么,企业为什么要做账,wordpress最新版核心,网站是通过超链接目录 Redis 典型应⽤ - 分布式锁什么是分布式锁分布式锁的基础实现引⼊过期时间引⼊校验 id引⼊ lua引⼊ watch dog (看⻔狗)引⼊ Redlock 算法其他功能 Redis 典型应⽤ - 分布式锁
什么是分布式锁
在⼀个分布式的系统中#xff0c; 也会涉及到多个节点访问同⼀个公共资源的… 目录 Redis 典型应⽤ - 分布式锁什么是分布式锁分布式锁的基础实现引⼊过期时间引⼊校验 id引⼊ lua引⼊ watch dog (看⻔狗)引⼊ Redlock 算法其他功能 Redis 典型应⽤ - 分布式锁
什么是分布式锁
在⼀个分布式的系统中 也会涉及到多个节点访问同⼀个公共资源的情况。此时就需要通过 锁 来做互斥控制 避免出现类似于 “线程安全” 的问题 线程安全问题多个线程并发执行的时候执行先后顺序是不确定的。就需要保证程序在任意执行顺序下执行逻辑都是OK的 ⽽ 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 不存在就设置 存在则直接失败 但是上述⽅案并不完整 某个服务器加锁成功了setnx 成功执行后续逻辑过程中程序崩溃了没有执行到解锁 这里不能通过在 finally 的方式解锁这只是对进程内的锁有效这对分布式系统的无效的比如服务器直接断电进程就直接异常终止了 引⼊过期时间
当 服务器1 加锁之后 开始处理买票的过程中 如果 服务器1 意外宕机了 就会导致解锁操作 (删除该key) 不能执⾏。就可能引起其他服务器始终⽆法获取到锁的情况
为了解决这个问题 可以在设置 key 的同时引⼊过期时间。即这个锁最多持有多久就应该被释放 可以使⽤ set ex nx 的⽅式 在设置锁的同时把过期时间设置进去 注意! 此处的过期时间只能使⽤⼀个命令的⽅式设置 如果分开多个操作 ⽐如 setnx 之后 再来⼀个单独的 expire 由于 Redis 的多个指令之间不存在关联 并且即使使⽤了事务也不能保证这两个操作都⼀定成功 因此就可能出现 setnx 成功 但是 expire 失败的情况 此时仍然会出现⽆法正确释放锁的问题 引⼊校验 id
对于 Redis 中写⼊的加锁键值对 其他的节点也是可以删除的。 ⽐如 服务器1 写⼊⼀个 “001”: 1 这样的键值对 服务器2 是完全可以把 “001” 给删除掉的。 当然 服务器2 不会进⾏这样的 “恶意删除” 操作 不过不能保证因为⼀些 bug 导致 服务器2 把锁误删除。 为了解决上述问题 我们可以引⼊⼀个校验 id。
⽐如可以把设置的键值对的值 不再是简单的设为⼀个 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).equals(serverId)) {redis.del(key);
}但是很明显解锁逻辑是两步操作 “get” 和 “del”这样做并⾮是原⼦的
引⼊ lua
为了使解锁操作原⼦可以使⽤ Redis 的 Lua 脚本功能 使用事务能解决这些问题但实践中往往用更好的方案就说 lua 脚本这是 redis 内嵌的脚本。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 节点针对这些组 redis 都加锁。在写锁的时候需要设定操作的 “超时时间”。⽐如50ms。即如果 setnx 操作超过了 50ms 还没有成功 就视为加锁失败。 如果给某个节点加锁失败 就⽴即再尝试下⼀个节点
当加锁成功的节点数超过总节点数的⼀半 才视为加锁成功 如上图 ⼀共五个节点 三个加锁成功 两个失败 此时视为加锁成功 这样的话 即使有某些节点挂了 也不影响锁的正确性 那么是否可能出现上述节点都同时遇到了 “⼤冤种” 情况呢? 理论上这件事是可能发⽣的 但是概率太⼩了。⼯程上就可以忽略不计了 同理 释放锁的时候 也需要把所有节点都进⾏解锁操作。(即使是之前超时的节点 也要尝试解锁 尽量保证逻辑严密)
简⽽⾔之 Redlock 算法的核⼼就是 加锁操作不能只写给⼀个 Redis 节点 ⽽要写个多个!! 分布式系统中任何⼀个节点都是不可靠的。最终的加锁成功结论是 “少数服从多数的”。
由于⼀个分布式系统不⾄于⼤部分节点都同时出现故障 因此这样的可靠性要⽐单个节点来说靠谱不少
其他功能
上述描述中我们解释了基于 Redis 的分布式锁的基本实现原理
上述锁只是⼀个简单的互斥锁。但是实际上我们在⼀些特定场景中 还有⼀些其他特殊的锁 ⽐如
可重⼊锁公平锁读写锁…
基于 Redis 的分布式锁 也可以实现上述特性。(当然了对应的实现逻辑也会更复杂)
此处我们不做过多讨论了
实际开发中 我们也并不会真的⾃⼰实现⼀个分布式锁。已经有很多现成的库帮我们封装好了 我们直接使⽤即可
⽐如 Java 中的 Redisson C 中的 redis-plus-plus。当然 有些⼤⼚也会有⾃⼰版本的分布式锁的实现
