共计 3258 个字符,预计需要花费 9 分钟才能阅读完成。
导读 | 很多人在实际的开发中害怕系统的 QPS 增高,因为觉得 QPS 太高会导致系统挂掉; 基于这种心理会想着尽量的降低系统的请求量,甚至有人会将很多处理放置到服务中来处理,这样外部发一起请求,服务就把所有的业务处理完了。 |
这种方式降低了系统的请求量,但是降低了系统的 QPS 吗? 这种做法系统更安全了还是更危险了?
首先来介绍一下基本概念。
- 系统吞吐量(Throughput)
吞吐量指单位时间内系统处理的请求数量,体现系统的整体处理能力。
- 响应时间(系统延迟 Latency)
请求的平均响应时间
一般来说,一个系统的性能收到系统吞吐量和响应时间两个条件的约束,缺一不可。比如,我的系统可以顶得住一百万的并发,但是系统的延迟是 2 分钟以上,那么,这个一百万的负载毫无意义。系统延迟很短,但是吞吐量很低,同样没有意义。
一般情况下,针对一个系统
• 吞吐量 (Throughput) 越大,系统延迟 (Latency) 越差。因为请求量过大,系统太繁忙,所以响应速度自然会低。
• 系统延迟 (Latency) 越好,能支持的吞吐量 (Throughput) 就会越高。因为 Latency 短说明处理速度快,于是就可以处理更多的请求。
• 并发数
系统同时能够处理的请求数 / 事务数。
• QPS(也称 TPS,Query per second/transaction per second)
并发数 / 响应时间
整体来看 QPS 能够概括系统吞吐量和延迟两方面指标,因此也是系统最重要的指标之一。但当系统的 QPS 升高,到底会对系统产生哪些影响,或者在我们如何避免 QPS 升高而对系统造成的危害呢?
我们紧接这来看看服务化系统的主要模式及系统资源的消耗。
![揭露 QPS 增高后的秘密 揭露 QPS 增高后的秘密](https://s.xgss.net/sky/2024-07-24/a43db9516beae72dc5be90b1a1556df9.jpg)
当一个请求发过来的时候,会消耗哪些系统资源呢?
请求对系统资源的占用
![揭露 QPS 增高后的秘密 揭露 QPS 增高后的秘密](https://s.xgss.net/sky/2024-07-24/2fe3b6a22d48cd4b9e04a5a4bd6c32a3.jpg)
![揭露 QPS 增高后的秘密 揭露 QPS 增高后的秘密](https://s.xgss.net/sky/2024-07-24/6bec175973e013a2a50e8e19280fd7cc.jpg)
请求对系统资源的占用
![揭露 QPS 增高后的秘密 揭露 QPS 增高后的秘密](https://s.xgss.net/sky/2024-07-24/66451a8fd23c986405b6b522192f43ad.jpg)
![揭露 QPS 增高后的秘密 揭露 QPS 增高后的秘密](https://s.xgss.net/sky/2024-07-24/28b123a942e8bf7072d3fb2d1833b99b.jpg)
混合服务的资源消耗
![揭露 QPS 增高后的秘密 揭露 QPS 增高后的秘密](https://s.xgss.net/sky/2024-07-24/3e0353acc27d314765d999186bb3ae5c.jpg)
系统负载
- •系统 CPU 利用率
如果系统的 CPU 使用率已经很高,说明我们的系统是个计算度很复杂的系统,这时候如果 QPS 已经上不去了,就需要赶紧扩容,通过增加机器分担计算的方式来提高系统的吞吐量。
- •系统内存
如果 CPU 使用率一般,但是系统的 QPS 已经负载不了了,说明我们的机器并没有忙于计算,而是收到其他资源的限制,如内存或者 io。这时候首先看下内存是不是已经不够了,如果内存不够了,那就赶紧扩容了。
针对 Java 项目来说,JVM 中 Heap 信息也是内存的一个直接反应,如 Java 的老年代的内存占比,是否发生 Full GC 的情况等。
- •系统 IO
系统的 IO 一般是和 CPU 使用率相反的,CPU 利用率高的时候,IO 使用率就不大,而 IO 使用率高的时候 CPU 一般利用率不高。
- •网络带宽(可支持的网络链接数)
当我们自身系统的网络带宽被占用完毕的时候,相当于把系统的入口和出口给堵死了,这时候外界的需求排不进来了,QPS 自然上不去。
在我们的系统中时常会使用连接池的方式来连接 DB,也会使用 HTTP 连接池的方式向依赖系统发起服务,或者使用线程池的方式提供给其他服务使用。很多时候因为系统的本身连接池自身有最大连接数的限制,会导致系统连接数耗尽,单系统其他资源依然属于正常情况。这时候可以适当增加连接数的方式,来增加系统的吞吐能力,但这种方法需要慎重,因为过多的连接池,会更快的消耗系统资源,并且会将压力传递给依赖系统。
依赖系统的性能
- •DB 性能
DB 性能很多时候是系统的根本,因为一旦 DB 出现了大问题,不单单会导致一个系统出问题,很可能会导致所有依赖此 DB 的系统出现业务逻辑问题。
一般开发在实践中,遇到最多的问题就是不当的 SQL 导致 DB 读写性能很低,如未使用索引的读写 SQL; 如数据库表不适当的锁范围; 另外,如果 DB 本身的读写已经达到了自身的限度,这时候可以考虑更换机器,更换系统的硬盘,或者增加读库等方法,但这方面的优化内容非常复杂,在后面会有专门的篇幅来讨论。
- •依赖服务的性能 依赖别人的服务,很多不确定其系统性能如何,在可能情况下,可以让下游系统紧急扩容的方式来解决其自身性能问题; 但对于自身系统而言,可以采用快速失败和接口降级的方式来实现。
如果上面所说的系统自身指标和依赖系统的指标都相对正常,但系统的 QPS 依然无法负载,说明系统内部出现问题,如系统被阻塞了。
在进行系统优化之前需要进行 Profile 测试分析,根据 2:8 原则来说,20% 的代码耗了你 80% 的性能,找到那 20% 的代码,你就可以优化那 80% 的性能。
- •调用接口异步化
调用依赖服务时,采用异步并行的方式调用,将多个耗时的请求合并发出,可以降低很多无谓的等待时间。
- •IO 异步化缓存化 系统中最常用的文件 io 是记录日志,在记录日志的时候设置合适的日志缓存,并使用异步化的方式写入日志文件; 在必要的地方记录日志,避免日志滥用,不仅对 io 造成压力,且会浪费系统硬盘空间,在一些极端情况下,会因为硬盘空间耗尽而导致系统吞吐量显著下降。
针对其他需要进行文件读写的操作,建议使用异步化的方式,降低阻塞的可能。
- •API 的 request 及 response 不使用过大的对象
过大的 request 和 response 会增加网络带宽的压力,且过大的字节传入容易造成数据丢失。
- •适当使用缓存
这个是在互联网服务中最常用的优化方式了,在此不再详述。
- •慎重使用线程
有人说,thread is evil,因为多线程瓶颈就在于互斥和同步的锁上,以及线程上下文切换的成本,怎么样的少用锁或不用锁是根本。另外在系统中使用线程池时,避免因为使用线程池模式和数量限制设置不当,而成为系统瓶颈。
- •数据库的锁的方式。
并发情况下,锁是非常非常影响性能的。各种隔离级别,行锁,表锁,页锁,读写锁,事务锁,以及各种写优先还是读优先机制。性能最高的是不要锁,所以,分库分表,冗余数据,减少一致性事务处理,可以有效地提高性能。
- •使用索引
在读写数据的时候都需要在 where 条件中检查索引的使用。
- •避免在 SQL 级的 join 操作
SQL 中的 join 操作对索引的优化是个很复杂的问题,因为互联网的项目经常会发生变化,针对数据表的索引也会不断优化,如果使用 join 很可能会无法正确索引; 且 SQL 级的索引的功能维护性也非常差。
- •部分结果集
在查询上增加适当的 limit
- a. 不要 select *,而是明确指出各个字段,如果有多个表,一定要在字段名前加上表名,不要让引擎去算。
- b. 不要用 Having,因为其要遍历所有的记录。性能差得不能再差。
- c. 尽可能地使用 UNION ALL 取代 UNION。
- d. 索引过多,insert 和 delete 就会越慢。而 update 如果 update 多数索引,也会慢,但是如果只 update 一个,则只会影响一个索引表。
- e. 关于 MySQL 的优化,现在相关的资料也非常多,推荐高性能 MySQL(第二版),这本书对 MySQL 的高性能有着更深入的讨论。
![post-qrcode](https://www.xgss.net/wp-content/uploads/2023/07/二维码-微信公众号256x256.jpg)