真·百万并发的业务，是如何部署实现均衡负载的？

[black11black]

如题，很惭愧我没有部署过这种业务，纯粹想了解学习一下。

根据舅舅党的消息，19 年双 11 淘宝峰值 qps 在 340 万左右，考虑到支付宝的 query 逻辑还相当复杂，我是感觉挺人类奇迹的，那么到底是如何实现的呢？

按照我粗浅的推测，我感觉均衡负载目前可以分几个层级（暂不考虑 CDN，只考虑源服务器，以我粗浅的知识不太清楚这种有回源的服务挂 CDN 最终能否达到加速效果），

• 在最前面的应该是 DNS，大服务商的 DNS 做一些均衡负载的操作，智能分配数据中心之类的。
• 然后 IDC 里接机房，我猜测机房应该是直接作为 DNS 解析端点的，不太清楚 IDC 有没有整理输出的框架。
• 每机房内部若干台实体机器，以容器集群管理，解决机器内热点问题。然后每机房的出栈是通过一个汇总端口的反向代理？

=====================================================================

大佬给开开眼，想见识一下真正的工业前沿高科技是啥样的

[leonme]

简单点就是堆机器，但是牛还是要吹的

[wangbenjun5]

阿里不是年年都在吹，你找找相关技术文章就知道了，其实你看了也不会，因为凡是出来吹的多少都是经过修饰过的，你只能真正到了那个位置才明白

[janus77]

没有什么是加一层解决不了的，如果有就再加一层

[lhx2008]

首先肯定是多中心多活的架构，不同地域连的服中心是不同的，然后内部肯定也是分片，不同用户连的服务器是不同但是是相对固定的，所以现在问题其实简化了很多了，关键就是秒杀系统，库存系统怎么设计了

[lasuar]

第一级如你所说是 DNS 实现按地域分配二级 balancer 节点，第二级一般是 Nginx/F5/LVS 实现单区域数据中心的 API 网关（ HTTP/WS/TCP..）流量均衡，第三级一般还有一个 API 路由层负责对该 DC 业务集群的负载均衡，这里可以理解为 docker/k8s 集群=路由层+业务集群，再往下就是 DB 层的分流，sql/nosql/ob-sql，不同的 sql 再做 master-slave, sharding, replicats，负载均衡差不多就是这些，高并发业务中除了 lb 还有一个重点的点就是 cache 。

[areless]

没什么好惊讶的，计算机硬件构架本身就比所谓的互联网均衡负载要高科技一百倍。每一个大型游戏运行时计算机内部调度能力都比所谓互联网公司的均衡负载要先进……阿里本身就做 IDC,把主干网接在 PCIE4.0 上还要什么软件均衡负载啊？都是忽悠你们的。要扛并发 1 是海量带宽接入，2 是多烧内存、别用储存，3 硬要做均匀负载，请把你们机房的 100M 网线换换掉，用 10g 去组内网，还有 10g 要插在 PCIE2.0*4 以上的通道里，老服务器插不了几个的那种就该淘汰了。

[123444a]

10 万个容器左右，每个 qps 才 500

[laminux29]

你一上来就看百万并发，当然会满头问号。

你应该从最基础的开始，比如一个最基本的 C++ Server，用户一两百个。

然后不断地添加各种业务，业务有低负载的，有高负载的。

接着慢慢加用户。

然后再把用户平摊到不同的网络地域里。

接着再加数据，加业务，加用户，加到单机无法承受。

这样一步步来，你自己一步步思考，应该怎样做，会遇到什么问题。

当用户量和并发逐渐达到淘宝这个地步，你就会明白了他们大概会怎么做，以及为何这么做。

不过，难就难在，整个进化过程，你需要亲身体会，才会知道里面有多少坑。只是凭空想象，里面有很多实际问题，是无法想象出来的。

[lihongming]

并发不是问题，堆机器，通过 dns 、cdn 、和 load balancer 等手段把用户分散到不同的服务器上就完了。

但作为电商，数据一致性才是最重要的。你不能超卖，也不能没卖完就停了，订单的付款状态也必须是准确的，客户付了款还显示没付款的话会累死客服的。

网上有很多秒杀系统的设计方案，比如利用 redis 的单线程特性来实现单点库存管理等，还是挺有意思的。

[HuHui]

分布式的思维可以看看 spring cloud 和 k8s 能学到不少东西

[123444a]

秒杀不就几千件商品而已

[reeco]

堆机器就完了，也没什么特别的技巧

[xuanbg]

楼主这个问题就尴尬了……真的，如果你能够理解高并发的业务场景，你也就不会来发这个帖提出这个问题。

