• 欢迎访问安全专题网站,安全专题信息,安全专题教程,推荐使用最新版火狐浏览器和Chrome浏览器访问本网站,欢迎加入安全专题 QQ群
  • 安全专题现已支持滚动公告栏功能,兼容其他浏览器,看到的就是咯,在后台最新消息那里用li标签添加即可。
  • 如果您觉得本站非常有看点,那么赶紧使用Ctrl+D 收藏安全专题吧

当服务QPS增高时,我们做什么

安全运维 网络收集 2年前 (2016-12-24) 217次浏览 0个评论

这篇文章是在给团队中级初级开发人员做的分享,相对比较浅。

很多同学在实际的开发中害怕系统的 QPS 增高,因为觉得 QPS 太高会导致系统挂掉;基于这种心理会想着尽量的降低系统的请求量,甚至有人会将很多处理放置到服务中来处理,这样外部发一起请求,服务就把所有的业务处理完了(比如将 for 循环的计算放置到服务端)。

这种方式降低了系统的请求量,但是降低了系统的 QPS 吗?这种做法系统更安全了还是更危险了?

首先来介绍一下基本概念。

1 .性能的关键指标

吞吐量指单位时间内系统处理的请求数量,体现系统的整体处理能力。

请求的平均响应时间

一般来说,一个系统的性能收到系统吞吐量和响应时间两个条件的约束,缺一不可。比如,我的系统可以顶得住一百万的并发,但是系统的延迟是 2 分钟以上,那么,这个一百万的负载毫无意义。系统延迟很短,但是吞吐量很低,同样没有意义。

一般情况下,针对一个系统

• 吞吐量(Throughput)越大,系统延迟(Latency)越差。因为请求量过大,系统太繁忙,所以响应速度自然会低。

• 系统延迟(Latency)越好,能支持的吞吐量(Throughput)就会越高。因为 Latency 短说明处理速度快,于是就可以处理更多的请求。

• 并发数

系统同时能够处理的请求数/事务数。

• QPS(也称 TPS,Query per second/transaction per second)

并发数/响应时间

整体来看 QPS 能够概括系统吞吐量和延迟两方面指标,因此也是系统最重要的指标之一。但当系统的 QPS 升高,到底会对系统产生哪些影响,或者在我们如何避免 QPS 升高而对系统造成的危害呢?

我们紧接这来看看服务化系统的主要模式及系统资源的消耗。

2. 服务化系统构成模式

2.1 基础服务

当服务 QPS 增高时,我们做什么

一个最基础的服务,一般就包含两种操作:业务逻辑处理和 DB 的读写。

当一个请求发过来的时候,会消耗哪些系统资源呢?

请求对系统资源的占用

当服务 QPS 增高时,我们做什么

当一个请求发过来之后,常规的这个请求会消耗一下资源:CPU(负责计算)、系统内存、网络链接等系统自身资源;如果我们的系统是基于 Java 的,那还涉及到 JVM 资源的占用,JVM 的 heap 和 stack 资源,其中 Heap 是更重要的指标。如果在这个请求需要与 DB 有交互,在连接 DB 进行操作的过程中,会消耗系统的数据库链接池资源。对应的在 DB 侧,会消耗 DB 的计算资源,而 DB 的计算最重要的指标就是 DB 的响应时间和 DB 的连接数。

2.2 集成服务

当服务 QPS 增高时,我们做什么

这种服务相对基础服务是另一个极端,这种服务只依赖与其他的服务,并没有自己的数据。

请求对系统资源的占用

当服务 QPS 增高时,我们做什么

在这个系统里面,我们可以将依赖服务当作 DB 来看待,只不过在请求的过程中不再消耗系统的数据库连接池资源。

2.3 混合服务

当服务 QPS 增高时,我们做什么

这种系统结构是我们最常用的结构,既有自身的业务数据,也会有部分计算依赖与其他服务。

混合服务的资源消耗

当服务 QPS 增高时,我们做什么

这种结构里面会集成上面两种结构的系统消耗。

2.4 系统资源消耗

系统负载

如果系统的 CPU 使用率已经很高,说明我们的系统是个计算度很复杂的系统,这时候如果 QPS 已经上不去了,就需要赶紧扩容,通过增加机器分担计算的方式来提高系统的吞吐量。

