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

    对于数据库负载均衡,大家最为耳熟能详的就是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的比较像,我也没有仔细研究。我觉得这属于附属功能了,关键点还是保证多个数据库如何能一致。

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