20 | 高性能负载均衡：分类及架构

2018-06-12 李运华

《从 0 开始学架构》

课程介绍



讲述：黄洲君

时长:大小4.23M



单服务器无论如何优化，无论采用多好的硬件，总会有一个性能天花板，当单服务器的性能无法满足业务需求时，就需要设计高性能集群来提升系统整体的处理性能。
高性能集群的本质很简单，通过增加更多的服务器来提升系统整体的计算能力。由于计算本身存在一个特点：同样的输入数据和逻辑，无论在哪台服务器上执行，都应该得到相同的输出。因此高性能集群设计的复杂度主要体现在任务分配这部分，需要设计合理的任务分配策略，将计算任务分配到多台服务器上执行。
高性能集群的复杂性主要体现在需要增加一个任务分配器，以及为任务选择一个合适的任务分配算法。对于任务分配器，现在更流行的通用叫法是“负载均衡器”。但这个名称有一定的误导性，会让人潜意识里认为任务分配的目的是要保持各个计算单元的负载达到均衡状态。而实际上任务分配并不只是考虑计算单元的负载均衡，不同的任务分配算法目标是不一样的，有的基于负载考虑，有的基于性能（吞吐量、响应时间）考虑，有的基于业务考虑。考虑到“负载均衡”已经成为了事实上的标准术语，这里我也用“负载均衡”来代替“任务分配”，但请你时刻记住，...



展开全文

精选留言

鹅米豆发
2018-06-12
日活千万的论坛，这个流量不低了。

1、首先，流量评估。
       1000万DAU，换算成秒级，平均约等于116。

考虑每个用户操作次数，假定10，换算成平均QPS=1160。

       考虑峰值是均值倍数，假定10，换算成峰值QPS=11600。

       考虑静态资源、图片资源、服务拆分等，流量放大效应，假定10，QPS*10=116000。

2、其次，容量规划。

       考虑高可用、异地多活，QPS*2=232000。

       考虑未来半年增长，QPS*1.5=348000。

3、最后，方案设计。

       三级导流。

       第一级，DNS，确定机房，以目前量级，可以不考虑。

       第二级，确定集群，扩展优先，则选Haproxy/LVS，稳定优先则选F5。

       第三级，Nginx+KeepAlived，确定实例。
展开
作者回复: 思路不错👍👍
共 19 条评论
314
无聊夫斯基
2018-08-27
我还是不是很理解TPS和QPS具体的区别
作者回复: T=transaction，代表写请求
Q=query，代表读请求
共 4 条评论
69
孙振超
2018-07-21
这篇文章最大的收获是分析问题的思路，从dau出发，结合业务的特点，计算出来总的qps和tps，而后再根据通常规律计算出qps和tps的峰值，加上一定的未来发展空间和高可用冗余，结合单机能够支撑的qps和tps量，就可以计算出来整个集群的规模，有了这些数据就可以制定出比较合理的负载均衡的策略，而不是无的放矢，凭空猜测。

展开
作者回复: 最常用的方式
共 2 条评论
43
ant
2018-06-12
日活跃用户1000万应该就是国家级应用了，面向全国活跃或者全球用户，比如最大的Xxx网站github。这个时候钱应该都不是问题了。我觉得可以考虑异地多机房部署。这样导流之后每个机房的日活就少很多。其实我在想如果在每个机房不加入负载硬件用多个ngnix集群来实现，每个ngnix上会有我们自定义的路由算法。ngnix也架设多层，逐层导流，比如我们一个机房设计承受200万，那么我们可以架设3层ngnix，第一层基于自己的路由算法导流到第2层ngnix。第2层又导流到第3层。为了避免ngnix单点，每一层ngnix部署多。这样导流下流每台服务器所承认的访问不会很多。不知道这样的设计能不能达到要求，老师点评下
作者回复: 可以达到，但有点复杂，nginx做级联不太合适，因为顶层的nginx性能是瓶颈，多级导流一般用在处理能力有差异的系统上，例如一级用F5，二级用LVS，三级用nginx
共 3 条评论
24
plflying
2018-06-12
1、首先分析论坛系统的需求：高可用、扩展性、常规安全性、高性能。以上需求优先级依次降低。
2、并发计算：
    1）、首先计算每秒并发量：1000万/(10*60*60)=278qps. (此处每天按照10个小时计算)
   2）、计算每秒最大并发量：278*5=1390. （此处的5为经验值，按照论坛的用户使用特点多集中晚上小部分时段，该值已尽量取大。同时网上也有按照时间和并发数的二八原则计算，本人按照第一种计算）
3、容量规划：
    1、前端2台nginx负载均衡，利用keepalive保证高可用。同时可用做静态资源缓存服务器。
   2、后端tomcat部署应用，按照单台tomcat支撑1200并发，需要2台。考虑冗余，此处配置3台。
   3、考虑高性能应用可以集成缓存，也可以使用统一缓存。
   4、数据库采用mysql，使用2台进行主从复制和读写分离。一方面满足读多写少的应用场景，另一方面在1台出现故障时，能保证高可用。