既然楼主你发了这个贴，那说明你对高并发场景根本就没有实际的概念。这样的话，我也没办法在这回复里面和你把这个事情说清楚……

事实上这个事情就没法简单地通过文字描述清楚，即使能描述出来，估计也没几个人能看懂，而且能看懂的那几个人也不需要看这些文字就能自己解决掉问题。否则，阿里那些 P9P10 们还有什么不可替代的价值呢？

[matrix67]

你看一下百度为了抗春晚加了多少机器。多少物理机。

[janxin]

分流堆机器啊

[opengps]

当然不是单纯的堆机器，我做过硬件设备通信的百万长连接，两台数据库服务器一台缓存服务器+几十台链接承载机器，虽然也是堆机器，但是软件也是要跟着做一堆扩容架构的。

一般的系统，服务器无状态化，数据库服务器，文件服务器全局共享，就足够应对大流量

但是流量继续增加，系统就需要更多的考虑不停机热添加实现加一层，还得是费不少心思的，像淘宝双十一那种峰值，能达到一个大型数据中心级别的系统终归还是极少数。里面必然还有些非内部人士不清楚的分流措施

[huayumo]

这玩意吧,水到渠成,逼着你进步,等你有这么多并发的时候,你不断尝试,就摸索出来了

[nnqijiu]

没有这个需求的时候强行搞也没用，美团创业初期也是阿帕奇一条龙搞定，后面壮大了才会搞各种分布式

[9]

多关注下别人在大会上的分享，一些优秀的设计，经过实战检验的经验已经分享出来了，为什么还要去无根据的瞎猜呢？比如百度分享他们在春晚上的解决方案，场景可能跟淘宝的不完全相同，但是也可以从中学到不少东西的

[zhoudaiyu]

F5 等 硬件负载均衡

[lewis89]

@lihongming #9 秒杀其实根本不是一个技术问题，稍微有点脑子的程序员直接给你 return 掉了 谁还给你去查 redis 不是老子有病，然后放几个随机数，成功的让它的订单走过去 然后改个状态

[paoqi2048]

分就完事了

[xuanbg]

@lewis89 没错，秒杀和高并发压根就八竿子打不着，还有瞬间峰值也是，拿 MQ 做个缓冲池就解决了。

高并发场景都是非常特殊的，各有各的解决方案，看别的人的方案最多起一个参考作用，没有一家是能照搬的。

[xuanbg]

@9 别人的经验没用的，大家都知道分流，但这就是正确的屁话。真正的问题从来就不是怎么分流，而是分流后产生的问题要怎么去解决。那些分享从来都只会说我们如何分流，不会告诉你分流产生了什么问题。其实也很容易理解，因为分流后的问题大家都不一样，你说自家特有的东西，别人也没兴趣听。

[salmon5]

这个问题首先要考虑的是一个字：钱；
上万人的工资；
上百万台的服务器、存储、路由、交换、防火墙硬件。
你算算这 2 个多少钱。

[andynet]

然后可以看一下 google 出的 SRE 那本书 里面有一些设计思路可以参考
然后就是 现在的很多公司对分布式都会过度构架，还是那句话 构架需要演进，到那步就部署适应的构架。

[OneMan]

从基础来，不要一下就想造个战斗机，先弄个模型飞机能飞起来就不错了

[black11black]

@lasuar 大佬回复靠谱，能感觉到一个成熟模型了

[black11black]

@xuanbg 你这回复了一长串没有任何建设性意义啊，没有谁生而知之的，总归是共同讨论共同进步，你说我不懂我确实也没架过这种业务，但我想了解一下总不能说是就犯罪了吧。如果是建设性讨论，比如你可以指出来我高并发场景理解错误，重点不在并发 IO 而在于虚拟数据库，或者在一致性。你这写了一长串总结出来就是“你不懂，说了你也听不懂”，有个啥用

[reeco]

淘宝那鬼代码看过你们就明白了，也是很多屎山在里面，没人敢动

[reeco]

部署架构的两个关键字： 单元化、异地多活，应该都能搜到不少东西

[Lonely]

@areless 你就一台服务器去抗？

[ceyes]

关键字：c10k 问题，可以研究一下。

[losephsky]

许式伟的架构课有一章就讲到高并发的负载均衡，推荐你去看看

[neoblackcap]

