简介

这是系统设计中两个最核心且容易混淆的性能指标。简单来说：
• RPS 是 “每秒请求数”，是从客户端或负载均衡器的视角看，服务器每秒接收到的请求数量。
• QPS 是 “每秒查询数”，通常是从数据库或特定服务的视角看，其每秒执行的查询操作数量。

1. 详细说明

1.1 RPS (Requests Per Second) - 每秒请求数

衡量服务器、服务或系统每秒接收到的外部请求（Request）的总数。一个来自用户浏览器、手机App或其他服务的HTTP调用，就算一个“请求”。 一个请求可能非常复杂，它可能触发了后端大量的工作，比如：

• 调用多个微服务
• 执行多次数据库查询
• 进行复杂的计算
• 访问缓存

用户访问CSDN首页的这个动作，向服务器发送了一个HTTP请求，这就算 1 RPS。但这个请求背后，服务器可能去数据库查询了10条用户关注的热帖、5条广告、3条消息通知，总共产生了 18次数据库查询。

1.2 QPS (Queries Per Second) - 每秒查询数

衡量数据库（如MySQL、Redis）或某个特定服务每秒执行的查询（Query）操作数量。关注的是对数据存储层的访问频率，通常指一次简单的数据操作，比如：

SELECT * FROM users WHERE id = 1; （1次查询）
UPDATE posts SET likes = likes + 1 WHERE id = 123; （1次查询）
Redis GET user:123:profile （1次查询）

如上所述，处理那1个用户访问首页的请求（1 RPS），数据库需要执行18次SELECT操作，那么数据库的负载就是 18 QPS。

2. 总结

可以把二者看作一种 “因果关系”：1个来自外部的 RPS，通常会在系统内部产生 N次 QPS（以及其他操作）。

# 用一个简单的公式来理解
总 QPS ≈ RPS ×（每个请求平均产生的查询次数）

补充

最近在一篇博客中看到这样一句话：

“写入吞吐量为 100K RPS，数据库仅支持 10K RPS”

这里的表述其实不够精确，它的意思是：

1. 应用服务器（Application Server）每秒能接收和处理 10万个写入请求（100K RPS）。
2. 但数据库（如MySQL）每秒最多只能安全地执行 1万次写入查询（10K QPS）。这里的“RPS”被博客作者用来指代数据库的写入操作速率，严格来说用“QPS”或“WPS（Writes Per Second）”更准确。

这就产生了一个矛盾： 应用层每秒接100k个请求，但数据库每秒只能处理1万个。如果不做任何处理，数据库会瞬间被压垮。如何解决这种差距？系统设计的一个重要目标，就是处理这种不匹配。下面是一些常用策略：

1. 写缓冲（Write Buffering） & 异步处理
   使用消息队列（如Kafka, RocketMQ）。应用服务器收到请求（100K RPS）后，立即返回“成功”给用户，同时将写操作任务扔进消息队列。后台的Worker服务再以数据库能承受的速度（10K QPS）从队列里取出任务，慢慢写入数据库，也就是常说的异步处理。

2. 批量写（Batching）
   不要来一个请求就写一次数据库。可以将多个请求合并成一个批量操作。100个写入请求可以合并成1个INSERT … VALUES (…), (…), …语句。这能将100 QPS降低到1 QPS，极大减轻数据库压力。

3. 缓存（Caching）
   对于读多写少的场景，使用缓存（如Redis）来抵挡绝大部分的读请（QPS），让请求不直接到达数据库。

4. 分库分表
   如果一个数据库实例只能处理10K QPS，那就用10个数据库实例，每个实例处理10 K QPS。通过将数据分散到不同的数据库节点上，来水平扩展整体的写入能力。