面對日增億級 PV，單庫單表已成瓶頸。本文系統闡述 Sharding 核心原理、三大路由演算法、集群高可用、讀寫分離、負載均衡、故障探測等完整分布式數據層設計，並以 iBatis+Spring 為基礎給出工程化落地方案。
Sharding（水平切分）：按規則將邏輯大表拆分為多個物理子表，分佈在不同 DB 實例。核心目標：突破單節點 I/O/CPU/存儲上限，實現橫向擴展。
對比垂直拆分（按業務拆庫），水平切分保持表結構不變，僅數據分片不同。
| 演算法 | 示例 | 優點 | 缺點 |
|---|---|---|---|
| 範圍分片 | user_id 1~10000 → DB1 | 範圍查詢友好，支持部分遷移 | 熱點傾斜（新用戶集中寫入） |
| Hash 取模 | user_id % 4 → 4 個 DB | 數據極度均勻 | 擴容需全量遷移，無法按機器性能加權 |
| 配置映射表 | 單獨 DB 存 user_id→DB 映射 | 極致靈活，一對一可控 | 每次查詢多一次查找，延遲增加 |
工程建議： 混合使用。核心大表用 Hash 均勻分佈；冷熱分離表用範圍；極少數超大租戶用映射表隔離。
內建上述三種演算法，支持 Groovy/SpEL 腳本動態擴展。解析 SQL 提取分片鍵 → 計算目標 Group/Table。
每個分片 = 1 Master + N Slave（數據同步靠 MySQL Replication/MySQL Router/Proxy）。單 Slave 掛掉不影響讀；Master 掛掉需自動故障轉移（MHA/Orchestrator/GTID）。
雙機制互補，將故障感知時間壓縮至秒級。
| 維度 | JDBC 封裝層 (Amoeba) | ORM 框架層 |
|---|---|---|
| 開發難度 | 高（需解析 SQL、重寫結果集） | 低（復用成熟 ORM） |
| 侵入性 | 高（替換 DataSource） | 低（插件/攔截器擴展） |
| SQL 可控性 | 中 | 高（原生 SQL，DBA 可直接優化） |
| 生產驗證 | Beta 階段 | 淘寶多年大規模驗證 |
選型結論：基於 iBatis (MyBatis) 插件機制實現 DDAL，保留原生 SQL 優勢，零侵入業務代碼。
分庫分表非銀彈，引入了分佈式事務、跨分片 Join、全局唯一 ID、遷移擴容等新複雜度。DDAL 將路由、高可用、負載均衡、故障探測封裝為基礎設施，業務層感知極小。後續演進：
核心思想不變：用軟體抽象屏蔽物理分片複雜度，讓業務聚焦領域邏輯。