以上内容请老师指正！
展开
作者回复: 1000万是用户数量，不是访问次数，访问次数会多很多，其它分析都可以
共 3 条评论
15
何国平
2018-06-14
nginx也支持4层反向代理了
作者回复: 我宁愿用LVS，久经考验，性能强大😄
12
食指可爱多
2018-06-12
请问老师后面会有容量规划方面文章吗？日活用户1000w转换成日请求量（这一步我没啥经验），再计算平均qps，考虑请求的波峰波谷，波峰取qps均值的5倍。1000x10000x10*24*60*60x5~5700得到qps峰值5700。不考虑后端应用层和更下层数据库缓存这些，接入层一个nginx就可以搞定了？
作者回复: 同样1000万日活用户，不同业务特点的QPS差异很大，例如抖音的访问量会明显高于支付业务，论坛业务明显高于工具类业务
共 2 条评论
13
老北
2018-07-08
千万日活，论坛的时间相对比较集中，同时在线预计会达到一百万。
这时候会有一半的人在操作(查看帖子之类)，每个用户操作可能会调用2-3个接口。那并发数大约就是50w*2.5=125w?

这时候nginx的5w并发就不行了。需要多个dns到不同主机，再进行nginx,lvs之类转发。
另外像tomcat一般支持2000左右连接数。这样就需要600多台tomcat？
总感觉哪里算的不对😂
展开
作者回复: 确实有点吓人，千万日活转换为百万同时在线这里有问题，一般把日活转换为pv，例如平均每个用户会访问100个页面，日访问量就是10亿，每秒就是大约1.2万的并发访问量，再按照峰值等于均值3倍来算，也就3.6万，远远没有125万那么夸张
共 2 条评论
9
低调的大老刘
2018-06-29
华哥，看到很多DNS+Nginx做负载，但是这种方式没办法预防DDOS攻击，你的Ip都暴露了
作者回复: 谁都没法防DDOS攻击呀，不暴露ip，正常用户也访问不了啊😄
6
一叶
2018-09-23
dear 华哥：文中说的一般的linux服务器 nginx 5w/s ，lvs 80w/s，这个一般的linux服务器能再具体一点吗，比如你们通常用的多少核多少g内存呢？3Q
作者回复: 与时俱进，现在基本都是32核48g内存了
共 2 条评论
5
交叉路口
2018-06-18
论坛这种业务的接口响应应该比较短，预计平均100ms ，超时限制500ms 。日活千万，预计峰值QPS 4000/s，按照超时500ms ，并发估算2000。采取dns+nginx 足够，具体实例根据 staging 压测来评估。dns 一是为了地理位置负载均衡，还有为了扩展性（客户端通过域名访问，后端需要拓展机器对客户端透明）。Nginx ：应用负载均衡，打到某个服务实例，利用其故障转移（可检测实例状态进行剔除）、并发限制等特性来保证服务稳定性，同时还可以利用它做其他事情（access log 做日志行为分析）。希望华哥指出不足😃
作者回复: 基本OK
4
互联网老辛
2018-06-13
并发测试如何来做，怎么知道自己设计的数据库，或者架构能支撑多少并发
作者回复: 基于业务场景进行性能压测，了解大概量级即可，不需要很精确
3
星火燎原
2018-06-12
不差钱的话可以考虑文中DNS +F5+ ngnix ，一般这种日活还是考虑DNS+LVS+Nginx
作者回复: 论坛不怎么赚钱啊😂
3
飞翔
2019-07-08
微服务的服务发现是不是也算一类负载均衡？
作者回复: 服务发现用了负载均衡
2
lyshrine
2018-10-18
老师画的这些有服务器的图，是哪那个软件画的？还是libreoffice？
作者回复: 是的，LibreOffice Draw
2
feifei
2018-06-13
日活跃用户千万，按14小时折算，每秒并发198，但这是平均，还有高峰时段，并发按平均并发5倍来估算，即每秒1千，然后来对比方案：

Dns负载，目前单机房能够满足，没跨机房的必要，dns目前不适用。
硬件负载，每秒几百万级的并非，很显然系统没有这么高的并发，硬件负载不适合。
软件负载，nginx单台能支持到5万的并发，当前系统,折算最高的并发也不过千级别。

经过方案的对比，软件负载使用nginx可以完全满足业务的要求，所以使用软件负载即可

展开
作者回复: 日活用户数！= 用户访问数，论坛类业务，一个用户一天可能访问几十个页面
2
公号-技术夜未眠
2018-06-12
通过容量规划，并考虑到高性能、高可用的要求，Web最前端可采用HAProxy+Keepalived双机(实现故障转移，保证高可用)作为负载均衡器；
后端的数据库架构采用MySQL一主多从，读写分离的方式，可采用LVS+Keepalived的方式实现读数据库的负载均衡与故障转移。
2
张玮(大圣)
2018-06-12
看了大家的各种计算，估容量，估机器，

想说的是：根据之前专栏讲到的单台高性能模式等知识，先把单台机器做到最优化，同时做好负载均衡层，然后进行压测，一步一步添加机器，均衡层 Nginx 够了，另外，要考虑成本啊，F5尽量不用，稳定性用双主克服下
作者回复: 最好算一下，当然有经验的架构师确实能够凭感觉预估
2
三月沙@wecatch
2018-06-12
不考虑多机房，不考虑不同地区，一个配置好点的nginx 就够了，防止单点，可以再加一台
作者回复: 1000万日活的业务，你真的要这么节省么？😂😂
共 2 条评论
2
肖一林
2018-06-12
峰值大概就是5000/s～20000/s，要看论坛活跃度。所以一个ng就够了。dns负载均衡也不一定就要支持异地多活吧，同一个机房多台主机也是可以的，所以最多dns+ng就可以很完美。需要异地多活的项目应该非常少。
作者回复: 这种方式也可以，dns做同机房多入口负载均衡
2