电商问题的最终瓶颈

[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 这个只是保证原子性，可不是事务