首先声明 本文基本是阅读 大话RAC 后的笔记。OK, 进入正题。
Oracle 10g RAC中采取两种方式提供负载均衡。第一种是connection blance。在用户连接的时候，根据随机算法把用户的连接定向到不同的节点。第二种是通过service，在应用层面上进行负载均衡。打个比方，一个ERP系统中包括多个模块，为多个部门服务。比如销售模块，人力资源管理模块。如果通过service进行负载均衡，我们可以定义一个 sales service代理销售模块，并且该service运行在节点1上，这样使用销售模块的人就会连接到节点1上。同理，定义一个HR service，代理人力资源模块，这样使用人力资源模块模块的人就会连接到节点2上。概况一下，第一种负载均衡是纯技术的负载均衡，第二种是面向业务的负载均衡。
connection blance这种负载均衡有两种实现方法，一种是在客户端实现，另一种是在服务器端实现。客户端实现非常简单，就是在tnsname.ora配置文件中的加上load_blance=yes这样的条目。但这种方法的缺点很明显。分配的时候并没有考虑两个节点的真实负载，所以分配结果不一定平衡，并且随机算法需要长时间片，如果短时间发起大量连接，就有可能都分配到同一个节点。更坏的结果是连接有可能被分配给故障节点。所以这种方式仅作了解，我们应该使用服务器端实现的负载均衡。而服务器端的负载均衡配置及原理也非常简单。 它的原理是由 PMON进程向listener定期的报告本节点的负载情况。listener了解了各个节点的负载情况后，会根据实际负载把收到的连接请求定向到负载较低的节点上去。如果你查看listener的log会发现很多service_update的条目，这些就是PMON在定期的汇报。 在服务器端实现负载均衡非常简单，只要配置remote_listener参数即可，这样每一个listener都会知道每一个节点的负载情况。
在了解了上面的connection blance之后，也许你在想这样已经足够好了，为什么还要发展service这种load blance呢？ 这就要分析RAC的本质了。RAC通过cache fusion模式来保证数据同步及一致。而cache fusion也是有一定开销的。 所以，如果有多个session需要同步的访问同一份数据，还是让他们都通过一个instance来访问比较好，这样会减少cache fusion的开销。让我们用ERP系统为例，若多个人同时访问销售模块，而通过connection blance把它们分散到不同的节点上，这时整个系统就需要通过cache fusion来频繁的交换数据以保证数据的一致性。 但如果通过service，他们都连接到同一个节点，就减去了cache fusion的开销。