簡介

這是系統設計中兩個最核心且容易混淆的性能指標。簡單來說：
? 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。通過將數據分散到不同的數據庫節點上，來水平擴展整體的寫入能力。