网站的运营离不开访问量，一个没有人气的网站是没有什么经营意义的。那么对于大量的访问者和流量的服务器分配是至关重要的。那么，负载均衡技术就是这个问题***的解决手段。现在，我们就为大家介绍一下关于SQL Server 的负载均衡问题。
对于数据库负载均衡,大家最为耳熟能详的就是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的比较像,我也没有仔细研究｡我觉得这属于附属功能了,关键点还是保证多个数据库如何能一致｡
