关于大型网站的数据同步机制的试想

由于工作的关系，在编程中使用了数据同步这样一个东西。一直没有理解这个机制的原理。今天看了某本书以后忽然感到一下子豁然开朗了。趁着还没忘记，赶紧找个地方记下来。

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

之前一直对数据更新的模式怀有疑问，由于目前在工作中使用的模式为“推模式”，曾经和某同事商量过，为什么不采用“拉模式”呢？现在看来使用“推模式”是正确的。整个数据更新同步的大致流程是这样的。首先，数据发生了更新，然后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端的数据变化就可以由数据库自己来通知到了。

至此，整个同步的机制就已经大体上完成了。至于具体的细节，我还要自己再考虑一下，这其中还是有一定的探讨余地。也希望有识之士能够共同探讨。