52 | 管理设计：分布式锁
陈皓
该思维导图由 AI 生成，仅供参考
你好，我是陈皓，网名左耳朵耗子。
我们知道，在多线程情况下访问一些共享资源需要加锁，不然就会出现数据被写乱的问题。在分布式系统下，这样的问题也是一样的。只不过，我们需要一个分布式的锁服务。对于分布式的锁服务，一般可以用数据库 DB、Redis 和 ZooKeeper 等实现。不管怎么样，分布式的锁服务需要有以下几个特点。
安全性（Safety）：在任意时刻，只有一个客户端可以获得锁（排他性）。
避免死锁：客户端最终一定可以获得锁，即使锁住某个资源的客户端在释放锁之前崩溃或者网络不可达。
容错性：只要锁服务集群中的大部分节点存活，Client 就可以进行加锁解锁操作。
Redis 的分布式锁服务
我们通过以下命令对资源加锁。
解释一下：
SET NX 命令只会在 key 不存在的时候给 key 赋值，PX 命令通知 Redis 保存这个 key 30000ms。
my_random_value 必须是全局唯一的值。这个随机数在释放锁时保证释放锁操作的安全性。
PX 操作后面的参数代表的是这个 key 的存活时间，称作锁过期时间。
当资源被锁定超过这个时间时，锁将自动释放。
获得锁的客户端如果没有在这个时间窗口内完成操作，就可能会有其他客户端获得锁，引起争用问题。
这里的原理是，只有在某个 key 不存在的情况下才能设置（set）成功该 key。于是，这就可以让多个进程并发去设置同一个 key，只有一个进程能设置成功。而其它的进程因为之前有人把 key 设置成功了，而导致失败（也就是获得锁失败）。
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线笔记
复制
AI
- 深入了解
- 翻译
- 解释
- 总结
分布式系统设计模式中的分布式锁管理设计是一个重要的技术话题。本文从分布式锁的必要性和特点入手，介绍了使用Redis实现分布式锁的方法和问题，并探讨了引入fence技术解决潜在问题的方法。此外，文章还讨论了从乐观锁到CAS的演进过程，以及分布式锁与乐观锁、CAS之间的关系。通过阅读本文，读者可以了解分布式锁的实现原理、存在的问题以及解决方案，对于分布式系统设计和开发具有一定的参考价值。 文章指出了分布式锁服务的初衷和几个概念性的问题，如锁的释放方式、高可用性和持久化需求、非阻塞方式的锁服务以及锁的可重入性。此外，还探讨了使用CAS等方式进行版本控制的情况下是否还需要分布式锁服务的问题。最后，文章强调了分布式锁服务在同步方面的作用，以及对读者提出了一些问题，引发读者对于锁服务的思考和讨论。 总的来说，本文通过深入浅出的方式介绍了分布式锁的设计原理和实际应用，对于想深入了解分布式系统设计模式的读者具有很高的参考价值。
仅可试看部分内容，如需阅读全部内容，请付费购买文章所属专栏
《左耳听风》，新⼈⾸单¥98
《左耳听风》，新⼈⾸单¥98
立即购买
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
登录 后留言
全部留言(44)
- 最新
- 精选
天天向上分布式锁 应该是 先获取锁 再进行业务操作 属于悲观锁 而用乐观锁代替 又演变为cas代替 这样合适吗？ 其实悲观和乐观 核心是面对的并发度不一样，如果在大并发下用乐观锁 应该失败的几率会增大，用悲观锁避免大量失败，但是会block！麻烦耗子哥 指导指导作者回复: 一切都是trade-off。不过实际情况下，乐观加上重试机制会好一些。
2018-05-08317
约书亚皓哥，这篇文章前半段一直到cas之前基本是在说redlock，后面说到fence和cas，恰恰是redlock争论当中反方的观点---如果你想锁的资源，能提供给你cas功能，那还要分布式锁干嘛？这也是我的疑问，我觉得是悖论 在我使用consul时，我发现，如果我要锁住一个资源，理论上100%安全的必要条件是，我的资源就是那个锁本身，在consul就是那个资源只能是锁住key对应的value。consul本身也提供cas，但对客户端来说，没加锁的代码容易写 但换成其他资源，这个悖论就显现出来了。我的想法对么？作者回复: 这篇文章其实我是在不断地变换思路解决问题，不能说Redlock没用，其至少可以同步不同的client。而你的理解是对的，如果是有共享资源，最好是在那个资源上提供无锁实现。
2018-04-1911
yun对资源修改，用cas而不是分布式锁，我反对 1:前提是共享资源的修改得提供cas,比如我要更新hdfs,然后再在hbase上更新meta,为了保证一致性，要用分布式锁 2，资源一存储在hbase,支持cas,资源二redis上，二者都支持cas,服务更新数据时要更新二者，服务是多个进城并发干，为了保证一致性，得有分布式锁，单个数据库的cas不行 cas和分布式锁是两个完全不同的东西，cas像是单机的乐观锁，能用cas的话，不用分布式式锁，那不废话吗？能单机干的，谁会上分布式 你跨多个服务，搞一个cas,试试？ 文中的令牌和cas，他们间确实类似。但是分布式锁中带令牌，就是为了解决，客户端认为占有锁，到实际锁过期的问题，此时没必要对比cas2019-06-191536- Randy现实生活中也有不需要更新某个数据的场景，只是为了同步或是互斥一下不同机器上的线程，这时候像 Redis 这样的分布式锁服务就有意义了 这句没明白，如果要进行互斥或同步操作，那就是要对同一个资源进行写操作，如果只是读操作那就不需要锁保护了，那分布式锁的意义是什么？2018-04-191328
林子如果用cas方式或者叫乐观锁来修改数据库中表（共享资源），会出现脏读问题，耗子叔，这点没提到。2018-07-09115
程序员Artistredis锁timeout确实是个问题，配合存储的版本控制一起做能解决数据准确问题。但是说存储上cas可以代替分布式锁，就不对了。分布式锁锁住的是计算过程和更新存储两件事，而cas只能管更新存储这一件事，也就是二者就不是一个级别的东西。再说锁住计算过程这件事在正常情况下是没有问题的，而当出现极端异常下的超时问题时，出现了同时计算，出现了冗余计算，这完全可以接受。2019-06-26611- 黄宸看完本章有点疑问，对于一般性的数据库修改都是有锁的，所以不存在并发问题，没必要用cas。而文中的redis分布式锁在使用过程中使用nx，px 实现了占位和过期的操作，从而达到分布式锁的效果。其中说到如果先持到锁的服务在一次执行中时间超时，锁释放；其他发现未执行完成，服务再次抢锁，此时存在两个服务都获得同一把锁，这时如果会出现更新覆盖的问题，个人觉得不能理解为分布式锁的问题，应该是程序设计上要考虑重复执行，或者如何去规避重复执行，或者执行补偿的问题。2020-02-1515
董泽润https://github.com/dongzerun/dlock 这是我在用的，redis lua 实现，和耗子叔的相似2018-06-214
王磊皓哥，有个问题想确认下，redlock是要求各个节点独立部署，都是master,那么这样的部署方式是否就限定这N台Redis不能同时作为缓存服务器了?2018-06-0814
华烬数据库用timestamp的判断是否冲突是有风险的吧2018-04-1914
收起评论
