又被面试官问倒了，关于分布式锁

[badboy17]

今天面试官问我，他们用 redis 和 zookeeper 都用做过分布式锁，但是 redis 做分布式锁有高可用的问题，zookeeper 的能提供的并发量也有限，怎么解决这个问题 来 v 社问问大佬们，怎么思考

[awalkingman]

ETCD

[sunny1688]

redis 集群不可以吗

[badboy17]

@sunny1688 redis 只用集群的话，有死锁的可能吧，如果一个节点挂了的话，redis 官方提供了 redlock 的分布式锁解决方案，但是这个也有问题，有人质疑这个并不能保证分布式环境下的锁的安全问题

[q474818917]

这都 2202 年，还这么卷呢

[wdwwtzy]

听听大家的

[GopherDaily]

@newskillsget etcd 和 zk 在并发上的差距在两个量级以内，所以没有本质差别？

和这个扯淡的问题没关系

[dwlovelife]

redisson

[sadfQED2]

一个搬砖大头兵视角：别他么跟我扯那么多，在我这里，分布式锁就是 redis ，天王老子来了也是 redis 。什么，你说 redis 挂了怎么办？ redis 挂了关我屁事，那是运维的锅，反正不是我的锅，挂了直接甩锅给运维

[HunterPan]

这种问题 主要考察你的思路，对 redis 和 zk 等的机制优缺点能说出来基本也差不多了。

[Jooooooooo]

既要又要吗

[hidemyself]

说一下 redis 和 zk 做分布式锁的利弊
说一下你们为什么，基于什么考虑选择 redis/zk
就可以了

[badboy17]

@hidemyself 他问的是解决方案，不是问我他们的利弊，利弊他给我介绍了

[PythonYXY]

哪有什么银弹，只能做好业务兜底喽

[bigbyto]

不管是使用 redis 还是 zookeeper 作为分布式锁，结果必然是把所有并行请求串行化，这必然会带来一个非常严重的性能损失。如果获得锁的线程需要 10ms 完成一个任务，那么 10 个并发请求必然需要 100ms ，所以他说的“zookeeper 的能提供的并发量也有限”我表示怀疑，到底是他系统先到瓶颈，还是 zookeeper 先到瓶颈？

对于一个并行系统执行效率的评估，可以引用 csapp 中的一条公式
Ep = T1 / p*Tp

Ep: 相对效率
T1: 单线程执行时间
p: 线程数
Tp: p 个线程的执行时间

对于他的系统，解决单线程的执行效率才是最重要的，这就意味着不能串行化，要放弃使用锁。所以就需要评估他们业务系统对于锁的依赖有多重，是不是业务重要到必须不能出任何差错。

就拿扣库存这种业务场景，可以通过库存预热到 redis ，通过 redis 原子扣减库存，再通过异步任务把库存回写到数据库，达到数据的最终一致。

还有一点，redis 最致命的问题在于它不是可靠的锁，它依赖了系统时钟，在学术角度看，在某些情况下它是没法判断 2 个 event 之间的 happend-before 关系。 而 zookeeper 内部的实现的逻辑时钟，因此更加安全。

[ClericPy]

之前看过各种实现方案, 最后都是改架构不用锁解决的...

[zmal]

没听说这个 case 有解决方案了啊，有方案踢我一脚。
用 redis 时做好业务兜底，用 zk 时别要求效率。

[golangLover]

@badboy17 不用想了。大部分人没能力解决这个 red lock 的问题

[godfunc]

@bigbyto 不懂就问，扣库存的场景中，如果 redis 故障，会导致数据丢失吧

[likeme]

@ClericPy 不懂就问，不用锁怎么解决高并发带来的问题？

[7911364440]

貌似没有完美的解决方案吧，要我选的话就 zookeeper ，毕竟用 zookeeper 实现的分布式锁算是可靠性最高的了，而且有封装好的框架可以用，实现起来也很简单。