文章标题

系统吞吐量

在说明QPS与TPS之前，首先需要明确系统吞吐量的概念。它是衡量一个系统的抗压能力的量。经常会听到有人问“你系统的最大吞吐量有多大”，这个问题从业务上来说，可以理解为该应用系统每秒钟最大能接受的用户访问量，或者每秒钟最大能处理的请求数；从服务器底层上来看，可以说该应用系统每秒钟最多能够输出多少字节数。只是场景不同，意思都差不多，就是衡量该系统的抗压能力。
系统吞吐能力有以下几个参数衡量：

QPS
TPS
并发数
平均响应时间
单次请求对CPU计算消耗越大，IO等待时间越长，则该系统的吞吐能力越差，反之越好。
名词解释

QPS（queries per second）：每秒钟处理完请求的次数，注意这里是处理完。具体是指用户发出请求到服务器处理完成功返回结果（针对服务器不resp的场景，你可以理解在server中有个counter，每处理完一个请求加1，1秒后counter=QPS）。这里要特别注意，这里的query是请求的意思，不是查询的意思，可以理解为request：
02cf6094bb5fed40.png
和我们数据库中的query(查询)不是一个意思。在web开发中，请求一般是需要查询数据库或者写入数据库，所以有人就会将QPS理解为每秒钟处理的查询次数，这是不正确的，因为请求除了读写数据库的服务，还有CPU计算密集型请求，比如VRP(NP问题)服务，纯粹提供算法计算，或者还有大数据实时处理服务等。
TPS（transactions per second）：每秒钟处理完的事务次数。一般TPS是对整个系统而言的，一个应用系统1S能完成多少事务处理，一个事务在分布式处理中，可能会对应多个请求。对于衡量单个接口服务的处理能力，用QPS的比较多。
并发量：系统能同时处理的请求数。
RT（响应时间，一般指平均响应时间）：处理一次请求所需要的平均处理时间。
计算关系

QPS = 并发量 / 平均响应时间
并发量 = QPS * 平均响应时间

举个栗子

f13c8b89fcc81096.png
把二楼食堂看作一个系统，每天中午12点到1点需要承载乐佳国际2000号人的吃饭请求，平均每个人吃饭要花10分钟。下面来计算食堂的QPS：
食堂QPS = 2000 / (60 * 60) = 0.555 个/s （每秒钟能处理完0.555个人吃完饭）
平均请求响应时间：10 * 60 = 600s
食堂并发量 = QPS * 平均响应时间 = 333个
也就是说食堂必须有333个座位才能满足2000号人在1h内把饭吃完。如果座位小于333个，那么食堂的每一瞬间，你都会发现有人站着端着盘子等位子吃饭。反之，如果座位大于333个，食堂空间扩大了，那你吃饭就会爽很多了！

大促分析

在大促，或者更极端的卖家秒杀场景中，1秒内有5万的卖家下手，我们的系统必须能承载5万的QPS压力。现在我们的系统有20台Tomcat服务器，每台服务器配置的最大连接线程数是500个。单次业务请求为100ms。
那么我们的系统理论上最大QPS为：
QPS = 并发数 / 平均响应时间 = 20 * 500 / 0.1 = 100000（10万的QPS）
你会觉得，咦！可以满足要求的QPS承载力啊，哈哈！
不过可惜的是，实际运作中业务请求的平均响应时间肯定远大于100ms。因为tomcat线程开启的越多，线程上下文切换消耗的时间越长，CPU资源消耗量也会增大，导致响应时间增大。如果不做全链路压测，你几乎是没有办法能很好的将平均响应时间估算出来，单机压测的业务响应时间肯定小于全链路压测的RT。比如之前的100ms，到秒杀当天，业务的平均响应时间增大到了250ms。那么：
QPS = 20 * 500 / 0.25 = 4w
瞬间系统真实的QPS变成了4w。。。
小于秒杀场景下要求的5wQPS值。
内心如此崩溃的：
c218be08ff319c63.png
如果小于要求的值，会变成什么情况呢，简单描述一下。就好比一条满载的4条道高速公路，忽然在某个点变成了3条。。。。你能想象当时的场景吗？
b5bb1e67d4775e40.png
如果服务器过载运行，极有可能出现宕机。所以在上线之前做好系统QPS的评估是非常有必要的。

服务接口的QPS

现在QPS不止可以描述应用系统，在分布式服务的场景中，还通常被用来细粒度的描述服务接口的能力（比如：CtStationClient接口的QPS）。在分布式场景中，通常A服务内部调用B和C服务，C服务又调用D和E服务。如下图所示：
891acaa6d5728e6e.png
这样A服务的QPS会和B、C、D、E都有关系，单次A服务处理的平均响应时间需要整个链路来衡量。可以看eageye上的服务链QPS图：
fda382b660b242a6.png
对于强依赖的服务在大促前需要做好适当的风险评估。
QPS需要结合业务功能来看，不能纯粹的比较两个应用的QPS高低。比如A应用或者A服务的最大QPS比B服务高，不能说B服务不行，QPS只有在同一功能或者同一业务服务下才能比较，因为请求处理的平均响应时间是和业务紧密结合的。

总结

上述对QPS、TPS、并发量、系统吞吐量的概念进行了阐述，为了便于理解，结合实际场景，对这几个参数进行了分析，给出了参数之间的计算关系：
QPS = 并发量 / 平均响应时间
并发量 = QPS * 平均响应时间
同时，结合大促场景，分析了QPS估算的过程，以及说明了线程数量增多、CPU资料消耗增多以及IO等待时间变长对QPS的影响。在应用开发或者服务接口开发时，需要对业务所需QPS进行预判，合理进行性能优化以求服务QPS满足业务要求。
最后，你或许会问说好的前世今生呢？怎么没有前世只有今生。。。。
bf01841134fee6ee.png
我只是觉得前世今生这个词比较有品位！比如论正态分布的前世今生