現狀：SQL Server 缺乏原生負載均衡與多主叢集
截至 SQL Server 2008 R2，微軟**未提供原生多寫入節點負載均衡**。可用技術僅限：
- AlwaysOn 可用性群組 (2012+)：單主多讀，次要複本可支援唯讀負載分流，**但寫入仍單點**。
- 異地複寫 / 交易式複寫：單向/雙向同步，衝突解決複雜，延遲不可控。
- 資料庫鏡像 / 記錄傳送：高可用/災備，**非負載均衡**。
- 分區檢視表 / 分區資料表：資料水平切分，應用層路由，**非透明負載均衡**。
單機熱備模式的三大痛點
| 痛點 | 說明 |
|---|
| 擴展成本高 | 僅能 Scale-up (換更強主機)，成本呈指數增長；無法 Scale-out (加廉價節點)。 |
| 資源浪費 | 備援節點長期閒置 (冷備/暖備)，ROI 極低。 |
| 切換非零秒 | 故障切換需偵測、決策、DNS/連線字串切換，通常以秒~分鐘計，業務中斷可感知。 |
第三方方案：ICX Database Router (I SEE X Database Servers)
架構定位：中介層路由器，非 Proxy、非驅動程式
- 部署於**應用伺服器與 SQL Server 叢集之間**，應用連線指向 ICX VIP。
- 後端掛載 **2~16 台 SQL Server 節點**，ICX 保證**任意時刻所有節點邏輯資料完全一致**。
- 核心技術：**並發事務同步複寫** — 截取事務日誌/指令，同步套用至所有節點，**在用戶端收到 Commit 回應前完成多節點持久化**。
核心能力
| 能力 | 實現機制 | 效益 |
|---|
| 真負載均衡 (讀寫) | ICX 依節點負載、延遲、連線數動態分派 SQL 陳述式 | 寫入吞吐線性擴展，讀取自動分流 |
| 零秒故障切換 | 節點異常偵測 → 即時從路由表移除 → 進行中事務重導向至健康節點 | 應用層無感知，連線不中斷，交易不回滾 |
| 多節點強一致 | 同步複寫 + 兩階段提交變體，任意節點故障不遺失已認可事務 | 資料零遺失，符合金融級一致性 |
| 透明部署 | 應用零修改，僅改連線字串指向 ICX；支援 ADO.NET、ODBC、JDBC、PHP PDO | 存量系統平滑遷移 |
事務同步策略智能化
- 小筆資料 → 直接同步資料列。
- 含 LOB (大物件) → 壓縮後同步，降低頻寬。
- 大批量 DDL/DML → 解析執行計畫，比較「同步資料」vs「同步 SQL 指令」成本，選擇較優策略 (如結構變更同步 DDL、大量刪除同步 TRUNCATE 指令)。
優缺點客觀評估
| 優點 | 缺點/風險 |
|---|
| 寫入 Scale-out 突破單機極限 | **單點故障**：ICX 自身掛掉 = 全叢集不可用 (需部署 ICX HA 雙機熱備) |
| 零秒切換、強一致、應用透明 | **廠商鎖定**：核心邏輯閉源，除錯、升級依賴原廠 |
| 節省備援硬體成本 (全主動) | **網路延遲敏感**：跨資料中心部署需極低延遲專線 (<1ms) |
| 支援異構硬體、版本混掛 (有限度) | **授權成本**：除 SQL Server 授權外，另需購買 ICX 授權 |
替代演進路徑：現代架構選擇
- AlwaysOn 可用性群組 (SQL 2012+)：單寫多讀，適合「讀多寫少」場景，零額外授權。
- 讀寫分離中介層：ProxySQL、MaxScale、自研 Router → 寫入導向主庫，讀取分流至從庫。
- 資料分片：應用層按 Tenant/Region/ID Hash 路由至不同 SQL 實例，犧牲跨分片交易換取極致擴展。
- 異步事件驅動 (CDC + Kafka + 消費者)：寫入單主，變更非同步推送至多下游 (搜尋、快取、資料湖、備份庫)。
- 雲端原生：Azure SQL Managed Instance / AWS RDS Multi-AZ / Google Cloud SQL — 託管高可用、讀取複本、自動容錯移轉。
結語
ICX Database Router 以**同步複寫中介層**實現了 SQL Server 罕見的「多主寫入負載均衡 + 零秒切換」，在**金融核心、電信計費、即時競價**等強一致、高寫入、不可中斷場景具備獨特價值。但隨著 **AlwaysOn、雲端託管、微服務架構** 普及，大多數新系統傾向「單寫多讀 + 非同步分流」或「分片 + 事件驅動」路徑。選型時請以**業務一致性要求、寫入併發量、團隊運維能力、總擁有成本 (TCO)** 為核心維度評估，而非單純追求「多主」。
