Oracle RAC提供兩種方式實現負載均衡，第一種是純技術手段，即在用戶連接時，根據系統當前的負載情況決定由哪個節點處理用戶請求；第二種是面向業務，人為的把應用切分成很多service，通過某個service過來的連接請求都由某個節點處理。下面來具體看看這兩種手段：
純技術手段 （面向連接的負載均衡）
1. 客戶端負載均衡
配置方法是在客戶端tnsnames.ora文件中設置LOAD_BALANCE=YES，當客戶端發起連接時，會從地址列表中隨機選取一個，把連接請求隨機分散給各個實例。
這個技術的最大缺點在於不能根據各個實例的真實負載情況來分散請求，太過粗糙，因此很少使用。
2. 服務器端負載均衡
服務器端負載均衡依賴於Listener收集的負載信息，在數據庫運行過程 中，pmon進程會收集系統的負載信息，定期更新至Listener中。如果你配置了Remote_listener參數，pmon進程不但能把負載信息 注冊到本地Listener，也可以注冊到其它實例的Listener。這樣有了pmon自動注冊機制後，集群的每個節點的Listener都掌握了所有 節點的負載信息，當收到客戶端請求時，會把連接分配給負載最小的實例。
面向業務手段 （利用Service負載均衡）
上 面介紹了純技術手段進行的負載均衡，看起來很美好，但在實際使用中，可能會帶來非常大的性能問題。大家都知道，RAC由於其share-disk的架構， 它的性能很大程度上依賴於內存融合(Cache Fusion)，純技術手段無法知道業務的具體情況，因此它可能把同一個業務的連接分散到各個實例中，導致大量的內存融合，性能急劇下降。
如果我們換一種思路，把同一種應用程序的連接分到同一個實例上，比如A應用程序的連接都連在A實例，B應用程序的連接都連在B實例上，這樣就能夠有效地減少內存融合。
對應用的劃分可以通過service實現，這需要DBA和開放人員合作，在了解業務特點的情況下配置service
