这是一个创建于 1648 天前的主题，其中的信息可能已经有所发展或是发生改变。
我看，秒杀的一些系统设计，似乎都是根据商品 ID hash 到同一个逻辑节点，然后在逻辑节点里面，排队处理
那么为什么不是分散到其他节点，基于分布式锁来处理呢？一样可以保证一致性
目前在想，是不是因为，如果基于分布式锁的话，那么没有抢到锁，只能返回秒杀失败，这样可能导致，商品依旧有库存，但是因为抢的时候，刚好有其他用户抢锁了，导致秒杀失败
谢谢
第 1 条附言 · 2020-05-21 03:06:49 +08:00
另外一个，就是如果用分布式锁的话，貌似就可以动态扩容了，如果是 hash 到同一个节点，要怎么加机器？新旧请求 hash 到不同节点吗？如果是这样的话，那么像微信抢红包的，520 的时候加一堆机器，要等到 522 凌晨才能释放？有点太浪费了吧？
 |
1
kop1989 2020-05-20 23:17:43 +08:00  1
因为秒杀的关键不是高性能逻辑，是减轻服务器压力。
单线程排队，甚至是请求抽奖，都是节省服务器压力为目的。并不是为了高效处理队列。 |
|
2
kop1989 2020-05-20 23:22:41 +08:00
举个不恰当的例子，程序员去大厂面试。为何是排队一个一个面，而不是根据来的人数动态匹配面试官？
因为对于公司而言，占用 10 个人 30 分钟，和占用一个人 300 分钟，产能影响、面试结果准确度等结果是不同的。 而最终目的却相同（给一个人发 offer ）。 那作为公司而言为什么要做出对自己不利的面试策略？ |
 |
3
luckyrayyy 2020-05-20 23:28:27 +08:00 1
性能啊，几十万个请求抢一个锁，画美不看。
|
 |
4
EPr2hh6LADQWqRVH 2020-05-20 23:33:13 +08:00 1
就随便收集请求 random 一下算了，别跟自己过不去。
|
 |
5
night98 2020-05-20 23:39:23 +08:00 1
基于分布式锁会存在抢占锁的问题，多个线程等待锁释放耗费的性能也是很高昂的代价，所以直接 hash 到单个节点排队处理，超出队列大小的还能直接返回失败，相比分布式锁会要少很多的内网请求。记住，高并发的原理就是尽可能做最少的事情，能走内存访问的不要走网络访问，能走网络的不要走 io，当然这种场景可以参考下无锁队列进行实现。
|
 |
6
jugelizi 2020-05-21 07:08:59 +08:00 via iPhone 1
看上去是没趟过分布式锁的坑
|
Select Language