【性能优化下】组织结构同步优化二，全量同步/增量同步，断点续传实现方式

全量同步

简单理解，全量同步，咱们就是将对方所有的数据，全部同步到我们内部系统中，对于组织结构同步的时候，我们没有必要每一次都是全量的，一般是第一次，无到有的时候会用到全量同步，可以理解为全量覆盖

增量同步

那么增量同步就比较好理解了，此处的增量同步指的是，第三方数据对于目前内部系统数据来说，哪一些是增加或者变动的数据，那么就同步这一部分数据到内部系统中

那么对于我们本次同步组织结构来说，就看内部系统是否已经存在了 /IDaaS 组，如果存在了，那么就走增量同步，如果不存在，则走全量同步

全量同步基本流程

全量同步的基本流程比较简单，再来回顾一下之前文章的一张总体图

可以看到全量同步和增量同步在我们整个同步流程的第四个阶段，到这个阶段的时候，第三方组织结构的数据已经全部正确的写入到了我们的临时表中

这个时候，我们就需要将临时表中的数据按照我们的逻辑和步骤写入到正式表中

此处阶段，显示判断是否有 /IDaaS 组，如果没有，则在同步记录表中写入 同步类型为 full 全量同步，如果有 /IDaaS 组，则记录同步类型为 incr 增量同步

全量同步比较简单，总共分成两个阶段，一个阶段是全量同步组 full_sync_group，一个是全量同步用户 full_sync_user

此处比较简单，同步用户之前，自然是先要将组给同步过来，完全分清楚，对于正式表中，数据是从无到有，所以步骤相对就简单一些

🧐开始全量同步

在进行全量同步前，仍然还是检查当前的同步状态是否是 sync_in，且同步步骤是否是sync_temp_user，若不是则不处理

1. 检查用户数量是否超过平台最大限制

1. 若过程中出现 error，则关闭当前任务，不进行同步，并且将同步记录中同步状态设置为同步中断 sync_interrupt，同步记录表中重试次数 +1
2. 检查临时表有效用户 + 已有正式表中未删除用户的数量是否超过平台最大限制（一般平台会有对于一个租户最多容纳多少用户的限制），更新同步状态为同步失败 sync_fail，并且清空临时数据，通知其他服务处理失败，且关闭当前任务

2. 校验当前同步步骤是 sync_temp_user 或者 full_sync_group ，则开始正式将临时表的组信息同步到正式表中，并将当前的同步步骤修改为 full_sync_group

• 这次这样进行判断，如果是 sync_temp_user 说明第一次处理到这里，如果是 full_sync_group 步骤，说明这个步骤之前被中断了，此刻需要断点续传

• 获取临时表中的组深度，且获取按照深度排序的组列表
• 按照由浅到深的将组数据写入到正式表中
• 删除临时用户表
• 如果过程中出现 error，则在该租户的同步记录中，同步状态标记为 sync_interrupt

3. 当同步步骤是 full_sync_group 或者 full_sync_user 的时候，则开始将用户从临时表加入到正式用户表中，且将同步步骤修改为 full_sync_user

• 同理，此处这样的处理逻辑，也是为了断点续传，逻辑之外，关于一个步骤中数据库的处理都是开启事务的

• 一层一层的去添加用户，先从临时表中查询同一个深度下对应的所有用户
  
• 从正式表中读取已经存在的用户
  
• 从临时表中按照例如 1000 条每次去读取数据（有效合法用户），写到到正式表中，校验如果用户已经存在于正式表中，则记录冲突用户，且不录入该用户，反之亦然
  
• 删除临时表中已经插入到正式表中的用户数据，并在临时表中更新指定用户是非法的
  
• 如果过程中出现 error，则在该租户的同步记录中，同步状态标记为 sync_interrupt
  
• 同步结束，则将同步状态设为 sync_success ，同步步骤设置为 sync_end，同时将临时表中非法的组，非法的用户全部读书出来，将非法数据传出去
  
• 最终清除临时用户组表，和临时用户表 ，在 redis 中记录下一次需要同步的时间
  

增量同步基本流程

增量同步的话，相对步骤就会多一些，看起来可能会觉得复杂，实际上按照如下步骤走的话，会很清晰并不复杂

