PostgreSQL Write Capacity Planning¶
概念概覽
1M CCU 寫入容量估算方法¶
核心知識¶
1M CCU 寫入容量估算方法¶
基準公式：CCU × write_rate × queries_per_op = total_queries/s
- 1M CCU × 20 writes/s × 10 queries/op = 200K queries/s
- 單節點 PostgreSQL 上限約 20-30K queries/s，缺口達 7-10x
CAS 樂觀鎖查詢放大¶
EndBattle（CAS 最多 3x 重試）× ConsumeItems（CAS 最多 3x 重試）
= 3 × 3 = 9x 查詢放大
Worst Case：200K × 3 = 600K queries/s
嵌套 CAS 操作（上層呼叫下層，兩層各自重試）會造成乘法級放大，不是加法。
每操作查詢數基準（用於估算）¶
| 操作 | 查詢數 |
|---|---|
| ConsumeItems | 7q |
| EndBattle Victory | 16q |
| CompleteChapter | 12q |
| SellItem | 5q |
| CreateAccount | 4q |
解法方向¶
- 短期：
DBMaxConns從 30 調升至 100-150 - 中期：讀寫分離（利用
readerPool架構） - 長期：分片（sharding）
經驗教訓¶
-
估算 DB 容量需要乘上「每操作查詢數」，光看 CCU 會低估 10x
-
嵌套 CAS 重試是乘法放大，不是加法，高並發熱點下可造成查詢風暴
-
DBMaxConns 預設值 30 在 1M CCU 場景下嚴重不足，需要 100-150
常見陷阱¶
-
只看 CCU 不看 queries/op，低估 DB 壓力
-
CAS 在低衝突下優於悲觀鎖，但同一用戶快速連點（高衝突）會觸發重試風暴
-
EndBattle + ConsumeItems 嵌套呼叫時，兩層 CAS 重試相乘而非相加
最佳實踐¶
-
建立 queries/op 表格，作為容量規劃的基礎數據
-
CAS 重試上限設 3x，並在設計時分析嵌套呼叫的放大倍數
-
讀寫分離架構（readerPool / writerPool 分開）讓擴容路徑清晰
相關概念¶
- Aurora RDS Proxy
- eks-node-group----dangling-------dangling---
- go-concurrency-patterns----dangling-------dangling---
- Production Readiness Audit Methodology
相關視角¶
以下頁面與本概念共享主題，但從不同角度切入。保留獨立視角同時提供交叉參考：
- Aurora IO Pricing — 共享：
capacity-planning/ 獨特：100k-ccu,aurora - Architecture Audit Methodology — 共享：
capacity-planning/ 獨特：architecture-audit,delivery-management - Redis Sorted-Set TTL GC Capacity Bomb — 共享：
capacity-planning/ 獨特：event-system,game-server - CCU Capacity Planning（壓測數據推算法） — 共享：
capacity-planning/ 獨特：ccu,eks - Go Microservice Production Readiness Scoring — 共享：
1m-ccu/ 獨特：audit,production-readiness
來源 Sessions¶
| 日期 | Session | 貢獻摘要 |
|---|---|---|
| 2026-03-18 | 95c980e8-1c4d-4527-908a-2db6715a4bc9 | 量化了 1M CCU 場景下 PostgreSQL 寫入容量缺口，並揭示 CAS 重試的查詢放大效應 |