完成了容灾恢复：多层结构下分布式数据库数据容灾概要性设计，待概要设计论证无误后将进行详细设计部分。
一、概念：
对象与表的对应关系：
学校有学生表，市里有学生表，省里有学生表，它们的表结构应该是完全一致的，只不过学校的学生表只有自己学校的学生信息，市里的学生表包含了全市所有学生的信息，
省里的学生表包括了全省的学生信息，其它无差别。以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程序实现之。
