Oracle RAC 負載均衡深度解析：連接層 vs 服務層策略

負載均衡兩大流派

1. 純技術手段（連接層負載均衡）：依當下系統負載動態分派連線。
2. 面向業務手段（服務層負載均衡）：依應用服務靜態綁定節點，減少跨節點資料傳輸。

一、連接層負載均衡

1. 客戶端負載均衡

-- tnsnames.ora 設定
MYDB =
  (DESCRIPTION =
    (LOAD_BALANCE = YES)
    (ADDRESS = (PROTOCOL = TCP)(HOST = node1-vip)(PORT = 1521))
    (ADDRESS = (PROTOCOL = TCP)(HOST = node2-vip)(PORT = 1521))
    (CONNECT_DATA = (SERVICE_NAME = orcl))
  )

客戶端隨機選取地址清單中的一個。缺點：無感知實際負載，極易造成節點負載不均，生產環境極少採用。

2. 伺服器端負載均衡

機制：PMON 定期收集節點負載（CPU、連線數等），向本地與遠端 Listener 註冊。Listener 接收連線請求時，導向負載最低節點。

關鍵設定：

• REMOTE_LISTENER 參數指向所有節點的 Listener（採用 SCAN VIP 最佳）。
• 確保 PMON 正常向所有 Listener 註冊服務。

優點：動態感知負載；風險：可能將同一應用的連線分散至多節點，引發大量 Cache Fusion（全域緩存融合）傳輸，反而降低效能。

二、服務層負載均衡

核心理念

「將同一業務的連線集中在同一節點，最大化本地存取，最小化跨節點傳輸。」

實作方式：Service 綁定節點

-- 建立服務並指定慣用/可用實例
SRVCTL ADD SERVICE -d orcl -s app_a -r "orcl1" -a "orcl2"
SRVCTL ADD SERVICE -d orcl -s app_b -r "orcl2" -a "orcl1"

-- 客戶端連線指定服務
APP_A = (DESCRIPTION = (ADDRESS = ...)(CONNECT_DATA = (SERVICE_NAME = app_a)))

優勢

• 大幅減少 Global Cache 封包傳輸（CR/Current Block Request）。
• 故障切換由 -a (AVAILABLE) 實例自動接管，高可用性不折損。
• 符合 RAC Shared-Disk 架構特性：資料親和性優於純負載均勻。

架構選擇建議

驗證與監控

-- 檢視服務分佈
SELECT inst_id, name, goal, dtp FROM gv$services;

-- 檢視連線分佈
SELECT inst_id, service_name, count(*) FROM gv$session GROUP BY inst_id, service_name;

-- Cache Fusion 統計
SELECT * FROM gv$sysstat WHERE name LIKE '%gc cr%';

總結

RAC 負載均衡不是越均勻越好。理解 Cache Fusion 代價，透過 Service 實現「業務親和性」，才是發揮 RAC 效能的關鍵。