我自己想了个场景，无限的流量冲击下的购买商品，类似于双 11 ，以及解决方式
面临无限大的流量冲击下的下单服务 首先排除使用队列，因为要保证对用户的实时性； 其次排除限流，前提就是不想错过任何一个流量；
只能利用 redis 去控制库存，在库存为 0 后，还要面对大量的 redis.get(key) > 0 的单纯的判断操作，这时候，只能去无限增加 redis 的服务器去分 key ，同时需要做到自动化扩容。
最终的瓶颈就是 redis 服务器的数量。但是真的可以做到自动化扩容 redis 分 key 的这个操作吗
 |
1
Jooooooooo Feb 24, 2022
"首先排除使用队列，因为要保证对用户的实时性"
看不到收益在哪...用户多等 5s 难道就不去买这个 1 块钱的 iPhone 了吗? "其次排除限流，前提就是不想错过任何一个流量" 你能立马就卖出去 10 份东西放进来 100 份流量干嘛? |
 |
2
NoNewWorld Feb 24, 2022
、。。。最终解决方案肯定是限流啊
|
|
3
NoNewWorld Feb 24, 2022
@zsyubo393 怎么可能不限流？大部分流量都是重复无用的，硬抗下来不值得
|
 |
4
displayabc Feb 24, 2022
@zsyubo393 能做限流，就能做查询库存为 0
|
 |
5
yibo2018 OP @Jooooooooo 首先说一下大前提，我考虑的就是极限情况，你也可以认为我钻牛角尖，但在终极项目面前，这些是一定要考量的
回答下你的问题 1. 看不到收益在哪...用户多等 5s 难道就不去买这个 1 块钱的 iPhone 了吗? 用户既然能在 5 秒前就买到，为啥要增加变数？ 2. 你能立马就卖出去 10 份东西放进来 100 份流量干嘛? 意思是我库存有 10 份，我直接从网关的层面去限流 10 个请求进来？这样其实挺好的呀，这方便我不是很了解，想问一下用什么技术？成本是什么？ 扩大下，如果有 100W 个库存，那我从网关控制 100W 个请求进来，这时的瓶颈也是 redis 吧！ |
|
6
displayabc Feb 24, 2022
@yibo2018 redis 可以集群，可以多个集群，从客户端进行分片，1000 个节点，按每个 5 万 QPS ，这就 5000 万了
|
 |
7
x8 Feb 24, 2022 via Android
无限流量什么意思，你的服务器要抵御阴离子炮轰击? 建议上 AT 立场
先谈剂量，再谈毒性 先谈规模，再谈设计 |
 |
8
leon0318 Feb 24, 2022 via iPhone
先不说业务，纯技术角度，用 redis 事务怎么保障？
|
|
9
yibo2018 OP @zsyubo393 想了下，就假设是淘宝，双 11 ，有几百万商品，请求量就可以看成是无限的，在这个时候对总的流量进行限制，那意味着有的人点了没反应？或者是点了提示稍后再试？如果能容纳的流量是固定，那再超过这部分流量的所有用户都被限制了，这样也不好吧
|
|
10
NoNewWorld Feb 24, 2022
@yibo2018 那就是 redis 集群吧，搞个 100 个，至于自动扩容，redis 扩容要重新分片，这个不知道大厂有做什么处理，不是基础架构看不到。redis 抗住了，100w 的话，应用服务也够呛，折中就是 mq 吧。牺牲实时性
|
|
12
yibo2018 OP |
 |
13
libook Feb 24, 2022
最终瓶颈是市场容量，比如对于淘宝来说市场基本限定在中国地区，人口基数和购买力是有限的，性能不够改销售策略、堆机器和优化服务治理总能够扛得住。
计算机领域没法解决“无限”的问题，不同体量等级可能需要用完全不同的方案，说“无限”的话，64bit CPU 第一个说搞不了。 |
|
17
NoNewWorld Feb 24, 2022
@yibo2018 淘宝不知道，他们貌似是自研的，不是 redis
|
|
18
displayabc Feb 24, 2022
@yibo2018 创建新的 redis 节点，加入某集群，这种不需要修改代码，也不需要重启
创建新的集群，直接走配置中心，下发新的集群地址 |
 |
