QPS（Queries Per Second） 是衡量系統吞吐量的核心指標，表示每秒能處理的請求數量。以下是關于QPS的完整解析和實踐指南：

---

一、QPS的核心公式

QPS = 總請求量 / 請求總時間（秒）

典型場景計算：

• 日請求量1000萬：QPS = 10,000,000 / (24*3600) ≈ 116
• 高峰時段（如秒殺）：需按峰值流量計算（例如1分鐘內處理10萬請求 → QPS=10,000/60≈1667）

---

二、QPS性能分層與應對策略

QPS范圍	適用場景	關鍵技術方案
< 50	內部管理系統	單機Tomcat/Spring Boot + MySQL
50~500	中小型Web應用	Nginx負載均衡 + Redis緩存 + 數據庫讀寫分離
500~5000	電商/社交應用	微服務集群 + Redis集群 + 分庫分表 + CDN
> 5000	雙11/春晚級高并發	分布式架構 + 異步化+ 隊列削峰 + 異地多活 + 自動擴縮容

---

三、提升QPS的6大核心手段

1. 架構優化

   • 分層設計：客戶端 → CDN → 網關 → 服務層 → 緩存層 → 數據層
   • 服務無狀態化：方便水平擴展
   • 熱點隔離：將高頻業務獨立部署（如秒殺服務）

2. 并發能力提升

   // Java線程池配置示例 (Tomcat)
   server.tomcat.max-threads=1000  // 默認200，需根據壓測調整
   server.tomcat.accept-count=1000 // 等待隊列長度
   

3. 緩存加速

   • Redis集群：單節點QPS可達10萬+
   • 多級緩存架構：

4. 數據庫優化

   • 讀寫分離：主庫寫 + 多個讀庫
   • 分庫分表：ShardingSphere / MyCAT
   • 連接池調優：

     # Druid配置示例
     spring.datasource.druid.max-active=100
     spring.datasource.druid.initial-size=10
     

5. 異步化處理

   # Celery異步任務示例（Python）
   @app.task
   def process_order(order_id):# 耗時操作save_to_db(order_id)# 接口中調用
   process_order.delay(order_id)  # 立即返回響應
   

6. 流量控制

   • 限流算法：

     // Golang令牌桶限流
     limiter := rate.NewLimiter(100, 10) // QPS=100
     if !limiter.Allow() {return errors.New("請求超限")
     }
     

   • 降級策略：超時直接返回默認數據

---

四、QPS壓測實戰

1. 工具選擇

工具	特點	適用場景
JMeter	圖形化界面，支持復雜邏輯	HTTP/API測試
wrk	輕量級，高并發低開銷	基準測試
Locust	Python腳本，分布式壓測	自定義場景模擬

2. 壓測命令示例

# wrk測試（100線程，1000連接，持續30秒）
wrk -t100 -c1000 -d30s --latency http://api.example.com# 輸出關鍵指標
Requests/sec: 3680  # 實際QPS
Latency: 45.2ms     # 平均延遲

3. 壓測關注點

• 拐點探測：QPS增長但響應時間突增的點（系統瓶頸）
• 錯誤率：>0.1%需立即優化
• 資源監控：CPU >70% / 內存 >80% / 網絡IO打滿

---

五、QPS與其他指標的關系

指標	計算公式	與QPS的關聯
TPS	每秒事務數	事務型系統中 QPS ≈ TPS
RT	平均響應時間(ms)	QPS = 并發數 / (RT/1000)
并發數	同時處理的請求數	并發數 = QPS * (RT/1000)

案例：若系統RT=50ms，要達到1000 QPS：
所需并發數 = 1000 * (0.05) = 50

---

六、高QPS系統設計案例（電商秒殺）

關鍵實現：

1. 庫存預扣：Redis DECR 原子操作
2. 請求過濾：網關層布隆過濾器攔截重復請求
3. 最終一致性：Kafka保證訂單創建

---

七、QPS 提升 Checklist

• 基準測試確定當前QPS瓶頸
• 添加應用層緩存（Redis/本地緩存）
• 優化SQL（慢查詢消滅 >100ms操作）
• 線程池/連接池參數調優
• 啟用Gzip壓縮減少網絡傳輸
• 靜態資源CDN化
• 非核心操作異步化
• 實施限流熔斷機制

實際優化效果：某電商支付接口通過Redis緩存+異步化，QPS從800提升至12,000，延遲從350ms降至28ms。