本文是 PostgreSQL overview 的 implementation-layer deep article。Overview 已說明 PG 在 OLTP 譜系的定位、本文聚焦 connection scaling 的根因 — 為什麼 PG 比多數 DB 更需要 pooler、跟 pgbouncer-config 是 根因 vs 配置 的關係。

Connection-per-Process Model 是 PG 的結構性選擇

PG 接受 client connection 時的行為跟多數現代 DB 不同：每個 connection 由 postmaster fork() 一個獨立的 OS process（backend）來服務。這個 process 在 connection lifetime 內專屬該 client、不跟其他 client 共享。

對比常見 DB 的 connection model：

PG 選 process 不選 thread 是 1990s 設計決定 — 當時 thread library 在多 UNIX 平台不穩定、process 隔離性更好（一個 backend crash 不會帶倒整個 DB）。這個 trade-off 一路保留到今天、是 PG 在 high-connection-count workload 的 結構性負擔。

量化：connection 數量對 RAM 跟 CPU 的壓力

一個 PG backend process 的 RAM footprint 由三部分組成：

1backend_rss ≈ shared_buffers_attach + process_private + work_mem 高水位

shared_buffers 是所有 backend 共享的、不重複計、但 process_private（catalog cache / plan cache / temp buffer）跟 work_mem 是 per-backend：

500 個 connection、平均 30MB 各 ≈ 15GB RAM 給 backend processes（還沒算 shared_buffers）。這是 PG 在 cloud instance 上很快撞到 RAM ceiling 的根因。

CPU 層面、fork() 系統呼叫在 Linux 通常 1-3ms、context switch ~3-5μs。100 connection burst 在 1 秒內進來、accumulated fork cost 100-300ms、加 query 本身的 CPU 跟 scheduler latency、平均 query 延遲會跳 2-5x。

三個 GUC 互動：max_connections / shared_buffers / work_mem

PG 的 memory 規劃由這三個 GUC 互動決定、不能獨立調：

1total_RAM ≈ shared_buffers + (max_connections × work_mem 高水位) + OS overhead

實務 sizing 規則（16GB instance、OLTP workload）：

max_connections = 1000 是常見 anti-pattern — 真實 active query 可能只 50-100、剩下都 idle、但每個還是吃 RAM 跟 process slot、context switch overhead 還在。

Pooler 為什麼是 production prerequisite

本段是「為什麼必裝」、實際 PgBouncer 配置看 pgbouncer-config。

Pooler 的核心責任是 把 N 個 application connection multiplex 成 M 個 PG backend（M ≪ N）：

1Application (3000 connection)
2   ↓
3Pooler（PgBouncer / PgCat）
4   ↓
5PostgreSQL (50 backend process)

Application 看到的是 無限 connection 池、PG 看到的是 穩定 50 個 backend。三個層次的效益：

1. RAM 節省：3000 connection × 30MB = 90GB → 50 backend × 30MB = 1.5GB
2. Fork() cost 攤平：backend 重用、不是每個 client 都 fork
3. Connection storm 緩衝：application 重啟 / scaling event 不會直接打到 PG

Pooler 有三種 pool mode、各有 application 層相容性 trade-off：

Production 多數選 transaction pool — 救 RAM 又保留 transaction semantics、代價是 application 不能用 session-level SET、LISTEN/NOTIFY、prepared statement（部分 pooler 已支援）。

Application-side Pool vs Middleware Pool vs RDS Proxy

三層 pool 都能解 connection 問題、但解的問題不同：

典型 production 拓撲：

1Application (HikariCP pool 10/instance × 50 instance = 500)
2   ↓
3PgBouncer transaction pool（50 backend）
4   ↓
5PostgreSQL primary

Application pool 救 fork cost、PgBouncer 救 backend 總量、兩層各做各的事不衝突。

雙層 pool 配置容易出錯：application pool size 5 + PgBouncer default_pool_size 50 + 100 個 app instance、application 願意開 500 connection、PgBouncer 只給 50 個 backend — 多 450 個 application connection wait、看起來像「DB 慢」但實際是 pool 不足。

