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

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

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

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

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

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

最新評論