Oracle RAC提供兩種方式實現(xiàn)負載均衡，第一種是純技術(shù)手段，即在用戶連接時，根據(jù)系統(tǒng)當前的負載情況決定由哪個節(jié)點處理用戶請求；第二種是面向業(yè)務，人為的把應用切分成很多service，通過某個service過來的連接請求都由某個節(jié)點處理。下面來具體看看這兩種手段：

純技術(shù)手段 （面向連接的負載均衡）

1. 客戶端負載均衡
配置方法是在客戶端tnsnames.ora文件中設置LOAD_BALANCE=YES，當客戶端發(fā)起連接時，會從地址列表中隨機選取一個，把連接請求隨機分散給各個實例。
這個技術(shù)的最大缺點在于不能根據(jù)各個實例的真實負載情況來分散請求，太過粗糙，因此很少使用。

2. 服務器端負載均衡
服務器端負載均衡依賴于Listener收集的負載信息，在數(shù)據(jù)庫運行過程中，pmon進程會收集系統(tǒng)的負載信息，定期更新至Listener中。如果你配置了Remote_listener參數(shù)，pmon進程不但能把負載信息注冊到本地Listener，也可以注冊到其它實例的Listener。這樣有了pmon自動注冊機制后，集群的每個節(jié)點的Listener都掌握了所有節(jié)點的負載信息，當收到客戶端請求時，會把連接分配給負載最小的實例。

面向業(yè)務手段 （利用Service負載均衡）
上面介紹了純技術(shù)手段進行的負載均衡，看起來很美好，但在實際使用中，可能會帶來非常大的性能問題。大家都知道，RAC由于其share-disk的架構(gòu)，它的性能很大程度上依賴于內(nèi)存融合(Cache Fusion)，純技術(shù)手段無法知道業(yè)務的具體情況，因此它可能把同一個業(yè)務的連接分散到各個實例中，導致大量的內(nèi)存融合，性能急劇下降。

如果我們換一種思路，把同一種應用程序的連接分到同一個實例上，比如A應用程序的連接都連在A實例，B應用程序的連接都連在B實例上，這樣就能夠有效地減少內(nèi)存融合。
對應用的劃分可以通過service實現(xiàn)，這需要DBA和開放人員合作，在了解業(yè)務特點的情況下配置service