完成了容灾恢复:多层结构下分布式数据库数据容灾概要性设计,待概要设计论证无误后将进行详细设计部分。

 一、概念:
    
  对象与表的对应关系:
  学校有学生表,市里有学生表,省里有学生表,它们的表结构应该是完全一致的,只不过学校的学生表只有自己学校的学生信息,市里的学生表包含了全市所有学生的信息,
  省里的学生表包括了全省的学生信息,其它无差别。以CITY_ID,SCHOOL_ID分别记录是哪个城市,哪个学校的学生数据。
  这样的设计,在学校上报数据时,只需按时间戳将学生信息保存到此表即可。

  时间戳:
  考虑到江西学籍共540所学校+11个市+1个省,如果使用数据库时间戳技术可能会造成不一致的情况,使用NTP同步也基本不现实,
  初步想到的是MAXID+1的解决办法,因MAXID+1产生的并发问题,将想办法尽力解决。
  select isnull(max(id),0) + 1 from 表,以下为说明方便,也将MAX_ID+1的方式说明为时间戳方式。需要特别说明的是这个MAX(ID)+1是指对学校为单位的,
  就是说比如1234这个学校,它下面有记录号,6,7,8,9,在学校2345下,也有记录号6,7,8,9,不是全表唯一的。

  删除:
  在设计时没有删除的概念,只能是打上删除标记,设置B_DEL=1,这样才能把这条记录的时间戳进行修改,上下一致

 
  副本:
  需要在学校、市、省三级都完整缓存的学生基本信息、学生异动信息表,三处缓存的表是一模一样的,互为副本。

    
  
    
  实现方式:
  因为WEB程序的无状态性,长时间运行的大事务的能力有限,所以采用 FLEX+ASP.NET+WEBSERVICE的方式进行实现。
 
   
  策略

 1、完整缓存策略
  就是全部缓存一次。

 2、时间戳同步策略(增量同步策略)
     每条记录在同步到另一个主机时,记录了这条记录转存为副本的时间戳。以后两台主机进行数据交换时,互相报一下自己的最大时间戳,决定是A向B传递数据,还是
  B向A传递数据,这里需要在表设计时避免既存在A到B,也存在B到A的情况,这样的东西设计为两张表。

  行为日志:
  通过业务撰写(或通过触发器)等方式对用户进行的操作进行完整记录。目前没有想到此功能具体有哪些实际应用价值,先放到这里,以后遇到问题再说。

  下面以一个学校学生表录入后上报为例进行具体流程说明:

  1、WEB程序在进入系统前,检查取T_BASE_STUDENT的时间戳,就是最大的变化 MAX ID,将时间戳上传到市端WEBSERVICE上,WEBSERVICE返回市端此学校的时间戳。
  2、程序负责进行对比,是学校比市里新(),还是市里比学校新。
   如果学校比市里新(如果存在未上报数据),那么把比时间戳大的那些数据取前100条上报给市端,市端保存到数据库中。递归调用此函数,再上报100条,直到数据上报完成,上下时间戳一致为止。
   如果市里比学校新(学校数据丢失,需要市里提供前100条数据,学校将数据保存到数据库,递归调用,直到上下数据完全一致)。
   
   此处可能会出现长时间与市端服务器进行数据交换的情况,用JAVASCRIPT进行表现可能不太合适,可以考虑使用FLEX+ASP.NET WEBSERVICE的方式进行比如进度条等友好提示信息的开发。
   
  3、确定此表上下一致后,学校根据报名库,录取库,收集了学生信息,然后又手工录了十名学生。
  4、教师检查后,认为无误,点击了上报按钮。我们将表中这些学生数据的需要上报标识为1。
  5、程序将需要上报标识为1,同时上报到市端的列记录为NULL的数据进行上报。上报完成后修改NULL为上报时间。
  6、至此,上下数据是完全一致的,副本保存成功。
  7、市端对学生的数据进行了修改,比如帮着把姓名修改了(当然,这不是实际业务,只是为了说明问题),那么这条记录的时间戳将进行修改,修改为此学校此表记录的MAXID+1。
  8、学校端再次进入学籍系统前,检查是不是有需要更新的数据,有需要的直接下载,保持与市端数据副本一致。

  总结:
  基于时间戳的增量副本办法,基本上可以解决数据不一致、容灾等问题,但也可能因为各种原因造成数据副本缓存失败,那时我们的备用办法将生效,就是使用完整缓存策略进行一次全新缓存。
  因为可能数据量大等问题,完整缓存可以考虑采用FLEX+WEBSERVICE程序实现之。