如果 CPU 使用率一般,但是系统的 QPS 已经负载不了了,说明我们的机器并没有忙于计算,而是收到其他资源的限制,如内存或者 io。这时候首先看下内存是不是已经不够了,如果内存不够了,那就赶紧扩容了。

针对 Java 项目来说,JVM 中 Heap 信息也是内存的一个直接反应,如 Java 的老年代的内存占比,是否发生 Full GC 的情况等。

系统的 IO 一般是和 CPU 使用率相反的,CPU 利用率高的时候,IO 使用率就不大,而 IO 使用率高的时候 CPU 一般利用率不高。

当我们自身系统的网络带宽被占用完毕的时候,相当于把系统的入口和出口给堵死了,这时候外界的需求排不进来了,QPS 自然上不去。

在我们的系统中时常会使用连接池的方式来连接 DB,也会使用 HTTP 连接池的方式向依赖系统发起服务,或者使用线程池的方式提供给其他服务使用。很多时候因为系统的本身连接池自身有最大连接数的限制,会导致系统连接数耗尽,单系统其他资源依然属于正常情况。这时候可以适当增加连接数的方式,来增加系统的吞吐能力,但这种方法需要慎重,因为过多的连接池,会更快的消耗系统资源,并且会将压力传递给依赖系统。

依赖系统的性能

DB 性能很多时候是系统的根本,因为一旦 DB 出现了大问题,不单单会导致一个系统出问题,很可能会导致所有依赖此 DB 的系统出现业务逻辑问题。

一般开发在实践中,遇到最多的问题就是不当的 SQL 导致 DB 读写性能很低,如未使用索引的读写 SQL;如数据库表不适当的锁范围;另外,如果 DB 本身的读写已经达到了自身的限度,这时候可以考虑更换机器,更换系统的硬盘,或者增加读库等方法,但这方面的优化内容非常复杂,在后面会有专门的篇幅来讨论。

如果上面所说的系统自身指标和依赖系统的指标都相对正常,但系统的 QPS 依然无法负载,说明系统内部出现问题,如系统被阻塞了。

在进行系统优化之前需要进行 Profile 测试分析,根据 2:8 原则来说,20%的代码耗了你 80%的性能,找到那 20%的代码,你就可以优化那 80%的性能。

3 常见系统优化 tips

3.1 代码调优

调用依赖服务时,采用异步并行的方式调用,将多个耗时的请求合并发出,可以降低很多无谓的等待时间。

针对其他需要进行文件读写的操作,建议使用异步化的方式,降低阻塞的可能。

过大的 request 和 response 会增加网络带宽的压力,且过大的字节传入容易造成数据丢失。

这个是在互联网服务中最常用的优化方式了,在此不再详述。

有人说,thread is evil,因为多线程瓶颈就在于互斥和同步的锁上,以及线程上下文切换的成本,怎么样的少用锁或不用锁是根本。另外在系统中使用线程池时,避免因为使用线程池模式和数量限制设置不当,而成为系统瓶颈。

3.2 数据库调优

并发情况下,锁是非常非常影响性能的。各种隔离级别,行锁,表锁,页锁,读写锁,事务锁,以及各种写优先还是读优先机制。性能最高的是不要锁,所以,分库分表,冗余数据,减少一致性事务处理,可以有效地提高性能。

在读写数据的时候都需要在 where 条件中检查索引的使用。

SQL 中的 join 操作对索引的优化是个很复杂的问题,因为互联网的项目经常会发生变化,针对数据表的索引也会不断优化,如果使用 join 很可能会无法正确索引;且 SQL 级的索引的功能维护性也非常差。

在查询上增加适当的 limit

原文:http://blog.brucefeng.info/post/high-qps-service

转载请注明:安全专题


    Selinux 中国 , 版权所有丨如未注明 , 均为原创丨本网站采用BY-NC-SA协议进行授权
    转载请注明原文链接:当服务 QPS 增高时,我们做什么
    喜欢 (0)
    发表我的评论
    取消评论
    表情 贴图 加粗 删除线 居中 斜体 签到

    Hi,您需要填写昵称和邮箱!

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址