电商问题的最终瓶颈

[yibo2018]

我自己想了个场景，无限的流量冲击下的购买商品，类似于双 11 ，以及解决方式

面临无限大的流量冲击下的下单服务 首先排除使用队列，因为要保证对用户的实时性； 其次排除限流，前提就是不想错过任何一个流量；

只能利用 redis 去控制库存，在库存为 0 后，还要面对大量的 redis.get(key) > 0 的单纯的判断操作，这时候，只能去无限增加 redis 的服务器去分 key ，同时需要做到自动化扩容。

最终的瓶颈就是 redis 服务器的数量。但是真的可以做到自动化扩容 redis 分 key 的这个操作吗

[Jooooooooo]

"首先排除使用队列，因为要保证对用户的实时性"

看不到收益在哪...用户多等 5s 难道就不去买这个 1 块钱的 iPhone 了吗?

"其次排除限流，前提就是不想错过任何一个流量"

你能立马就卖出去 10 份东西放进来 100 份流量干嘛?

[NoNewWorld]

、。。。最终解决方案肯定是限流啊

[NoNewWorld]

@zsyubo393 怎么可能不限流？大部分流量都是重复无用的，硬抗下来不值得

[haython]

@zsyubo393 能做限流，就能做查询库存为 0

[yibo2018]

@Jooooooooo 首先说一下大前提，我考虑的就是极限情况，你也可以认为我钻牛角尖，但在终极项目面前，这些是一定要考量的

回答下你的问题
1. 看不到收益在哪...用户多等 5s 难道就不去买这个 1 块钱的 iPhone 了吗?

用户既然能在 5 秒前就买到，为啥要增加变数？

2. 你能立马就卖出去 10 份东西放进来 100 份流量干嘛?

意思是我库存有 10 份，我直接从网关的层面去限流 10 个请求进来？这样其实挺好的呀，这方便我不是很了解，想问一下用什么技术？成本是什么？
扩大下，如果有 100W 个库存，那我从网关控制 100W 个请求进来，这时的瓶颈也是 redis 吧！

[haython]

@yibo2018 redis 可以集群，可以多个集群，从客户端进行分片，1000 个节点，按每个 5 万 QPS ，这就 5000 万了

[lizon]

无限流量什么意思，你的服务器要抵御阴离子炮轰击? 建议上 AT 立场

先谈剂量，再谈毒性
先谈规模，再谈设计

[leonme]

先不说业务，纯技术角度，用 redis 事务怎么保障？

[yibo2018]

@zsyubo393 想了下，就假设是淘宝，双 11 ，有几百万商品，请求量就可以看成是无限的，在这个时候对总的流量进行限制，那意味着有的人点了没反应？或者是点了提示稍后再试？如果能容纳的流量是固定，那再超过这部分流量的所有用户都被限制了，这样也不好吧

[NoNewWorld]

@yibo2018 那就是 redis 集群吧，搞个 100 个，至于自动扩容，redis 扩容要重新分片，这个不知道大厂有做什么处理，不是基础架构看不到。redis 抗住了，100w 的话，应用服务也够呛，折中就是 mq 吧。牺牲实时性

[yibo2018]

@leonme lua 写个原子性操作包括：查询库存，减少库存

[yibo2018]

@zsyubo393 对，这就是我现在的疑点：自动扩容，redis 扩容要重新分片，这个不知道大厂有做什么处理
这个真的可以做吗。
至于用 MQ ，目前淘宝肯定没用

[libook]

最终瓶颈是市场容量，比如对于淘宝来说市场基本限定在中国地区，人口基数和购买力是有限的，性能不够改销售策略、堆机器和优化服务治理总能够扛得住。

计算机领域没法解决“无限”的问题，不同体量等级可能需要用完全不同的方案，说“无限”的话，64bit CPU 第一个说搞不了。

[yibo2018]

@haython 如果不够了咋办，可以做到自动扩容吗

[yibo2018]

@lizon 哈哈哈阴离子炮灰是什么鬼

[yibo2018]

@libook 没错，我只是在讨论最终的瓶颈问题，以及解决这个瓶颈的方式

[NoNewWorld]

@yibo2018 淘宝不知道，他们貌似是自研的，不是 redis

[haython]

@yibo2018 创建新的 redis 节点，加入某集群，这种不需要修改代码，也不需要重启
创建新的集群，直接走配置中心，下发新的集群地址

[felixcode]

点下单按钮后，让用户玩大转盘，转好了减免两毛钱，系统还是忙的话，奖励再转一次。

[leonme]

@yibo2018 这个只是保证原子性，可不是事务

[libook]

