1, 需求
登录App的账号是从两个不同的系统过来,一个是zy,一个是mh。
2, 实现机制
最初采用的是全量同步,即将本系统的信息一条条的与其他系统对比,没有就新增多余就删除。这样全量同步导致的结果是过程时间执行太久,需要30分钟左右。
然后考虑用增量同步,即其他系统送操作标识过来,每张表都新增一个op_flag,A代表新增,D代表删除,M代表修改,根据这些标识进行更新。这样修改后大大提高了同步效率,只需5分钟即可完成,但出现另一个问题,维护成本太大。因为增量同步只涉及到本次的数据,上次出错的数据是不会处理的。刚上线时,肯定大大小小会存在问题,所以每次修复问题后还要对历史数据进行处理,工作量巨大,而且后续如果有新增的岗位信息,这也是个问题。
最后采用的是差集比较,全量同步和增量同步融合方式,对于具有有意义的唯一标识的表,如人员表,可将staff_id进行差集比较。对于关系表,如人员与小区的关系表,进行全量对比(staff_id必须加索引)。于非关键信息,进行增量同步,如人员的地址和姓名(只处理M)。这样处理后,执行效率高,只需5分钟左右;维护成本低,无需修复历史数据;定位问题快,可直接定位到具体的记录。
3, 具体
1)必须建立回退和备份机制
回退:当突然出现大批量账号问题导致无法登录App时,首先将所有涉及的表回退,使之能正常登录,然后才是分析和查找问题。
备份:账号信息同步出错时,必须分析是自己同步过程有误还是账号从其他系统过来就是错的,所以必须建立备份机制才能分析到底是哪一方的问题。
2)必须建立同步日志和监控机制
日志:新建一张日志表,字段至少要有时间,具体的过程名,报错或更新的信息,便于快速定位问题。
监控:将报错的具体信息插入短信表,有个短信进程每隔半个小时会扫描,将短信发给负责人,负责人能实时监控同步过程的异常信息。
3)新建一个Package包,将所有过程放到包里,便于管理
4)新建一个过程用于job执行
该过程可控制不同过程的执行顺序,如果新增或删除,就不需要修改job,直接修改该过程即可生效。
5)问题的唯一标识
进入到每个游标里时,将唯一标识记录下来,出错时把唯一标识写到表里,这样抛错的时候,不用一行行的去调试,直接定位问题所在,大大提升查找问题的效率
6)Insert语句
采用insert into table(字段)values(值)形式,不要用insert into table values()方式。因为table是链路过来的表的话,如果新增字段,没有处理的话,则会报错,采用第一种形式的话,就不会报错。
7)Update、delete语句
不要写没有where条件的update或delete语句
4, 其他
涉及到公司机密,具体代码就不上传了。