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