bigbyto

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

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

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

@sujin190 不知道你们有没有压测的数据，这种设计在一定的节点下能承载多高的并发下单量？其实我想表达的是，如果大量请求传到了下游，就会出现多个事务竞争行锁的问题，这样系统的吞吐量就会急剧下降。

@sujin190 再请教下你们实际场景有这样用过吗，对性能的影响有没有经过详细的测试验证。

想一下你提到的美团场景，实际上美团商家经常会有一些特价商品，如果是一些热门商家，多个用户都会选择这个特价商品再加上其他商品，如果是这种场景，这个热门商家的锁几乎是被穿透了？大量的请求都获得了锁，是否会把下游的服务击穿？

@BBCCBB 服务在释放锁的时候就能感知到锁不属于自己了

@sujin190

"实现正常的都是对需要操作的资源加锁而不是对服务加锁，这种情况下并不是全局锁，冲突率实际是极低的"
这一点我请教一下，你们实际锁的使用是如何设计来达到你描述的冲突低的。 实际上有很多场景我们操作资源并不是对单一资源的操作，如果对多个资源分别加锁，这就很容易出现死锁。

不管是使用 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 内部的实现的逻辑时钟，因此更加安全。

开发机都要 32g 起步吧。苹果就是那么鸡贼，也没办法，上了他的贼船，只盼 intel 争气一点，让 mac 更便宜一些。

这个功能经常间歇性抽风，原因不明。话说我的 iphone13 好像一整年没失效过，以前总老的设备容易失效。