河北北京大型网站的数据同步机制可行方案

发布时间:2011-10-18 05:52:58  浏览次数:2570
 

河北北京大型网站的数据同步机制可行方案

首先来谈一下,什么是数据同步。

我们在网站建设|网站制作|网站设计|网站模板 过程中,常常遇到同步问题。众所周知,在大型网站上由于访问量巨大,网站往往是由大量的服务器集群组成的。此时数据库的访问压力就成为一个很大的瓶颈。为了减轻数据库的压力,可以采用以下这样一种策略,即:将一些常用的数据按照一定的规则存放在本地内存中。这样对于一些常用数据就不用去访问数据库了,转而直接从本地内存中获取,既减轻了频繁访问数据库的压力,又提高了数据处理的能力(毕竟获取本地内存的数据相比获取远程数据库的数据速度要更快)。但这里也存在这样一个问题:常用数据并不表示一成不变,那么如何在数据变化时集群中的众多服务器如何获知这些变化呢?由此引出了数据同步的问题。

 


之前一直对数据更新的模式怀有疑问,由于目前在工作中使用的模式为“推模式”,曾经和某同事商量过,为什么不采用“拉模式”呢?现在看来使用“推模式”是正确的。整个数据更新同步的大致流程是这样的。首先,数据发生了更新,然后Server端将更新部分的数据“推向”Client端,也就是服务器集中中的众多机器。由于Server端能够准确获知是哪部分数据发生了更新,因此只需将更新部分的数据“推向”Client端即可。反之,相对而言,如果使用“拉模式”,由于众多的Client端并不知道是哪些数据发生了变化,因此能采取的策略就是以下两种:

1、定时向Server端请求全部的数据,不论数据是否变化;

2、Server也保存变化部分的数据,当有Client端进行请求的时候将变化告诉Client。

 


但是这两种策略都存在有问题:

策略一的问题在于,Client每次都要从Server端获取全部数据,网络传输量大。

策略二的问题就更大了:1、由于Server端不知道哪些Client还没有更新,因此对于更新部分迟迟不敢删除,容易引起内存的溢出;2、如果数据在Client端请求Server之前发生了两次变化,则容易引起数据的混乱和污染。

 


因此使用“推模式”是一种合理的方案。机制如下:首先,Server端获取了变化,此时在Server端维护了一张Client端的列表,Server端按照列表依次通知到Client端,将数据“推向”Client端。当列表中的Client端都推送完了以后,更新部分的数据即可删除。为了防止部分Client端由于网络原因无法推送,设定的时间间隔过了以后数据一样删除,同时认为该Client已经消失,从维护列表中删除。

 


机制虽然了解了,但是这里还存在一个问题,面对数据库中的数据变化,Server端又是如何知道的呢?这里我们需要提到一个东西:Web高速缓存Cache。在Cache中有一种Cache是可以依赖于数据库的,即SqlCacheDependecy。这种Cache可以和数据表相关联,当表没有变化时,Cache一直存在,而当指定的表发生数据变化时,则Cache会做出相应的响应。有了这个利器以后,Server端的数据变化就可以由数据库自己来通知到了。

 


至此,整个同步的机制就已经大体上完成了。至于具体的细节,我还要自己再考虑一下,这其中还是有一定的探讨余地。也希望有识之士能够共同探讨。希望广州网站建设同行也可以给出自己的看法。