共计 2835 个字符，预计需要花费 8 分钟才能阅读完成。
这篇文章主要介绍了 Redis 中 Redlock 的示例分析，具有一定借鉴价值，感兴趣的朋友可以参考下，希望大家阅读完这篇文章之后大有收获，下面让丸趣 TV 小编带着大家一起了解一下。
为什么要用锁
我待过的一家 k12 教育公司，我们当时有个业务场景是这样的。业务这边要给学生排课，偶尔会反馈学生的课时明明充足的但是却提示课时不足，等再刷新一遍页面却发现学生的课时已经不够了。更可怕的是，偶尔会有学生的课时被扣成负数(公司被白嫖课时)。
再比如下面这个例子
上面的这俩个问题都是并发给我们的业务带来的问题。解决这个问题的核心就是，同一时间只能允许有一个请求来对这些敏感 (重要) 的数据进行读写操作。所以这个时候就要使用到分布式锁来限制程序的并发执行。
setnx 有哪些问题
我们先来看看用 Redis 如何实现分布式锁，想必大家都很熟悉。比如针对我文章开头讲的学生排课的问题我们就可以这样加锁
这就是我们常规使用 setnx 来实现锁的方式。
现在我们假设有这样一个场景。A 请求拿到锁到了第 2 步给学生排课的时候程序挂了，没有释放锁。那么这个锁就成了死锁，下一个操作同一个学生的请求永远就拿不到锁，那么这个学生就没法被排课了。这个时候都需要手动去把锁释放掉。
为了解决死锁的问题，我们给锁加一个过期时间。
加上过期时间之后，如果 A 请求没有主动释放锁，在锁过期之后也会主动释放，这样 B 请求一样可以获取锁处理业务逻辑。但是如果在加过期时间的时候也就是在第 1 步和第 2 步之间程序崩溃。那还是会出现死锁的问题。这个问题的根源就在于 setnx 和 expire 这两条指令不是原子指令。所以如果 setnx 和 expire 能够要么全部执行要么一个都不执行那该多好。
为此在 Redis2.8 之前社区涌现了一大批扩展包来解决该问题。官方为了治理该乱象，在 2.8 版本中加入了 set 指令的扩展参数使得 setnx 和 expire 指令可以一起执行，所以现在我们使用分布式锁应该是这样了
这样看起来已经很完美了，已经达成了我们的期望“setnx 和 expire 能够要么全部执行要么一个都不执行那该多好”。我们再假设现在有如下场景：
A 请求现在获取到了锁，锁的超时时间设置的是 5 秒。到了第 2 步执行业务逻辑，结果因为某些原因 5 秒之后业务逻辑还没有执行完，此时锁由于超时自动释放了。这个时候 B 请求也来了，拿到锁之后开始执行业务逻辑。A 请求这个时候业务逻辑执行完了，开始执行第三步，释放了锁。而这个时候锁是 B 请求拿到的，结果被 A 请求释放了。那么 C 请求就可以拿到锁了。这个时候 B 请求和 C 请求就会导致并发问题了。所以可以从这个例子看出来，在分布式锁中过期时间的设置非常重要，如果设置的时间小于这个接口的响应时间那么仍然会产生并发问题。所以我们可以参考接口响应时长的监控来设置锁的过期时间。
Redlock
我们上述的方案都是基于单点的 Redis 的实现方式。单点的 Redis 实现分布式锁基本上可以满足 95% 的业务场景。剩下的 5% 就是对数据一致性要求极其严苛并且对于锁丢失的 0 容忍的业务场景。这个时候就得考虑 Redlock 了。至于单点的 Redis 即使通过 sentinel 保证高可用，如果这个 master 节点由于某些原因发生了主从切换，如果数据主从数据同步不及时那么势必会有数据丢失，那么就会出现锁丢失的情况。
假设存在多个 Redis 实例，这些节点是完全独立的，不需要使用复制或者任何协调数据的系统，我们假设有 5 个 Redis master 节点，客户端为了取到锁，步骤将会变成这样：
以毫秒为单位获取当前的服务器时间
尝试使用相同的 key 和随机值来获取锁，客户端对每一个机器获取锁时都应该有一个超时时间，比如锁的过期时间为 10s，那么获取单个节点锁的超时时间就应该为 5 到 50 毫秒左右，他这样做的目的是为了保证客户端与故障的机器连接不耗费多余的时间！超时间时间内未获取数据就放弃该节点，从而去下一个 Redis 节点获取。
获取完成后，获取当前时间减去步骤一获取的时间，当且仅当客户端从半数以上 (这里是 3 个节点) 的 Redis 节点获取到锁且获取锁的时间小于锁额超时时间，则证明该锁生效！
如果取到了锁，key 的真正有效时间等于有效时间减去获取锁所使用的时间（步骤 3 计算的结果）。
如果获取锁的机器不满足半数以上，或者锁的超时时间计算完毕后为负数等异常操作，则系统会尝试解锁所有实例，即便某些 Redis 实例根本就没有加锁成功，防止某些节点获取到锁但是客户端没有得到响应而导致接下来的一段时间不能被重新获取锁
所以我们看出，redlock 其实是比单点 Redis 看起来更加可靠的锁。
如果你跟我一样是 Node.js 程序员那么正好有第三方库 redlock 直接使用。
我们真的需要 redlock 吗
关于 redlock 其实也有另外一种声音，Martin Kleppmann(剑桥大学的研究员，从事数据库、分布式系统和信息安全交叉领域的 TRVE DATA 项目)写过一篇 blog 发表了关于对 redlock 的一些看法，感兴趣的可以看看。Redis 作者 Salvatore 也对这篇文章的疑问做出了一些回应，还挺有意思的。作者的 blog 主要的观点如下：
分布式锁的用途无非两种：
效率：使用锁可以避免不必要地做同样的工作两次（例如一些昂贵的计算）。如果锁定失败并且两个节点最终完成相同的工作，结果是成本略有增加（您最终向 AWS 支付的费用比其他情况多 5 美分）或带来轻微的不便（例如，用户最终两次收到相同的电子邮件通知）。
正确性：使用锁可以防止并发进程相互干扰并破坏系统状态。如果锁定失败并且两个节点同时处理同一条数据，则结果是文件损坏、数据丢失、永久性不一致、给患者服用的药物剂量错误或其他一些非常严重的问题。
如果是为了效率，则根本没有必要承担 Redlock 的成本和复杂性，锁丢失导致多发几次邮件和运行 5 个 Redis 服务器的成本相比，最好只使用单个 Redis 实例。如果你使用的是单个 Redis 实例，Redis 节点突然断电或者崩溃，或者出现其他问题，这个时候当然会丢失锁。但是如果你只是将锁用作效率优化，而且这种崩溃不会经常发生，那没什么大不了的。这种“没什么大不了”的场景是 也恰好是 Redis 优秀的地方。至少如果依赖单个 Redis 实例，那么查看系统的每个人都能够更方便的定位问题。
如果是为了正确性，那么严格来讲，redlock 根本不具有强一致的严格性。举了一些例子
时序和系统时钟做出了危险的假设，对每台服务器的时钟强依赖。因为有系统有 GC 的存在，做 GC 的时整个服务器是夯住的，时间也就停滞了，所以我们不能够对时钟有强依赖。
没有令牌。客户端每次获取锁的时候服务端没有下发令牌，服务端应该校验每次操作的时候客户端的令牌要与服务端当前的令牌一致才难操作锁。
感谢你能够认真阅读完这篇文章，希望丸趣 TV 小编分享的“Redis 中 Redlock 的示例分析”这篇文章对大家有帮助，同时也希望大家多多支持丸趣 TV，关注丸趣 TV 行业资讯频道，更多相关知识等着你来学习!