5 個 Production 踩雷

Case 1：Connection storm（重啟 / autoscale 同時打進來）

情境：Kubernetes rolling restart、200 個 pod 同時重連、每 pod 開 20 個 connection、瞬間 4000 個 connection 嘗試打到 PG。

PG max_connections = 500 直接拒絕 3500 個、application 看到 FATAL: sorry, too many clients already、retry storm 雪上加霜。

修法：

• PgBouncer 在前面、application 連 PgBouncer 不直連 PG
• reserve_pool_size = 5 給管理流量留 buffer
• Application 端加 jittered exponential backoff、避免 retry 同步

Case 2：fork() cost 在 burst 流量

情境：Cron job 每分鐘整點觸發、500 個 worker 同時開 short-lived connection 跑 30ms query、結束關閉。

每分鐘 500 次 fork() + 500 次 exit()、fork cost 500-1500ms、CPU spike、其他 OLTP query 延遲飆。

修法：

• Worker 改 connect 到 PgBouncer transaction pool、backend 重用、fork 只在 PgBouncer 首次拓展時
• 或 worker 改成 long-lived process + 內部 task queue、避免每分鐘重 fork

Case 3：shared_buffers 跟 max_connections 互相壓縮

情境：16GB instance、shared_buffers = 8GB（50%）、max_connections = 800、work_mem = 16MB。

預估 RAM：8GB + 800 × ~30MB = 32GB ≫ 16GB instance、OOM kill 來訪。

修法（重新分配）：

1shared_buffers = 4GB           # 25%
2max_connections = 200          # 透過 PgBouncer multiplex
3work_mem = 16MB
4effective_cache_size = 12GB
5maintenance_work_mem = 512MB

關鍵：max_connections 不是調更大救 connection 不足、是調 PgBouncer pool size 拓展 application 容量。

Case 4：Double-pool 配置失敗

情境：Application HikariCP pool size = 50、50 個 instance、PgBouncer default_pool_size = 20、PG max_connections = 100。

Application 願意開 2500 個 connection、PgBouncer 只給 20 個 backend、application thread 大量 block 在 PgBouncer 等 backend 釋出。

修法：

• 計算 application 願意的並發 vs PgBouncer 允許的 backend vs PG max_connections 三層匹配
• 通常 application_total_connection ≪ pgbouncer_max_client_conn + pgbouncer_default_pool_size + reserve ≪ pg_max_connections
• Monitor PgBouncer SHOW POOLS 的 cl_waiting、長期 > 0 表示 pool 不足

Case 5：max_connections 設太大反而慢

情境：team 看到 connection refused、把 max_connections 從 200 調到 2000、想說「給更多 connection 應該更好」。

調完 throughput 反而降 30% — context switch overhead、planner cache 競爭、lock manager 競爭都跟 connection 數線性放大。

修法：

• max_connections 上限通常 200-500、超過要靠 pooler multiplex
• 用 pg_stat_activity 看真實 active connection（state != ‘idle’）、通常 < 100
• 真實上限 = active 高水位 × 安全係數 1.5、不是「未來可能會用到的數量」

跟 MySQL connection model 對比

MySQL thread-per-connection model 讓它在 high-connection-count workload 上 看起來 更省 — 但 PG 透過 PgBouncer 達到的 application 看到的容量跟 MySQL 直連是一樣的、只是多一層 indirection。

實務影響：

• MySQL 直連 1000 connection 還 OK、PG 直連 1000 connection 通常 OOM
• PG + PgBouncer 1000 application connection、後端 50 backend、表現跟 MySQL 1000 直連相當
• 沒有 PG 更耗 RAM 的本質結論、是 PG 預設不 multiplex、需要外掛 multiplex 層

PG 17+ 的 connection 進展

PG 17（2024）對 connection 仍維持 process-per-connection、但有幾個減壓改進：

• Per-process memory 降低：catalog cache 改 generational allocator、idle backend RAM 降 ~20%
• Subscriber-side parallel apply：logical replication 減少 connection 開銷
• io_combine_limit：buffered read 合併、降 syscall overhead

