系统设计之分布式锁（进阶必会）

楼主 redis cluster 是 ap，  分布式锁是cp， 你觉得可以用redis 吗?

针对 Redis，不知道最新的版本如何，但是在针对之前的版本，Redlock 是否能够提供可靠的分布式锁服务，DDIA 的作者跟 Redlock 的作者是超过一架的 https://martin.kleppmann.com/201 ... ibuted-locking.html。欢迎大佬提供更新的消息

本质还是hig availability 和 strong consistency 的trade off.  取决于你的应用场景对一致性的要求。

第一种使用DB 类似 redis(单线程), 实现简单， 但是性能不好，有single point of failure. 如果使用数据库集群，则依赖数据库的一致性。

第二种使用redis 集群 + 普通读写锁,  性能好，高可用性， 遇到network partition 会发生脑裂问题，但非强一致性（比如client1 从 master拿到锁， 但是接着master 挂掉，新的master 没有备份锁信息，client2 从新的master 拿到第二把锁)。 另外不建议使用redlock，具体看Martin 的文章https://martin.kleppmann.com/201 ... ibuted-locking.html

Redlock 个人理解本质还是zookeper类似的quraom 实现强一致性, 而且redlock 严重依赖系统时钟，但是网络延迟，clock drift, GC pause 都会造成 同一个时间有可能 多个client 拿到锁。大多数情况大家都是因为性能好才选择Redis，对数据丢失或者不准确可以容忍，没必要为了强一致性 选择redlock 凭空增加复杂度 降低性能。目前Redlock没有得到大规模验证使用。

第三种 consensus protocol
比如zookeeper + fencing token 可以实现强一致性, 代价是写性能不高 而且选举的时候可能不可用.
Kubernetes 基于etcd 的lease  https://kubernetes.io/docs/concepts/architecture/leases/

Wait for answers

前面很多答案都很优秀了。我再写个我的理解，同时增加下细节。
1. 用SQL的话就直接利用ACID特性。但是如果是单机SQL，就有SPOF问题。如果是分布式的SQL的话，就没有这个问题，但一般效率就比较差。如果你对SQL ACID很熟练，你也可以展开讲讲你的理解。实际上，要做好细节也非常多。

2. 用Redis的话，在新API加持下，可以直接set expiry，利用这个API加锁。Redis的QPS会比SQL高出很多（高多少，得会）。如果是用cluster Redis的话，那就会遇到分布式锁常见的一致性问题。Redlock是Redis分布式锁的一种实现。大概思想就是有N台机子，然后用拿到一半以上的锁就可以。当拿锁出现问题的时候，也要会处理。这里，大家可以自己搜下Redlock大概怎么work的。考官可能会问你可能情况下，怎么处理比较对。

（有人提到了这个Redlock是不是安全的这个对喷，有兴趣的可以去钻研下： https://martin.kleppmann.com/201 ... ibuted-locking.html， http://antirez.com/news/101）

3. 第三种就是利用zookeeper，chubby之类的。核心思想就是利用consensus。地里有个非常好的文章讲解这部分，我最不赘述了： https://www.1point3acres.com/bbs/thread-499338-1-1.html。

楼主可以写博客了感觉

感谢楼主和评论区分享～