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

[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 等 硬件负载均衡