网络的使用越来越生活化，那么单一的负载均衡技术已经不能满足日益紧张的网络压力。为了缓解这些压力，我们提出了更多的要求，也改进了不少技术，当然，最多的，就是和其他技术相互来结合进行优化设置。现在我们就说一说缓存服务器和负载均衡技术的结合使用。
根据一些专家的调查分析,发现企业在使用数据库的时候,90%以上主要用来查询｡有些企业这个比例甚至更高｡也就说,用户对数据库的操作,其实更新操作占的比例很少｡大部分的操走都只是查询操作｡如一些论坛,大部分用户只会看贴,而不会发帖｡这就是一个典型的查询操作比例大大超过更新操作比例的例子｡针对这种情况,其查询操作往往是其数据库性能的瓶颈｡如何有效提高查询的性能,这就使各个数据库专家在考虑的问题｡在SQL Server数据库中,已经有了一个现成的解决方案｡数据库管理员可以利用缓存服务器来提高数据库的性能｡笔者这里就以SQLServer2008为例,谈谈如何利用缓存服务器来实现负载均衡,来提高数据库的查询效率｡
利用缓存服务器来负载均衡
如上图,是一家著名的BBS论坛的数据库架构｡首先其通过多台WEB应用服务器来实现负载均衡｡这个方案跟数据库架构关系不大,笔者不做过多阐述｡笔者要谈的是,其在数据库服务器与WEB应用服务器之间,还多了一层,即数据库缓存服务器｡在SQLServer数据库中,就是利用这些缓存服务器来实现数据库层面的负载均衡,来提高数据库的查询性能｡那么这个解决方案到底有什么特点呢?是如何来解决查询操作这个瓶颈问题?在部署这个解决方案的时候需要注意哪些问题呢?不要着急,笔者会一一回答这些问题｡
一､ 数据查询与数据更新分开走
如上图所示,如果用户要查看某个帖子,其就会打开某个连接｡此时WEB应用服务器就会从后台数据库中查询相关的记录｡这里需要注意的是,由于其只是查看帖子,而不涉及到更新的操作,为此WEB应用服务器就只从缓存服务器中读取数据｡这个缓存服务器中的记录跟数据库服务器的内容是同步的｡WEB应用服务器在从数据库缓存服务器读取数据之前,还会先判断一下哪台数据库服务器比较空｡会优先连接到比较空闲的数据缓存服务器中,然后从这台服务器中读取数据｡所以,当访问这个论坛的用户比较多时,这个数据缓存服务器能够实现负载均衡的需要｡
如果用户看了某个帖子,现在需要发表一个评论,此时后台数据库会怎么操作呢?注意,当WEB应用服务器发送了一个Update更新操作的时候,其应用服务器会自动连接到数据库服务器,而不会再连接到数据库缓存服务器｡而是直接向数据库服务器发送更新操走的语句｡当数据库服务器更新了相关的内容之后,会与数据库缓存服务器实现数据的同步｡从上图中可以看出,整个数据查询与数据更新WEB应用服务器是分两条路走｡其实这就好像是公路上分道行驶,机动车走机动车道;非机动车走非机动车道｡如此的话,就不会因为非机动车比较慢,而影响到机动车的速度｡在这个方案中,将数据库的更新操作与查询操作分开来走,也是类似的道理｡在查询时,数据流是单向流动的,所以能够在很大程度上提高查询的效率｡从而让数据负载均衡的效果更加明显｡总之,当某个应用程序查询操作大大超过更新操作时,通过在多个数据库间缓存只读数据,并在数据库间均匀连接客户端以分发负载,则就可以向外扩展工作负荷的读取分区,即实现负载均衡的目的｡
二､ 采用这个方案需要注意的地方
在部署这个解决方案时,仍然有些数据库管理员需要关注的内容｡如以下这些内容,数据库管理员需要根据企业的实际情况来进行调整,以提高这个方案的价值｡#p#
首先需要考虑数据缓存服务器与数据库服务器之间同步的频率问题｡这个同步操作是一把双刃剑｡若同步的频率太高,会影响数据库服务器与缓存服务器的性能;若同步频率比较低的话,则数据库缓存服务器中的数据得不到及时的更新｡如此的话,用户查询时可能在短时间内无法获取最新的数据｡所以,一般来说,系统滞后的时间应该尽量的短,即数据库服务器的更新内容必须尽快与数据库缓存服务器进行同步｡理想的状态时,在更新数据库服务器的同时更新数据库缓存服务器｡但是,这么做是以牺牲数据库与数据库缓存服务器的性能为代价的｡为此数据库管理员在实施这个解决方案时,往往不会这么做｡而是设置在一段时间之后同步｡如可以设置为10秒､60秒､300秒或者更长的时间后进行同步｡具体这个同步的时间间隔多少为好,没有一个统一的标准｡这需要数据库管理员根据企业对数据同步的要求不同而定｡一般来说,数据库管理员在满足用户需要的前期下,可以将这个时间设置的相对长一点｡这可以避免因为过多的同步操作而降低了这个方案的价值｡其实,对于大部分用户来说,60秒左右的时间差异还是可以接受的｡如在论坛中,一个人发帖后,在一分钟之后看到一般不会有什么问题｡对于人的感觉来说,这个一分钟时间不长｡但是对于数据库服务器来说,这一分钟可以做很多事情｡所以,适当延长这个同步时间,却可以在很大程度上提高数据库服务器性能｡这个时间的代价,有时候还是值得的｡
其次,在数据库服务器与数据库缓存服务器之间,应该建立比较直接的､快速的网络连接｡当用户比较多时,数据库服务器与数据库缓存服务器之间若发生同步操作,则会造成很多的网络流量｡有时候同步操作发生时,影响这个工作的效率可能并不是数据库服务器或者数据库缓存服务器本身,而是他们之间的网络连接｡由于其可用的带宽跟不少数据库服务器系统的吞吐量,从而影响到了同步操作的效率｡为此,在数据库服务器与数据库缓存服务器之间的网路连接,应该尽量的直接｡如最好不要在中间夹着其他的不必要的网络设备;也最好不要在他们之间配备防火墙等安全策略｡这些安全策略与网络设备都会在很大程度上影响到这个同步操作的效率｡另外,最好也不要有其他的应用服务来争抢带宽｡所以简单的说,如果可能的话,在数据库服务器上部署多张网卡,直接与数据库源服务器实现双机互联,而那传输同步操作需要的数据,这是一个很不错的手段｡由于其数据传输更直接､而且其他设备或者应用服务也会来争夺其带宽,同时又可以克服他们的非法攻击｡为此,只要他们之间多距离比较短的话,采用这种方案可能效果会比较好,可以在最大程度内缩短这个同步操作所需要的时间,从而让其他用户尽早看到更新的数据｡
三、为同步选择合适的复制方案
那么该如何实现数据库服务器与缓存服务器之间的同步呢?在SQLServer数据库中,有三个方案可供数据库管理员选择｡这三个方案分别为快照复制､合并复制与事务复制｡这三个复制模型各有各的特点｡不过从最终效果来看,其都可以实现数据库服务器与数据库缓存服务器之间的同步｡不过由于其内部的实现机制不同,为此其虽然结果相同,但是从性能等方面考虑,还是有差异的｡各种复制模型的原理与特点属于基本知识的范畴,笔者在这里就不做过多阐述了｡笔者认为,在利用这个数据库缓存服务器来实现负载均衡的方案中,最好采用事务复制的同步方案｡因为相比其他方案来说,事务日志能够满足事务的一致性､数据库服务器系统比较大的吞吐量､同步时尽量少的开销､以及系统比较短的滞后时间等等需求｡另外在有些企业中采用这个方案的话,还要考虑到表与记录的过滤需求｡而通过事务复制的话,就可以实现对列和行的过滤｡而其他复制模型的话,只能够部分满足这些需求｡所以,笔者认为,在选择数据同步方案时,可能选择事务复制来实现同步,更加的合适｡不过最终是否真是如此,还是要求数据库管理员根据企业的实际需要,然后分别采用几个复制模型来进行测试,才能够得出真正合理的结果｡
