12 | 高性能架构的三板斧：分析系统性能问题从哪里入手？
2022-03-14 李智慧
《李智慧 · 高并发架构实战课》
课程介绍
讲述：李智慧
时长:大小12.74M
你好，我是李智慧。
我们在讨论高性能架构之前，需要先聊聊什么叫高性能，以及如何量化地测试系统的性能。在02 讲中，我们讨论了一些和并发相关的指标。事实上，并发数正是系统性能的核心指标之一，因为高并发会引起系统资源短缺，来不及处理用户请求，就会导致系统性能下降。
除了系统并发数，一般说来，和系统性能相关的量化指标还有响应时间和吞吐量。在前面的案例分析中，我们也多次估算过响应时间和吞吐量。我们再重新回顾下这几个指标的定义。
吞吐量、响应时间和并发数三者之间是有关联性的。。并发数不变，响应时间足够快，那么单位时间的吞吐量就会相...
© 版权归极客邦科技所有，未经许可不得传播售卖。 页面已增加防盗追踪，如有侵权极客邦将依法追究其法律责任。
精选留言
郭硕2022-03-15老师的每篇文章都收益匪浅，了解了一种特定的架构方案，但是又感觉每篇点到为止，很多细节都没有探讨，而且感觉距离实际落地还有很大的距离，不知道老师有没有一些建议或者资料，能够让我们顺着老师的每节课更深入的学习每种架构方案？共 2 条评论3
HappyHasson2022-03-22二层负载均衡，返回消息给请求端是直接返回的，是需要后端服务器和请求端主动创建链接？这样会不会有直连风险？作者回复: 不需要创建链接，响应数据包还是走请求的路由通道，因为IP地址不变，网络层协议不受影响。
唐国强2022-03-17老师这里可以加上前提，垂直伸缩
peter2022-03-16请教老师几个问题啊： Q1：高并发标准是什么？多大的并发量算高并发？ Q2：负载均衡器单点问题怎么解决？ 如果负载均衡器也需要多个服务器，那么就需要在其前面加负载均衡器，如此递归，则为死循环，好像这个方法不行。那么，是采用两个机器互为主备吗？或者干脆就是一台，宕机后重启吗？ Q3：F5、LVS是几层负载均衡？ 买过老师的那本关于架构的书，几年前啦，现在不知道放哪里了。记得书中提过F5和LVS。那这两个是几层的负载均衡？好像记得书上说F5是硬件负载均衡；“硬件”负载的话，就不能说是某一层的负载均衡了，对吗？ Q4：多大规模的互联网公司（或用户数）需要CDN？ 什么级别的用户数需要用CDN？（也许是别的判断标准，不是“用户数”，而是“流量”等，就是说对是否需要采用CDN的标准不清楚）。更具体一点，像极客时间这样的公司需要用CDN吗？ Q5：针对应用服务器，tomcat性能是不是不如Jetty？ 比如tomcat处理速度比jetty慢、并发数比jetty低等（这两个方面只是举例，我并不清楚两者的区别） Q6：假设并发数五千，采用tomcat的话，需要几台服务器？（不考虑备份）。（是不是一台tomcat只能处理五百左右并发？记不清从哪里看到这个数字了） Q7：大型互联网公司的最前面入口是什么？ 在讲互联网架构的书籍和专栏中，会提到用户请求到达的第一个设备，比如Nginx、F5等等。即便快如F5，其处理能力也是有限的，根本无力承担阿里这样的流量。那么，最前面的入口是怎么解决大流量的？ 难道说有多个入口？如果是多个入口，这多个入门之前难道不需要一个“转发器”？如果需要一个“转发器”，那这个“转发器”也顶不住阿里这样的大流量啊，这不成了死循环了？展开作者回复: 1 高并发没有标准 2 有一种负载均衡叫DNS负载均衡，可以为多台负载均衡服务器在域名解析时进行负载均衡，相当于两层负载均衡。负载均衡服务器也会做主主热备，通过IP漂移的方式进行灾备切换。 3 F5、LVS支持IP负载均衡和链路层负载均衡，F5硬件也是在通信协议上进行负载均衡，只是把负载均衡代码固化在硬件里。 4 是否用CDN主要看响应中图片这类静态文件占比是不是很高，访问量是不是很大。具体多大量，看用户响应时间和图片服务器负载压力是不是能接受。看了一张极客时间的图片URL，https://static001.geekbang.org/resource/image/7a/30/7a76de65eb43771e3bd9e1f601b40830.jpg 使用独立二级域名，大概率是使用CDN的。 6 用多少服务器主要看服务器配置和程序逻辑，和Tomcat关系不大。 7 参考回答2
👽2022-03-15这篇，可能是最近几节以来，学习压力最小的一节。。。 说来惭愧，工作过程中其实还没有遇到过真正意义上的性能问题。主要提升还是提升请求性能。 首先考量，肯定还是代码层面。这是作为一个开发工程师最直接能做的。优化SQL性能，尝试接口拆分，优化代码结构等。 其次，如果中间会涉及外部请求。就考虑把这份外部请求的数据缓存起来。曾经有一个业务场景是用户调我们的接口查行情，然后我们再调第三方的接口再拼上我们的数据把行情返回给用户。其中调用第三方接口的这部分性能比较差（而且第三方接口是收费的）。我使用的方式就是把用户的请求缓存起来。比如，某用户查询了美刀的行情，我们就把这部分数据存几分钟，未来几分钟内所有的用户都拿这份数据。其实只有第一个用户体验较差，但是整体用户体验还是比较不错的。再加上是移动端的应用，偶尔请求慢了，用户也可以理解为运营商网络波动。 当然，还可以有其他的解决方案。比如，后台跑定时任务，后台更新行情。可以吗？当然是可以的，但是现实情况是，我们的用户访问时间段也不是24小时。这样轮询第三方接口，反而会增加第三方服务的费用开支。并且当时的开发人员只有我一个。所以我选择了一个，开发成本最低，但是能解决大多数用户体验的方法。 我的感悟是，其实很多时候，提升性能提升用户体验都是要成本的。 不考虑研发时间和金钱开支，很多问题可以很粗暴的解决。多地部署，就近访问，拉专线。凡是花钱，花时间解决的问题，解决起来都是比较轻松的。然而问题就是，很多时候，就给你这么多钱，这么多时间。还要把事干好，这就需要好好权衡了。展开作者回复: 赞
启程2022-03-14分布式对象缓存就涉及到数据一致性的问题，这一方面老师能详细加一下吗？特别是大数据量对数据实时性还有一定的要求的场景作者回复: 后面文章14的案例会涉及一种缓存数据一致性的解决方案。