电商问题的最终瓶颈

2022-02-24 17:24:20 +08:00
 yibo2018

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

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

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

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

3160 次点击
所在节点    程序员
34 条回复
libook
2022-02-24 19:02:18 +08:00
淘宝的目标不是营收越高越好,因为涉及到短期利润和长期利润的问题,竭泽而渔可能短期利润高,但长期利润会受损,所以每年双十一淘宝都是有一个确定的销售额目标的,在整个购物节过程中会随时动态调整销售策略,以确保销售额不多不少刚好落在目标上面,进一步确保逐年收益稳步上升,这个涉及到大量的经济学和商学知识。

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

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

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

有个概念叫“优雅降级”,你可以搜一下,不追求技术上的完美,只追求核心业务指标。
Jooooooooo
2022-02-24 19:03:00 +08:00
@yibo2018 做事情考虑成本啊. 就算是淘宝也不会去考虑一秒有 100 亿请求的场景.
yzbythesea
2022-02-24 19:29:07 +08:00
以前在的公司电商,也有类似抢货

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

无限扩容 redis 是个伪命题,因为 redis 内部负担不了这么高的并非。
dzdh
2022-02-24 21:17:28 +08:00
@yibo2018 #12

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

双十一 收银台 你运气好会看到一个中间页面 [您的请求正在被处理,请等待] 。然后等个十几秒或几十秒后会自动跳转到收银台。
dzdh
2022-02-24 21:29:06 +08:00
@yibo2018

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

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

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

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

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

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

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

-_-
yogogo
2022-02-24 22:04:30 +08:00
@felixcode 秒杀,前端流量随机砍一半,路由再一半,哈哈哈🐶
IvanLi127
2022-02-24 22:14:31 +08:00
不可能队列都没有
IvanLi127
2022-02-24 22:15:30 +08:00
擦,不小心发出去了。。。

没队列和大学抢课的网站有什么区别。。。
neilyoone
2022-02-24 23:21:26 +08:00
你这样的场景 最适合用 MQ 来抵挡流量冲击
MQ: Kafka 、RocketMQ
功效: 削峰、解偶、延时消费

用 redis 来堆是什么操作?
限流是针对 DDOS 攻击、刷单用到的
jzphx
2022-02-25 08:44:10 +08:00
@yibo2018 100w 的库存还抢啥
xuanbg
2022-02-25 08:46:17 +08:00
最终方案肯定是能卖多少卖多少啊,货发不出去可以厂家代发货啊。
Felldeadbird
2022-02-25 09:54:18 +08:00
楼主排除了限流手段,只能无限推大服务器 IO 了。所以扩容方案得提前做好了。我感觉这个不是单纯 redis 可以完成。
fishDD
2022-02-25 18:33:47 +08:00
模糊的正确:商品总量就这么多,那大概流量是不是 5 倍 还是 10 倍 亦或者 20 倍流量呢。
准确的错误:对每一个流量负责。
mayli
2022-02-27 07:01:11 +08:00
无货就直接无货,这个是刷猴的瓶颈吧

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/836210

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX