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 会在该群集中的每台服务器上创建该多数据源的实例。