1. 什么是多數據源
我們知道配置WebLogic Server集群時一定要配置一個單一接入點（例如：Apache或F5），這樣客戶端只要訪問這個單一入口點就可以了。對於客戶來說，就好象訪問一台服務器，但實際上是有一組服務器來提供服務，客戶根本不會覺查這組服務器的存在以及這些服務器之間的協作關系。與應用服務器集群類似，數據庫也可能由多個實例構成集群（Oracle RAC），那么同樣道理，對於數據庫的訪問也需要一個單一入口點，這就是多數據源。也就是說多數據源是協作管理一組數據源，實現負載均衡與故障轉移。
2. 多數據源算法
雖然多數據源可以實現負載均衡與故障轉移，但是在配置多數據源時，必須二選一。
- 故障轉移
故障轉移算法提供了一個用於滿足連接請求的數據源的有序列表。通常情況下，每一個對這種類型的多數據源發出的連接請求都由該列表中的第一個數據源提供服務。如果某個數據源連接未能通過測試，並且該連接無法被替換，或者如果該數據源已掛起，則會從該列表中的下一個數據源開始，按順序查找連接。
故障轉移算法這依賴於數據源上的“保留時測試連接（TestConnectionsOnReserve）”選項來測試數據源中的連接。
即：數據源-> 配置->連接池->高級
圖1
JDBC 是一個高度有狀態客戶端 DBMS 協議，在此協議中，DBMS 連接和事務狀態直接與 DBMS 過程和客戶端（驅動程序）之間的套接口相連。出於此原因，不支持在正在使用某個連接時對其進行故障轉移。
連接可能會在被保留之后發生故障，在此情況下，您的應用程序必須處理該故障。WebLogic Server 無法為某個應用程序正在對其進行使用時發生故障的連接提供故障轉移。使用連接時發生的任何故障都需要您重新啟動事務並提供代碼以處理這樣的故障。
- 負載均衡
可從該列表中的任何數據源向對負載平衡多數據源做出的連接請求提供服務。MultiPool會使用循環法方案來選擇要用於滿足連接請求的數據源。當多數據源提供了某個連接時，它會從正好列在用於提供連接的上一個數據源后面的數據源中選擇一個連接。如果某個數據庫連接未能通過測試，並且該連接無法被替換，或者如果該數據源已掛起，則使用負載平衡算法的多數據源也會故障轉移到該列表中的下一個數據源。
3. 故障轉移增強處理
- 數據源故障時的連接請求路由增強
為了在多數據源中的某個數據源發生鼓掌時提高性，WebLogic Server會在緩沖池連接未能通過連接測試的情況下自動禁用數據源。禁用了某個數據源后，WebLogic Server不會將連接請求從應用程序路由到該數據源，而是會將連接請求路由到多數據源中列出的下一個可用數據源。
- 恢復多數據源中發生故障的數據源時的自動重新啟用
由於連接未能通過連接測試從而導致整個數據源被禁用。多數據源會定期測試該已禁用的數據源中的連接，如果該數據源可用，則該數據源將變為可用，並恢復向該數據源路由連接請求。測試頻率是由該多數據源的“測試頻率”特性控制的，默認120秒，如下圖。
多數據源->配置->一般信息
圖2
- 使用回調控制多數據源故障轉移
對於故障的定義，一是測試未通過，還有一種情況就是當數據庫連接請求數超過了多數據源中當前數據源中的可用連接數時，對於這種情況，我們可以在配置多數據源時指定“如果繁忙，則進行故障轉移請求（FailoverRequestIfBusy）”選項，圖2。
4. 使用回調控制多數據源故障轉移
我們可以將一個回調處理程序注冊到WebLogic Server中，用以控制是否或何時進行故障轉移。以便在故障轉移前可以進行任何其它系統准備，如准備好數據庫或具有高可用性的框架進行通信。此回調處理程序是通過多數據源的“故障轉移回調處理程序”特性注冊的，並且是針對每個多數據源進行注冊，見圖2。
4.1 回調程序
回調程序必須實現weblogic.jdbc.extensions.ConnectionPoolFailoverCallback接口，此接口只有一個回調函數allowPoolFailover( currPool, nextPool, opcode )，其返回值必須是OK, RETRY_CURRENT, or DONOT_FAILOVER。
4.2 故障遷移時工作原理
在當前數據源未能通過連接測試時，或者在當前數據源中的所有連接都處於忙狀態（如果已啟用FailoverRequestIfBusy），WebLogic Server會嘗試將連接請求故障轉移到列表中的下一個數據源，如果已注冊了某個回調處理程序，則WebLogic Server會調用回調處理程序，傳遞以下信息，並等待一個返回（即同步調用）。
-
- currPool：當前正在用於提供數據庫連接的數據源名稱，這是“故障轉移源”數據源。
- nextPool：多數據源中列出的下一個可用數據源的名稱，這是“故障轉移目標”數據源。
- opcode：表明調用原因的代碼，OPCODE_CURR_POOL_DEAD表示當前數據源已失效並已將其禁用；OPCODE_CURR_POOL_BUSY 表示該數據源中的所有數據庫連接處於使用狀態。即：FailoverIfBusy=true
回調處理程序返回值：
-
- OK：繼續執行，故障轉移到列表中的下一個數據源。
- RETRY_CURRENT：使用當前數據源重試連接請求
- DONOT_FAILOVER：不重試當前連接請求，並且不進行故障轉移，WebLogic Server將引發一個weblogic.jdbc.extensions.PoolUnavailableSQLException。
如果第二個數據源發生故障，則 WebLogic Server 會在嘗試故障轉移到多數據源中的下一個可用數據源（如果有一個）的過程中，再次調用回調處理程序（像在以前的故障轉移中一樣）。
注意： 在您手工禁用數據源時，WebLogic Server 不調用回調處理程序。
對於使用負載平衡算法的多數據源，WebLogic Server 不會在禁用了某個數據源的情況下調用回調處理程序。但是，它會在嘗試重新啟用已禁用數據源時調用回調處理程序。
4.3 故障恢復時工作原理
-
- currPool：以前禁用的並且目前可供重新啟用的數據源的名稱。
- nextPool：此為空。
- opcode：此值始終為OPCODE_REENABLE_CURR_POOL，表未currPool中指定的數據源目前可用
回調處理程序返回值：
-
- OK：繼續執行，這意味着重新啟用指示的數據源，WebLogic Server會根據多數據源算法和該數據源在已包括數據源的列表中的位置，恢復向數據源路由連接請求。
- DONOT_FAILOVER：不重新啟用currPool數據源，繼續從正在使用的數據源為連接請求服務。
如果回調處理程序返回了DONOT_FAILOVER，則WebLogic Server將嘗試在下一個測試周期期間重新啟用數據源，並將回調處理程序作為該進程的一部分進行調用。
多數據源中列出數據源時所使用的順序是非常重要的。使用故障轉移算法的多數據源將始終嘗試從多數據源中的數據源列表中的第一個可用數據源為連接請求提供服務。請考慮以下情況：
-
- MultiDataSource_1 使用故障轉移算法，具有注冊的 ConnectionPoolFailoverCallbackHandler，並包含三個數據源：DS1、DS2 和 DS3（以該順序列出）。
- DS1 變為已禁用，因此，MultiDataSource_1 將連接請求故障轉移到 DS2。
- 然后，DS2 變為已禁用，因此，MultiDataSource_1 將連接請求故障轉移到 DS3。
- 一段時間之后，DS1 再次變為可用，回調處理程序將允許 WebLogic Server 重新啟用該數據源。DS1 將為以后的連接請求提供服務，因為 DS1 是該多數據源中列出的第一個數據源。
- 如果隨后 DS2 變為可用，並且回調處理程序允許 WebLogic Server 重新啟用該數據源，則連接請求將繼續由 DS1 提供服務，因為在數據源列表中，DS1 列在 DS2 之前。
5. 在服務器和群集上部署 JDBC 多數據源
多數據源為了滿足連接請求而使用的所有數據源與該多數據源必須部署在相同的服務器和群集上。多數據源始終使用部署在同一台服務器上的數據源來滿足連接請求。多數據源不會將連接請求路由到群集中或域中的其他服務器。
要將多數據源部署到某個群集或服務器，您要選擇該群集或服務器作為部署目標。在服務器上部署某個多數據源時，WebLogic Server 會在該服務器上創建該多數據源的一個實例。將多數據源部署到群集時，WebLogic Server 會在該群集中的每台服務器上創建該多數據源的實例。