@black11black 理论上是你也只能根据网上分享出去面试吹水，然而真正的大厂面试官面对你吹这些，立刻就会打脸，还不如不吹。所谓经历过百万并发的人，在中国也屈指可数，v2ex 上面大部分的程序员都没有这样的经验。这根本就是屠龙技。哪怕腾讯那样的企业，一般人是不可能允许你去写对应的代码的。
了解一下是可以的，不过百万并发是一个非常空泛的议题。长连接跟短连接都不一样。游戏的百万在线，跟网页的百万并发浏览，整个逻辑思路可能都不一样。
当然大家都会在说分流，但是不同的业务会导致不同的资源需求。真正经历过百万并发的人或者架构师是需要深入业务，评估资源的需求。不是一句简简单单的加机器，上商用软硬件就可以打发过去的。没有实际的业务场景，理论简直是空中楼阁。当然你有这样的问题，恭喜你，你很可能在一家朝阳企业。

[marcoxuu]

阿里出过一本书叫做《逆流而上-阿里巴巴技术成长之路》介绍了 lz 主题中提到的几个问题

[dreamusername]

阿里云 SLB 负载均衡单条最高 100 万并发，后面使用 Kubernetes，服务性能不够，数量来凑，这样百万并发就出来了.
SLB 前面再使用 WAF DNS，几百万就出来了。

[God365]

@andynet 现在的很多公司对分布式都会过度构架，还是那句话 构架需要演进，到那步就部署适应的构架。
非常同意，适合当前阶段和规模就是最好的，构架需要根据业务增长演进

[qiyuey]

去 HTTP 化，分布式 MTOP

[xuanbg]

@black11black 你理解的“你不懂，说了你也听不懂”并没错，但这个并不是我傲慢、不愿意分享或者看不起人。有些东西没有经历过就是理解不了，也很难描述，百万级并发恰好就属于这个范畴。做过的人都不会认为搞定这个是掌握了什么高大上的知识，而仅仅是一些令人焦头烂额的各种尝试和妥协罢了。这种经验没有复制的价值，也并不值得炫耀。当然，也不值得学习。

[1194129822]

你小瞧了 money 的力量，双 11 的压力主要是凌晨大规模的 OLTP, 但是下单之后并不能马上退款，减轻了一些场景压力。我在一篇博客上看到微信开发分享的红包架构，一代面向用户开放的的时候，过于火爆，没有什么架构设计直接所有压力全在 mysql 数据库，后来增加几千个节点硬撑。后来重构引入缓存和内存计算。所以所谓高并发，当遇到这个瓶颈之后，自然有解决办法。只要有钱，没什么解决不了的。12306 这种网站，事务要求太高，所以几乎全是内存计算，单个节点的内存单位都是 TB 级。

[akira]

几百并发都能搞死一片人的。。。

[lihongming]

@akira 同意，百万级的日访问量也就是 10-30 并发，绝大多数企业没机会体验百级以上的并发。

偶尔做个活动，搞个楼上说的那种用随机数决定过不过的伪并发也就糊弄过去了。真正的高并发场景太少了

[IMCA1024]

@lihongming redis 那个我去搜了下 看到某乎一主题下面回答的 好像还挺有道理

聿明 leslie
蚂蚁金服 OceanBase 工程师:

18 年的回答
减库存的场景中阿里没有听说用 redis 的，都是直接写数据库，减库存的瓶颈主要是来自于一个比较热的商品，大量并发的去抢，比如热门商品的秒杀，并发写同一个商品会带来大量的热点行锁冲突，导致 TPS 下降，阿里优化的 MySQL 分支（ alisql ）和 OB0.5 使用的策略都是用一个缓冲队列，如果不同事务想加锁同一行，就将这批事务去排队，避免大量争锁的代价，OB1.0 版本的思路要做得更彻底一些，提前释放行锁，这个做法的难点在于要分析出事务的依赖关系，行锁提前释放了，不能破坏事务隔离性

作者：聿明 leslie
链接： https://www.zhihu.com/question/268937734/answer/351683594
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

[Aresxue]

CDN -> DNS -> 硬件负载如 F5 > 软件负载如 nginx 和 lvs -> 应用负载如 dubbo 的请求分发(默认随机)和 SpringCloud 的 Ribbon

[salmon5]

可以，1 个程序员顶 1000 个程序员。

[stevenkang]

逢山开路，遇水架桥，水到渠成。

[ArtIsPatrick]

你要知道，因为瞬时流量过大，许多秒杀的实现并不是最先点按钮的人抢到，而是随机的让一部分人抢到。有时候前端甚至都没请求后端的接口就告诉你秒杀已经结束了。所以秒杀其实本质上和抽奖差不多。双十一下单的时候提示当前下单人数过多也是同理，它只请求了一个速度极快的仅返回当前服务器负载情况的接口，并没有请求下单接口。

[fcten]

关键词：分布式系统。负载均衡只是其中的一小部分。