資料庫網路與分散式儲存

連線模型

PostgreSQL 前後端協定

PostgreSQL 的 wire protocol 自 7.4 起為 v3.0，PostgreSQL 18 新增 v3.2（更長的取消金鑰、協商機制；libpq 預設仍以 3.0 連線）。所有訊息（除第一個 startup message）格式一致： 1 byte 訊息型別 + int32 長度（含自身）+ 內容，整數為大端序，字串以 NUL 結尾。

連線建立

客戶端送 （協定版本、、、可選參數如 ）；可先送 升級 TLS 或 。 伺服器依 回覆認證要求（ 走 SCRAM-SHA-256 的多輪交換、、……，第 18 章）， 接著送多個 （、、……）、（程序 id 與取消金鑰）與 。

簡單查詢與擴充查詢

其他子協定：COPY（ 後客戶端送 串流，批次載入最快的路徑）、取消（另開一條連線送 + 金鑰，因為原連線正忙）、 非同步通知（ 的 ）、複寫協定（ 後以 雙向串流 WAL，walreceiver 與邏輯複寫客戶端如 Debezium 都走這條）。 協定是公開且穩定的，所以 PgBouncer、CockroachDB、YugabyteDB、QuestDB、Materialize、DuckDB 的 pg 伺服器模式等都「說 PostgreSQL 協定」以重用整個驅動生態。

連線池

應用程式端（HikariCP、pgx pool、SQLAlchemy pool）與伺服器端（PgBouncer、Odyssey、PgCat、Supavisor、RDS Proxy）兩層都常見。PgBouncer 的三種模式：

Pool 大小：連線並非越多越好。PostgreSQL wiki 與 HikarCP 的經驗公式 \(\text{connections} \approx \text{cores} \times 2 + \text{effective spindles}\)， 再依實測調整——超過核心數太多只會讓所有查詢因為上下文切換與鎖競爭一起變慢。應用程式端 pool 總和應 \(\le\) 後端 pool 的 ； 等待 pool 的排隊要有 timeout，否則一次慢查詢會讓整個服務卡死。

延遲、RPC 與序列化

• 往返才是單位：同機房往返約 0.2–0.5 ms、跨區域 30–150 ms；一個 ORM 的 N+1 查詢在 0.5 ms 往返下 1000 列就是 0.5 秒。 對策：JOIN／ 合併查詢、批次寫入（多列 、）、pipelining、把邏輯移到資料庫（CTE、函數）、prepared statement 省 parse。

• 格式：PostgreSQL 協定可選文字或二進位（、、 二進位省大量轉換）；分散式資料庫內部節點間多用 gRPC/Protobuf（TiKV、CockroachDB）或自訂二進位 RPC。

• TCP 細節：（關 Nagle，避免小訊息延遲）； 偵測死連線（特別是經過 NAT／負載平衡器時）； TLS 握手 1–2 次往返（連線池攤平）；Unix domain socket 比 localhost TCP 快且可用 peer 認證。

• 尾端延遲（Dean & Barroso 2013）：一個請求扇出到 100 個節點時，p99 的慢節點幾乎必然出現；分散式資料庫以 hedged request、超時重送到另一個複本、限制扇出來對抗。

Timeout、重試與冪等

結果不明（ambiguous failure）：客戶端送出 後連線中斷——交易可能已 commit、也可能沒有。盲目重試會重複執行（重複扣款），不重試可能遺失。正確做法：

• 讓操作冪等：以客戶端產生的 idempotency key 為唯一鍵（），重試時可安全重做；或把「這筆交易是否完成」寫成可查詢的狀態。

• 重試要有上限、指數退避、加抖動（jitter），並區分可重試錯誤（、、連線失敗）與不可重試錯誤（約束違反、語法錯誤）。

• 層層重試會放大流量（retry storm）：只在一層重試，搭配斷路器（circuit breaker）與負載卸除。

• 「exactly-once」在分散式系統中不存在於傳輸層，它永遠是「at-least-once + 去重」。

分散式儲存架構

日誌即資料庫：Aurora 與 Neon

Amazon Aurora（2017）的核心觀察：傳統主從複寫中網路成為瓶頸——primary 要送 WAL、整頁、double-write、備份等多份資料。 Aurora 讓資料庫只送 redo 日誌到跨 3 個可用區、6 份複製的儲存服務（寫 4/6 quorum、讀 3/6，可容忍整個 AZ + 一個節點失效）， 儲存節點在背景把日誌套用成頁面、做 checkpoint、備份到 S3；網路 I/O 減少 7.7 倍，當機復原不需要重播（儲存層持續在做）。 2018 年的後續論文說明它如何避免在 I/O 路徑上跑共識（以 epoch 與 quorum 讀取代替）。

Neon 以開源 PostgreSQL 做了類似拆分：safekeepers（Paxos 複寫的 WAL 服務，3 節點 quorum）接收 WAL 保證持久； pageservers 消化 WAL 成分層的不可變檔案（類 LSM），服務 請求並把冷資料下沉到 S3；計算節點是修改過的無狀態 PostgreSQL。 副產品是copy-on-write 分支與時間旅行（任意 LSN 的資料庫分支幾乎零成本）與 scale-to-zero。

以物件儲存為底層

S3 類物件儲存提供近乎無限容量、11 個 9 的持久性、極低單價，但單次請求延遲 10–100 ms、只支援整物件寫入（無原地修改）。 這些特性恰好與不可變、大塊、循序的資料結構相容：Snowflake 把表切成 micro-partition 存於 S3，計算節點用本地 SSD 當快取； LSM 的 SSTable 天然可以放在 S3（RocksDB-Cloud、SlateDB、Neon 的 layer file）；lakehouse 的 Parquet + Iceberg/Delta 更是以物件儲存為唯一真相。 趨勢是「S3 為持久層、本地 NVMe 為快取、記憶體為工作集」的三層設計，以及 S3 Express／條件寫入（compare-and-swap）帶來的新原語。

分散式檔案系統與複寫 vs 糾刪碼

GFS（2003）／HDFS 以 64–128 MB chunk、3 副本、append 為主的設計支撐了第一代大數據系統；Google 現今的 Colossus 以糾刪碼為主。 三副本儲存成本 \(3\times\)、修復只需複製；糾刪碼（Reed–Solomon，如 6+3）成本 \(1.5\times\)、可容忍 3 個失效，但修復要讀多個分片並計算，小檔與隨機讀不友善。 資料庫層通常不直接碰這些（交給雲端 EBS/S3），但理解它們有助於解讀「持久性 11 個 9」與「I/O 延遲抖動」的來源。