但 process-per-connection model 本身 沒換 — 短期內 PG 仍需 pooler。長期方向（PG 18+ 討論）可能引入 thread-based backend、但目前是 experimental patch。

相關連結

• pgbouncer-config：PgBouncer 操作配置 + 5 case
• replication-topology：Read replica + connection 分流
• query-optimization：work_mem 影響 plan
• mvcc-lock-model：connection idle in transaction 卡 vacuum
• autovacuum-tuning：autovacuum 也吃 connection slot

下一步

• 連到 pgbouncer-config 學配置細節
• 看 PostgreSQL overview 回到全圖

本文是 Redis overview 的 implementation-layer deep article。連線與往返是 application 端量到的延遲主因，跟 server 端的記憶體、持久化調校互補。pipeline 機制以 Redis pipelining 官方文件 為準、最後檢查日 2026-06-16。

延遲不在 Redis、在往返

把單一 GET 丟進 redis-cli --latency，會看到 server 端執行時間是微秒級。但 application 端的 APM 量到的 Redis 呼叫卻是 1-3ms。這個差距不是 Redis 變慢了，是網路往返（round-trip time，RTT）——命令從 application 送到 Redis、結果送回來，這趟來回就是毫秒級，而 Redis 的執行只佔其中一小部分。

這個認知翻轉了 Redis 優化的方向：當你的服務每個請求要打 10 個 Redis 命令，瓶頸不是 Redis 的吞吐，是 10 次 RTT 疊加成 10-30ms。pipelining 常被講成「批次發命令省效能」，但它真正消除的是 RTT 稅——把 10 次往返打包成 1 次往返，server 端執行時間幾乎不變，但 application 端延遲從 10×RTT 降到 1×RTT。

對每次互動要查多個 cache 的服務，這筆 RTT 稅是延遲預算的主要支出。Snap 在 multi-cloud 架構下的痛點正是這個放大版：application 在一個 cloud、cache 在另一個，每次 lookup 多吃 5-30ms 跨 cloud RTT，「5ms × 10 cache lookup = 50ms 額外延遲」。Snap 把 KeyDB 部署到同 cloud 減少跨 cloud RTT，本質就是降低往返稅。本文處理 RTT 的會計、連線池配置與 pipeline 的正確使用。

核心概念：RTT 會計與三種降稅手段

Redis 一次請求的延遲拆成三段：client 序列化 + 送出、網路往返（RTT）、server 執行。多數 cache 場景下 RTT 是主導項，server 執行可忽略。降低總延遲有三種手段，對應三種「省 RTT」的方式：

連線池消除「每次都建連線」的稅。建立 TCP 連線（三次握手）本身就是一趟 RTT，若還有 TLS 再加幾趟。每個請求都新建連線等於每次都付建連稅。連線池讓連線重用，把建連成本攤平到接近零。

pipelining 把 N 次 RTT 壓成 1 次。連續送 N 個命令而不等每個的回應，一次讀回 N 個結果。這要求這 N 個命令彼此無依賴（後一個不需要前一個的結果）。

Lua script / 多 key 命令把多操作合成 1 次往返且原子。當命令之間有依賴（讀了再決定怎麼寫），pipeline 不適用（後面的命令送出時前面的結果還沒回來），這時用 Lua script 把邏輯放到 server 端一次執行，省 RTT 又拿到原子性。

pipeline 跟 MULTI 是不同的東西

這兩個常被混淆，但解的問題不同：

pipeline 純粹是傳輸層優化，不保證原子性——pipeline 裡的命令在 server 端仍可能跟其他 client 的命令交錯。要原子性用 MULTI/EXEC 或 Lua。兩者也可以組合（在 pipeline 裡送 MULTI…EXEC）。

注意 Redis 的 MULTI/EXEC 不是關聯式 DB 的 transaction：執行期某命令出錯（例如對 string 做 list 操作）不會回滾已執行的命令，它沒有 rollback。

配置：連線池與 pipeline 的設定路徑