19
felixcode PRO  4
点下单按钮后，让用户玩大转盘，转好了减免两毛钱，系统还是忙的话，奖励再转一次。
|
|
21
libook Feb 24, 2022 1
淘宝的目标不是营收越高越好，因为涉及到短期利润和长期利润的问题，竭泽而渔可能短期利润高，但长期利润会受损，所以每年双十一淘宝都是有一个确定的销售额目标的，在整个购物节过程中会随时动态调整销售策略，以确保销售额不多不少刚好落在目标上面，进一步确保逐年收益稳步上升，这个涉及到大量的经济学和商学知识。
阿里的云计算做得很强了，弹性伸缩和优雅降级已经相当成熟了，甚至都包装成商品拿出来卖了，各个中间件也是从系统 Kernel 开始进行深度定制化，确实不能用现有开源方案的情况来推论。 所以我的猜测是，因为每年淘宝的销售额目标是确定的，所以服务资源是可以预估出来的，在购物节之前该买服务器买服务器，改调整资源比例调整资源比例，再结合各种 SRE 工作，使得购物节可以按照预期进行。 比如需要多少内存 Cache （类似于 Redis ），在各种情况下的扩容预案及相关自动化方案，都是在购物节之前就安排测试好的，你让淘宝去撑无限压力，他们也撑不住。 有个概念叫“优雅降级”，你可以搜一下，不追求技术上的完美，只追求核心业务指标。 |
|
22
Jooooooooo Feb 24, 2022
@yibo2018 做事情考虑成本啊. 就算是淘宝也不会去考虑一秒有 100 亿请求的场景.
|
 |
23
yzbythesea Feb 24, 2022
以前在的公司电商，也有类似抢货
我记得是购物车和下单分开的，购物车的库存是最终一致性，下单的库存是强一致性。很多客户都可以加进购物车，但是最后付款下单那一刻会显示无库存。而下单就是用队列，先到先得。 无限扩容 redis 是个伪命题，因为 redis 内部负担不了这么高的并非。 |
 |
24
dzdh Feb 24, 2022
|
|
25
dzdh Feb 24, 2022 1
@yibo2018
就不说双十一，就说淡的出鸟的淡季你也跟淘宝没得比啊。不用扯 [终极] 。量都不对等怎么做方案。 再说，真的抢购秒杀，就个位数库存那种，你点击的瞬间提示你 [已售罄] ，真的是 [已售罄] 了吗？你猜是不是你已经被随机筛掉了。你是不是想问，凭什么随机，万一我一刷新发现还有库存呢？那你想有没有一种可能是淘宝敢这么做是因为他真的有那么大的量， [必然] 随机筛掉一批后，再刷新就真的 [已售罄] 了？ 至于你，你就不能这么干（不是可以不，是不可以），因为你的量不够，但是你就可以直接的用 redis decr 对 redis 还 0 压力你信不信。 然后没有 [万能] 方案，没有任何一个 [方案] 可以随意放到任何地方任何场景 不做改动或者随便做点啥改动 就能 100%契合场景的。 一个项目前期你就必须要直连库，你就不能（不是可以不，是不可以）用缓存你信不信，用缓存反而增加开发成本，还不如直接连数据库 update set stock = stock-1 了。 到后期你就必须上个缓存（数据库集群也顶不住），不上的话用户打开首页就要 1 分钟那种。 在往后你就不准考虑技术向问题（不是可以不，是不可以），你还想考虑技术问题？你不考虑跟投资人咋安排下季度方案讨论上季度财报你还有心思考虑 我 这个 服务器 cpu +20%了还能不能顶得住？ -_- |
 |
27
IvanLi127 Feb 24, 2022 via Android
不可能队列都没有
|
|
28
IvanLi127 Feb 24, 2022 via Android
擦，不小心发出去了。。。
没队列和大学抢课的网站有什么区别。。。 |
 |
29
neilyoone Feb 24, 2022
你这样的场景 最适合用 MQ 来抵挡流量冲击
MQ: Kafka 、RocketMQ 功效: 削峰、解偶、延时消费 用 redis 来堆是什么操作? 限流是针对 DDOS 攻击、刷单用到的 |
 |
31
xuanbg Feb 25, 2022
最终方案肯定是能卖多少卖多少啊，货发不出去可以厂家代发货啊。
|
 |
32
Felldeadbird Feb 25, 2022
楼主排除了限流手段，只能无限推大服务器 IO 了。所以扩容方案得提前做好了。我感觉这个不是单纯 redis 可以完成。
|
 |
33
fishDD Feb 25, 2022
模糊的正确：商品总量就这么多，那大概流量是不是 5 倍 还是 10 倍 亦或者 20 倍流量呢。
准确的错误：对每一个流量负责。 |
 |
34
mayli Feb 27, 2022 via Android
无货就直接无货，这个是刷猴的瓶颈吧
|
Select Language