那么对于增量同步为什么需要那么多步骤才能保证咱们顺利同步？才能保证咱们可以断点续传？？

实际上稍加思考的话，我们就需要考虑这些问题：

• 同步数据，自然是需要先同步组
• 那么对于组的增删改查，用户的增删改，我们需要按照这样的顺序处理呢？
• 思考之后，自然是

• 删除正式表中的用户（避免后续冲突，此步骤说明最新的同步数据中没有这一部分用户）
• 添加组
• 移动用户 （如果移动的目的组不存在的话，那还玩什么？？所以添加组要放在这个步骤的前面）
• 添加用户
• 编辑用户
• 删除组

🧐开始处理增量同步数据

下面关于校验步骤的位置，理由都是为了确定当前执行的步骤是正确的，并且为了做到断点续传

1. 开始标记组

1. 校验当前同步步骤是 sync_temp_user 或者 incr_sync_markup_group，则当前的同步步骤修改为 incr_sync_markup_group
2. 读取原有正式表中的组，读取临时表中的组数据
3. 通过标记，找到新增的组，找到删除的组，并在临时用户组表中标记新增的组，在正式表中标记删除的组

2. 开始标记用户

1. 校验当前同步步骤是 incr_sync_markup_group 或者 incr_sync_markup_user，则将当前步骤修改为 incr_sync_markup_user
2. 获取原有正式表中的非IDaaS组下的用户，读取临时表中的用户，通过读取出来的临时表中的用户去读取正式表中的数据，标记哪一些用户是新增的，哪一些是修改的，哪一些是移动的（组变动了），在正式表中标记删除的用户

3. 开始处理正式表，临时表中的标记数据

1. 删除用户 ，检查当前步骤是 incr_sync_markup_user 或者是 incr_sync_delete_user 才进行，且更新步骤为 incr_sync_delete_user
2. 新增用户组，校验同步步骤是 incr_sync_delete_user 或者是 incr_sync_add_group 才进行，且更新步骤为 incr_sync_add_group
3. 移动用户，校验同步步骤是incr_sync_add_group 或者是 incr_sync_move_user 才进行，且更新步骤为 incr_sync_move_user
4. 删除用户组，校验同步步骤是 incr_sync_move_user 或者是 incr_sync_delete_group 才进行，且更新步骤为 incr_sync_delete_group
5. 新增用户，校验同步步骤是 incr_sync_delete_group 或者是incr_sync_add_user 才进行，且更新步骤为 incr_sync_add_user
6. 修改用户，校验同步步骤是 incr_sync_add_user 或者是 incr_sync_edit_user 才进行，且更新步骤为 incr_sync_edit_user
7. 如果过程中出现 error，则在该租户的同步记录中，同步状态标记为 sync_interrupt
8. 同步结束，则将同步状态设为 sync_success ，同步步骤设置为 sync_end，同时将临时表中非法的组，非法的用户全部读书出来，将非法数据传出去
9. 最终清除临时用户组表，和临时用户表 ，在 redis 中记录下一次需要同步的时间

自然，对于每一个步骤的实现方式根据实际情况来定，这只是一个例子，主要是理解，整个流程的3 张表，4 个同步状态，以及 14 个同步步骤

是怎么保证断点续传的？

可以看到对于每一个步骤都在我们的操控范围内，还记的最开始创建同步任务的时候吗？

这个 同步中断 就是用于断点续传的

可以这样来实现 断点续传

• 后台会启动一个定时任务，定时去扫同步记录表中 同步状态是 sync_interrupt 状态的记录
• 根据每一条记录是全量同步还是增量同步，来走不同的同步路径
• 再根据每一条同步记录中的同步步骤，就可以接着中断之前的步骤来进行同步数据了

自然，细心的同学还发会发，同步记录表中有重试次数这个字段，用法是每中断一次，这个字段值 +1，如果发现已经 3 次了，那么就会删除这条记录，若之后再次触发该租户的同步任务，则从 0 开始同步即可

欢迎点赞，关注，收藏

朋友们，你的支持和鼓励，是我坚持分享，提高质量的动力

好了，本次就到这里

技术是开放的，我们的心态，更应是开放的。拥抱变化，向阳而生，努力向前行。

我是阿兵云原生，欢迎点赞关注收藏，下次见~