連線池配置（以 Python redis-py 為例，多數 client library 概念一致）：

 1import redis
 2
 3pool = redis.ConnectionPool(
 4    host="10.0.0.1", port=6379,
 5    max_connections=50,          # 池上限、依並發量與 Redis maxclients 反推
 6    socket_timeout=0.5,          # 單命令逾時（秒）——必設、否則慢命令拖垮 caller
 7    socket_connect_timeout=0.5,  # 建連逾時
 8    health_check_interval=30,    # 定期檢查連線存活、清掉壞連線
 9)
10r = redis.Redis(connection_pool=pool)

socket_timeout 是最常被遺漏卻最關鍵的設定——沒設逾時，一個慢命令或網路黑洞會讓 caller 無限等待，連鎖拖垮上游。

pipeline 的使用：

1# pipeline：N 個無依賴命令、一次往返
2pipe = r.pipeline(transaction=False)  # transaction=False 純 pipeline、不包 MULTI
3for uid in user_ids:                  # 假設要拿 100 個 user 的 profile
4    pipe.hgetall(f"user:{uid}")
5results = pipe.execute()              # 一次往返拿回 100 個結果

依賴型操作改用 Lua（命令間有讀後寫的依賴，pipeline 不適用）：

 1# 原子的 check-and-set：讀目前值、符合條件才更新——一次往返且原子
 2lua = """
 3local current = redis.call('GET', KEYS[1])
 4if current == ARGV[1] then
 5  redis.call('SET', KEYS[1], ARGV[2])
 6  return 1
 7end
 8return 0
 9"""
10cas = r.register_script(lua)
11cas(keys=["lock:resource"], args=["old_token", "new_token"])

MGET / MSET / HMGET 等原生多 key 命令是最簡單的省 RTT 手段——能用多 key 命令就不用 pipeline，更省事且原子。

Production 故障演練

Case 1：每請求新建連線、延遲全是建連稅

徵兆：Redis 呼叫延遲偏高且不穩，INFO stats 的 total_connections_received 速率極高（接近 QPS），Redis 的 connected_clients 反覆上下震盪。

根因：application 沒用連線池，或每個請求 redis.Redis(...) 重新建立 client。每次請求付一趟 TCP 握手（加 TLS 更多）的 RTT，建連稅疊在每個請求上。

修法：

1. 用連線池並重用，client 物件在 application 生命週期內共用，不是每請求建立
2. 短生命週期環境（Lambda / serverless）把連線池放在 handler 外（容器重用時連線存活）
3. 監控 total_connections_received 速率，遠高於合理重連頻率代表沒重用
4. TLS 場景的建連稅更高，連線重用的收益更大

Case 2：沒設 socket_timeout、一個慢命令拖垮整條鏈

徵兆：某次 Redis 短暫卡頓（fork 尖峰、網路抖動），application 端大量請求 hang 住不回，thread / connection 被耗盡，影響擴散到跟 Redis 無關的請求。

根因：連線沒設 socket_timeout。Redis 一旦慢回應或網路黑洞，caller 無限等待，佔住 thread 與連線，連鎖拖垮整個服務。

修法：

1. 一律設 socket_timeout（cache 場景通常幾百 ms 就該逾時，cache 本來就該快）
2. 逾時後 application 要有 fallback（回源或降級），不是把逾時當 fatal
3. 連線池 max_connections 設上限，避免無限建連把 Redis 的 maxclients 打滿
4. fork 尖峰是常見的慢源頭，對應 persistence deep article 的延遲尖峰治理

Case 3：一個巨大 pipeline 把 server 跟 client 都撐爆

徵兆：用 pipeline 批次處理時，某次塞了幾十萬個命令進一個 pipeline，Redis 記憶體尖峰、client 端記憶體爆，甚至 OOM。

根因：pipeline 把所有命令的 request 跟 response 都 buffer 起來。一次塞太多，server 端要 buffer 全部 reply（計入 used_memory、見 記憶體調校 的 output buffer），client 端要 hold 全部結果，雙邊記憶體尖峰。

修法：

