背景痛點：傳統 DPF 協調者節點瓶頸
在 DB2 Database Partitioning Feature (DPF) 中，大表按分區鍵 (Partitioning Key) 橫向切分至多個節點。傳統架構下：
- 所有客戶端請求先到達中央協調者節點
- 協調者解析分區鍵，轉發至目標數據節點
- 聚合結果後返回客戶端
- 後續請求同樣走協調者，造成「雙倍網絡跳數」與協調者 CPU/網絡壓力
圖示對比： 兩條查詢訪問不同節點，傳統模式需 8 次遠程調用 (客戶端→協調者→數據節點→協調者→客戶端，兩次)。
SACR 核心機制：首跳重定向，後續直連
- 客戶端發起事務首條語句，連接任一節點 (入口節點)
- 入口節點根據分區鍵判斷數據所在節點：
- 若恰是自身 → 直接充當事務協調者
- 否則 → 向客戶端返回重定向信息，指引直連目標節點
- 客戶端建立新連接直連目標節點，事務內後續所有請求直接發送
- 下一事務從上一事務的協調者節點開始，可能再次重定向
效益： 消除中間轉發，減少網絡延遲、協調者負載，提升吞吐量。
性能增益量化 (官方測試數據)
| 場景 | 語句可重定向比例 | 每事務查詢數 | 響應時間提升 |
|---|
| 理想：所有數據同一節點 | 100% | 10 | 300% |
| 混合：半數查詢同節點 | 50% | 2 | 34% |
| 混合：半數查詢同節點 | 50% | 5-10 | 10% |
| 最壞：完全隨機分布 | 0% | - | 持平 (無損失) |
結論：事務內查詢越集中於單節點，SACR 收益越大；即使隨機分布也不會拖後腿。
啟用 SACR 兩步走
步驟 1：配置 DPF 分區鍵 (關鍵設計決策)
良好的分區鍵應滿足：
- 包含最高頻 WHERE 條件列
- 包含最高頻 JOIN 條件列
- 包含常用 GROUP BY 列
- 所有唯一鍵/主鍵必須覆蓋分區鍵列
- 避免：基數極低 (如性別)、數據傾斜嚴重的列
步驟 2：WebSphere 管理控制台啟用 SACR
無需修改應用代碼，對應用透明。
- 打開 WAS 管理控制台 → Resources → JDBC → Data Sources
- 選取目標 Data Source → Custom Properties
- 新增 Boolean 屬性：name=
useTransactionRedirect, value=true
- 保存並重啟相關應用伺服器
適用條件：
- WebSphere Application Server 6.0+
- DB2 Universal JDBC Driver (JCC) Type 2 或 Type 4
- 基於 Java 的 OLTP 應用
架構師視角的最佳實踐
- 分區鍵即業務鍵：在訂單系統中，
customer_id 往往同時滿足高頻查詢、Join、Group By，是極佳分區鍵候選
- 連接池配合：啟用 SACR 後，連接池應允許建立到多個節點的連接，避免池耗盡導致重定向失敗
- 監控指標：關注
Redirect Count、Coordinator Node CPU、Network Hops 變化趨勢
- 回滾策略：保留關閉 SACR 的開關 (
useTransactionRedirect=false)，以便快速回歸排查
