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

[badboy17]

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

[bigbyto]

@sujin190 我个人的观点是只有在十分严谨的场景才会考虑用锁(比如涉及到金额)，对于下单的场景，使用 redis 之类的设计并发量能提升好几个数量级，这个缺点就是在极端情况下超卖和少卖选择一个。

我大概测试过 redis ，保守 6w 的原子扣减库存(lua)是很轻松的。

[sujin190]

@bigbyto #39 但是事务竞争行锁超过系统限值的问题，无论你用不用分布式锁都是要解决的，我并没有说分布式锁可以同时满足限流逻辑，其解决的仅仅是商品库存校验过程中的并发问题，当然设计合理的分布式锁可以提供限流服务，从系统结构上倒是可以简化有点，我们自己在实现的时候也是充分考虑了我们的流量上限的，而且数据库及其他服务都有连接池限制，超过之后也会 wait ，连接池限制了不可能突破底层数据库和服务的性能限制，所有就直接用使用的异步 IO 框架硬抗了

[bigbyto]

@sujin190 实际上 mysql 数据库的插入性能并不低，只要可以绕过行锁竞争，一台 4 核 8g 的服务器承受 1 秒 6000 条插入游刃有余。加上分表设计，并发下单性能就会非常可观。

[winglight2016]

这不是 CAP 的选择问题吗？ AP 或者 CP ？跟需求有关，没有哪个方案能同时满足 CAP

[sujin190]

@bigbyto #41 是的，并没有一刀切的通用方案，每个方案都各有优势，就看自己的需求了，如果允许超卖，redis 计库存也挺好的，我提这个方案只是觉得再大多数企业都不可能有美团淘宝这样的量，加锁是实现最直观并且使用产品需求最多又出异常可能最少的方案了

我们的加锁服务是自己实现的，相同机器上差不多能有 3-5 倍 redis 的 qps ，当然我们用的挺好，也不一定就适合你，开发容易维护简单适合自己需求才是真的

https://github.com/snower/slock

[sujin190]

@bigbyto #43 是的，mysql 的单行单字段的读写性能大概率比大家想的高多了，我们也是想就我们的电商需求不大可能超过 mysql 的单行读写性能，那么就只需解决并发异常就行了，真到了 mysql 都支撑不了了，我们都起飞了，有了资源还怕啥，哈哈

[jack778]

距离面试白板手写操作系统还剩 10 年。

[hhjswf]

cap 理论他不懂吗

[zhaorunze]

你说的已经是结论了，结论怎么解决呢？

[xz410236056]

@bigbyto #14 Ep = T1 / p*Tp 唤醒了上学的时候计算机系统结构中关于流水线的记忆。。

[zzzzzzZ]

本来就是个破八股，这种没水平的面试官就喜欢强行出截搭题，你这种给制度刷坏了的考生还真就把这截搭题当个宝。


腐儒，臭不可闻。

[badboy17]

@zzzzzzZ 我就是个初级程序员，面试官是蚂蚁的

[dayeye2006199]

好奇你面的这个职位是做什么业务的？

[ly11tea]

@badboy17

看来你之前没做面试题准备 我刚在 maimai 上搜 最起码 21 年 7 月份就有人面蚂蚁被问到这个问题了
因该是他们题库里的

[ly11tea]

@badboy17 https://mp.weixin.qq.com/s/ybiN5Q89wI0CnLURGUz4vw

[FrankHB]

@sujin190 “实现正常的都是对需要操作的资源加锁而不是对服务加锁”

这你可能太乐观了。都不用管啥分布式系统，这年头 GIL 都干不掉的运行时都满大街跑呢……
（当然搞 Java 的可能没那么倒霉，所以感知不强……）

[sujin190]

@FrankHB 我们现在讨论的是 web 类的无状态服务的状态同步加锁问题，和 gil 本来就不是一回事，和多线程编程也只是类比，并不完全是一回事

[FrankHB]

@sujin190 要怎么给解决方案，自然不是一回事。

但既然 @bigbyto 有从理论上提到这方面的问题，那我就顺带吐槽一下很多时候很基础的东西在一些情况下会被人莫名其妙地忽略掉。也许是被惯的。
至少“锁”这个玩意儿什么时候得用，其实这里是不用很关心具体哪个领域的，分析过程和结论都没什么变化。偏偏要直接上具体实例分析，反而无意义地削弱了结论。
反应得过来的话，就是个简单的锁的粒度的问题……但其实工程中你可能得容忍大多数基础设施的开发者在这里都没怎么拎清楚。

当然你也可以说，太理论了没必要，对从业人员兼容性太低，反而容易让人联系不到实际问题而抓不住重点。
这个也说得过去，不过你要提数据库的锁类比，已经相当抽象了。
而且数据库其实这方面是优等生，这里的期望扩展到其它领域是不那么靠谱的。

[zzzzzzZ]

@badboy17 阿里的也是个臭八股，阿里三四万程序员你以为个个都是人才呢？

如果你能真正在这行呆下去，过三五年回头看。这都是若智才会问出来的题。

面新手基础 /算法那么多东西好考，再不济找一些八股看看你理解能力也没问题。强行整这种截搭，暴露出他水平很低劣想在你面前装一波，但是水平有限装个 b 都没装好，属于是架构的门都没摸着的臭腐儒（阿里的）。

[badboy17]

@zzzzzzZ 他问我怎么做幂等，我说用数据库唯一键，然后他说数据库只能是插入场景可以用，修改的场景呢，我说做幂等就建一张幂等表，用业务的唯一 id 做唯一索引，不管是什么业务逻辑要做幂等，都可以用这张表做，我觉得他可能没理解数据库唯一键怎么做幂等，不过我觉得他问我的这个分布式锁的问题，如果让我这个工作了两年不到的程序员回答，有困难，但是我觉得问题有讨论的价值