1. pipeline 分批（chunk），每批幾百到幾千命令，不要一個 pipeline 塞無上限
2. 大量資料的掃描用 SCAN 游標分批，不要 KEYS * 一次撈
3. 監控 client output buffer（CLIENT LIST 的 omem），異常大代表有巨型 pipeline 或慢 consumer
4. 批次大小靠 RTT 與記憶體權衡——批次越大省越多 RTT，但記憶體尖峰越高

Case 4：在 cluster 模式對跨 slot key 開 pipeline / transaction 失敗

徵兆：單機 Redis 上運作正常的 pipeline 或 MULTI，搬到 Redis Cluster 後報 CROSSSLOT Keys in request don't hash to the same slot。

根因：Cluster 模式下 MULTI/EXEC 與某些多 key 命令要求所有 key 在同一個 hash slot。pipeline 在 cluster 下也要按 slot 分組送到對應 node——若 client library 不自動處理跨 slot，會失敗。

修法：

1. 同組操作的 key 用 hash tag {...} 強制同 slot（例如 user:{123}:profile、user:{123}:settings）
2. 用支援 cluster pipeline 的 client library，它會自動按 slot 分組
3. 設計階段就考慮 key 的 slot 分布，避免事後重構，對應 cluster re-sharding 的 hash tag 治理
4. 跨 slot 的批次邏輯改用 application 端聚合，不依賴 server 端原子性

Case 5：把 pipeline 當 transaction 用、出現資料競態

徵兆：用 pipeline 做「讀一個值、根據它決定寫什麼」的邏輯，高並發下偶發資料不一致——兩個 client 讀到同樣的舊值、各自寫入，一方覆蓋另一方。

根因：把 pipeline 誤當原子操作。pipeline 只是把命令打包傳輸，命令之間 server 端仍可能插入其他 client 的命令——它沒有原子性。讀後寫的依賴邏輯放 pipeline 裡，等於沒有任何併發保護。

修法：

1. 讀後寫的依賴邏輯用 Lua script（server 端原子執行），不用 pipeline
2. 樂觀鎖場景用 WATCH + MULTI/EXEC（watch 的 key 被改則 EXEC 失敗、重試）
3. 分清楚需求：要省 RTT 用 pipeline，要原子性用 Lua / MULTI，兩者目的不同
4. distributed lock 場景見 2.5 distributed lock，Redis 的鎖有自己的正確性陷阱

Capacity / cost 邊界

連線與往返的容量判讀，圍繞連線數與每請求往返次數：

撞牆後的路由判斷：

• 單執行緒 CPU 打滿、命令吞吐到頂：Redis 主執行緒單線處理命令，pipeline 省 RTT 但不增加 server 端平行度。CPU 到頂走 Cluster 分片把命令分散到多 node。
• 想要單機多核平行處理命令：DragonflyDB 的 shared-nothing 多核架構讓命令在單機就能多核平行，Redis 要靠 cluster 才能達到的吞吐它單機就能撐——高吞吐單機 workload 的替代。
• 跨 cloud / 跨 region 的 RTT 是結構性瓶頸：Snap 的解法是把 cache 部署到跟 application 同 cloud / 同 region，從根本消除跨區 RTT——這是架構層決策，不是 pipeline 能補的。

整合 / 下一步

連線與往返是 application 端延遲的主因，但它跟 server 端調校互補：

• 跟 記憶體調校：巨型 pipeline 的 server 端 reply buffer 計入 used_memory、慢 consumer 的 output buffer 是記憶體洩漏源頭。
• 跟 persistence / fork latency：fork 尖峰是 socket_timeout 必須存在的理由之一——慢源頭不只網路。
• 跟 Cluster re-sharding：cluster 模式改變 pipeline / transaction 的 key 分布規則，hash tag 治理是前提。
• 跟 2.6 high concurrency：高並發下的連線數爆炸與熱 key 是同一組壓力的不同面向，連線池上限與 local cache 兩層都是解法。

相關連結

• 上游 vendor 頁：Redis
• 同 vendor deep article：記憶體與淘汰調校、persistence 與 fork latency、Sentinel 與 failover 時序、Cluster re-sharding
• 上游概念：2.6 high concurrency、2.5 distributed lock
• Methodology：Vendor 深度技術文章寫作方法論