淘宝的目标不是营收越高越好，因为涉及到短期利润和长期利润的问题，竭泽而渔可能短期利润高，但长期利润会受损，所以每年双十一淘宝都是有一个确定的销售额目标的，在整个购物节过程中会随时动态调整销售策略，以确保销售额不多不少刚好落在目标上面，进一步确保逐年收益稳步上升，这个涉及到大量的经济学和商学知识。

阿里的云计算做得很强了，弹性伸缩和优雅降级已经相当成熟了，甚至都包装成商品拿出来卖了，各个中间件也是从系统 Kernel 开始进行深度定制化，确实不能用现有开源方案的情况来推论。

所以我的猜测是，因为每年淘宝的销售额目标是确定的，所以服务资源是可以预估出来的，在购物节之前该买服务器买服务器，改调整资源比例调整资源比例，再结合各种 SRE 工作，使得购物节可以按照预期进行。

比如需要多少内存 Cache （类似于 Redis ），在各种情况下的扩容预案及相关自动化方案，都是在购物节之前就安排测试好的，你让淘宝去撑无限压力，他们也撑不住。

有个概念叫“优雅降级”，你可以搜一下，不追求技术上的完美，只追求核心业务指标。

[Jooooooooo]

@yibo2018 做事情考虑成本啊. 就算是淘宝也不会去考虑一秒有 100 亿请求的场景.

[yzbythesea]

以前在的公司电商，也有类似抢货

我记得是购物车和下单分开的，购物车的库存是最终一致性，下单的库存是强一致性。很多客户都可以加进购物车，但是最后付款下单那一刻会显示无库存。而下单就是用队列，先到先得。

无限扩容 redis 是个伪命题，因为 redis 内部负担不了这么高的并非。

[dzdh]

@yibo2018 #12

> 至于用 MQ ，目前淘宝肯定没用

双十一 收银台 你运气好会看到一个中间页面 [您的请求正在被处理，请等待] 。然后等个十几秒或几十秒后会自动跳转到收银台。

[dzdh]

@yibo2018

就不说双十一，就说淡的出鸟的淡季你也跟淘宝没得比啊。不用扯 [终极] 。量都不对等怎么做方案。

再说，真的抢购秒杀，就个位数库存那种，你点击的瞬间提示你 [已售罄] ，真的是 [已售罄] 了吗？你猜是不是你已经被随机筛掉了。你是不是想问，凭什么随机，万一我一刷新发现还有库存呢？那你想有没有一种可能是淘宝敢这么做是因为他真的有那么大的量， [必然] 随机筛掉一批后，再刷新就真的 [已售罄] 了？

至于你，你就不能这么干（不是可以不，是不可以），因为你的量不够，但是你就可以直接的用 redis decr 对 redis 还 0 压力你信不信。

然后没有 [万能] 方案，没有任何一个 [方案] 可以随意放到任何地方任何场景 不做改动或者随便做点啥改动 就能 100%契合场景的。

一个项目前期你就必须要直连库，你就不能（不是可以不，是不可以）用缓存你信不信，用缓存反而增加开发成本，还不如直接连数据库 update set stock = stock-1 了。

到后期你就必须上个缓存（数据库集群也顶不住），不上的话用户打开首页就要 1 分钟那种。

在往后你就不准考虑技术向问题（不是可以不，是不可以），你还想考虑技术问题？你不考虑跟投资人咋安排下季度方案讨论上季度财报你还有心思考虑 我 这个 服务器 cpu +20%了还能不能顶得住？

-_-

[yogogo]

@felixcode 秒杀，前端流量随机砍一半，路由再一半，哈哈哈🐶

[IvanLi127]

不可能队列都没有

[IvanLi127]

擦，不小心发出去了。。。

没队列和大学抢课的网站有什么区别。。。

[neilyoone]

你这样的场景 最适合用 MQ 来抵挡流量冲击
MQ: Kafka 、RocketMQ
功效: 削峰、解偶、延时消费

用 redis 来堆是什么操作?
限流是针对 DDOS 攻击、刷单用到的

[jzphx]

@yibo2018 100w 的库存还抢啥

[xuanbg]

最终方案肯定是能卖多少卖多少啊，货发不出去可以厂家代发货啊。

[Felldeadbird]

楼主排除了限流手段，只能无限推大服务器 IO 了。所以扩容方案得提前做好了。我感觉这个不是单纯 redis 可以完成。

[fishDD]

模糊的正确：商品总量就这么多，那大概流量是不是 5 倍 还是 10 倍 亦或者 20 倍流量呢。
准确的错误：对每一个流量负责。

[mayli]

无货就直接无货，这个是刷猴的瓶颈吧