QPS TPS PV 等概念
PV（Page View，页面浏览量）： 指的是页面被浏览的总次数。用户每次打开一个页面，就算作一次 PV。同一个用户多次访问同一页面，PV 也会累加。PV 是衡量网站流量的重要指标，但它不能反映实际访问的用户数量。
QPS（Query Per Second，每秒查询数）： 指的是系统每秒能够处理的请求数量。QPS 是衡量系统吞吐能力的重要指标。比如说某 API 支持 200 QPS，就是说这个接口可以做到每秒查寻 200 次。
TPS（Transactions Per Second，每秒事务数）: TPS 指的是每秒钟系统能够处理的事务数量, 一个事务通常包含多个操作, 例如一次完整的订单提交、一次银行转账等, 在一些简单的系统中，一个请求就是一个事务，此时 QPS 和 TPS 相等。但在复杂的系统中，一个事务可能包含多次查询，此时 TPS 通常小于 QPS.
并发数： 指的是系统同时能够处理的请求数量, 假设一个系统的 QPS 是 1000, 平均每个请求的处理时间是 100 毫秒, 那么这个系统的并发数大约为 1000 * 0.1 = 100 (1 s 处理 1000 个请求, 那 0.1 秒可以处理 100 个)
想象一个水龙头（请求入口），水流速度是每秒 1000 毫升（QPS）。水流到一个水管（系统），水管的长度决定了水在里面停留的时间，假设水在水管中需要 0.1 秒才能流出（平均处理时间）。
那么在任何时刻，水管中都存有多少水呢？答案是 1000 毫升/秒 * 0.1 秒 = 100 毫升。这 100 毫升水就相当于并发数。
可以通过 PV 来估算网站的峰值 QPS, 根据 28 定理, 80%的请求发生在20%的时间内:
峰值 QPS ≈ (总 PV 数 * 80%) / (每天秒数 * 20%)
假设一个网站每天的 PV 是 100 万，那么它的峰值 QPS 大约为 (1000000 * 0.8) / (86400 * 0.2) ≈ 46。这意味着在访问高峰期(20%的时间)，网站需要每秒处理约 46 个请求,
我说下我目前接触下来比较合理的 QPS 范围：带了数据库的服务一般写性能在 5k 以下，读性能一般在 10k 以下，能到 10k 以上的话，那很可能是在数据库前面加了层缓存。
比如候选人上来就说服务单实例 API 读写性能都有上万 QPS, 那我可以大概猜到这应该是个纯 cpu+内存的 API 链路。但如果候选人还说这里面没做缓存且有数据库调用，那我可能会追问这里头用的是哪款数据库，底层是什么存储引擎？
注意我们可以通过一个网站的 PV 来估算它需要的 QPS, 一般网站都是一百以内的 QPS, 因为 100 QPS 就意味着 216万 PV 了, 反推：总 PV 数 = (峰值 QPS * 每天秒数 * 20%) / 80%
但是这只是估算一天 20% 时间的 QPS, 实际比这复杂, 比如淘宝那种, 某个时间点, 很多人冲进直播间买东西, 这就不能通过上面的方式来计算网站需要的 QPS 了, 这个时候就要看我们服务器最多可以支持多大 QPS, 和网站每天峰值 QPS 估算不是一个场景了,
上面我们已经提到: 并发数 = QPS / RT(响应时间), 因此: QPS = 并发数 * RT, 这是不是说, 并发数越高, 我们的 QPS 就会越高呢, 从公式可以看出：
-
在平均响应时间不变的情况下，并发数越高，QPS越高
-
如果并发数不变，平均响应时间越短，QPS越高
可是不要忽略: 并发数和平均响应时间是相互影响的, 在并发数设置过大时, API 同时要处理很多请求, 我们知道每个请求, 服务器都会开启一个新的线程或者协程, 用线程的时候一般都会用线程池, 因为频繁创建删除线程也是有代价的, 另外线程池可以用来控制线程总数: 并发度.
不要忘了, 线程是有时间片的, 并不是说我们开启 1000 个线程, 就真的是 1000 个线程在同时运行, 所以当并发 HTTP 请求增加时, 就会导致大量线程在 READY 队列等待 CPU, 每个线程分配到的CPU时间片减少, 这个时候就会导致大量的上下文切换, 也就是线程实际干活的时间越来越短, 时间都浪费在了上下文切换上,
所以并发数过大时，API 同时要处理很多请求，会频繁切换上下文，而真正用于处理请求的时间变少，请求响应时间也会变长, 反而使得 QPS 会降低, 一般 API 会有一个合适的并发数，在该并发数下，API 的 QPS 可以达到最大，但该并发数不一定是最佳并发数，还要参考该并发数下的平均请求响应时间。
比如下面这个API压测数据，并发50至并发300的QPS都是220左右，但是并发2000的平均请求响应时间是60ms，平均QPS下降到33，那么我们可以理解为并发2000下API处于不可用状态了。
