随着业务量的提高,以及访问量和数据流量的快速增长，网络各个核心部分的处理性能和计算强度也相应增大，使得单一设备根本无法承担。在此情况下，如果扔掉现有设备去做大量的硬件升级，必将造成现有资源的浪费，而且下一次业务量的提升，又将导致再一次硬件升级的高额成本投入。于是，负载均衡机制应运而生。

    对于数据库负载均衡，大家最为耳熟能详的就是Oracle RAC了。下面，我们先简单了解Oracle RAC的实现方法。
    RAC是双机并行服务器(8i及以前版本称作Oracle Parallel Server，OPS)，用来在集群环境下实现多机共享数据库，以保证应用的高可用性，同时可以自动实现并行处理及均分负载，还能实现数据库在故障时的排错和无断点恢复。它可以自动进行负载平衡、故障修复和规划停机时间，以支持高可用性应用程序。若并行服务器中某节点失效，透明的应用程序容错能够把用户自动转接到另一节点上继续运行，应用程序在用户没有察觉的情况下继续执行。这使周期性和非周期性发生故障的系统增大了连续可用性。进程的失效可以完全透明地转移到另一节点上去，通过适当地配置，可以指定所有查询都在客户端进行缓存，这样它们便可以在转移后的节点上重新设置。

      截至到SQL Server 2008，微软还是没有推出负载均衡组件，只能通过SQL Server的其他技术特性或者利用第三方组件来DIY，下面列出我在做项目时最常用到的几个方案

端到端拓扑的事务性复制
    SQL Server 2005对端到端(P2P)拓扑结构上事务性的复制加强了支持。P2P的拓扑结构支持无限的发布服务器，它们彼此之间可以互相交换事务。
    P2P拓扑是SQL Server的一个巨大进步。现在，多端点服务器可以更改数据，并且向其他的发布者复制事务。这就是说，订阅服务器不再被限制在主要的报告环境中，可以通过事务性负载全球共享的方式将服务器分布开来。当用户的数量增加的时候，只要简单地向这个群体中添加服务器即可。
    除了将负载分布之外，这个拓扑结构还增加了可用性。如果任何一个点的服务器不可达，则池中其他服务器就会共享这个负载，因为每个服务器都有其他所有服务器上可获得的全部数据集合。
    注意：因为数据的同步是异步的，也就是说各个节点上的数据可能会是存在差异的，所以千万不要把它当成真正的负载均衡。 它被设计出来是用来各个数据库中心交换数据的，不是用来真正的做负载均衡的。

镜像+快照
      镜像和快照是SQL Server 2005的另外两个新特性，镜像的主要用途是高可用性，正常情况下镜像数据库是不可用的，就这么闲着显然是太浪费了，可以对镜像数据库做个快照，然后把一些对于数据实时性要求不高的查询转移过来，这样似乎也能分担主库的一些压力。
      把这个方案也叫负载均衡方案实在是勉为其难（我也是随大溜按照别人的思路归纳的），因为快照不能建立的太频繁，所以它的数据延时要比复制还要长，以小时记，因此转移过来的查询只能是一些报表之类的查询。

Moebius for SQL Server
    这个方案是一个第三方软件，是从微软出来的几个人做的，说他们是微软出来的并不是说他们的技术多厉害，而是他们利用SQL Server的一些内部接口把集群做的非常透明， 无论是应用程序的调用还是开发/管理人员的使用都和面对一个数据库一样。
    他们的实现原理是这样的：和镜像一样，每个数据库节点都有自己的数据，也就是无共享磁盘架构。他们称之为“中间件”的程序宿主在数据库的内部，每个节点数据库上写入数据导致数据变化时，SQL Server会激活“中间件”，“中间件”把变化的数据同步到其他的节点上。其他节点发生变化也是一样。因为“中间件”宿主在数据库内， 所以它能够把每个同步的Session和SQL Server的Session绑定到一起，也就是使用户的执行和数据的同步成为一个原子操作，从而保证数据在每时每刻都是一致的。
因此查询可以随便到每个机器上去查，从而做到了真正的负载均衡。
    另外还包括什么高可用性和虚拟IP什么的，和Oracle RAC的比较像，我也没有仔细研究。我觉得这属于附属功能了，关键点还是保证多个数据库如何能一致。

      抛砖引玉，我只是简单说了一下每个方案的实现原理，理论指导实践，有了方法接下来就是重复的枯燥的实践了。 祝大家实践快乐，并最终招到自己心目中完美的解决方案。