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