关于性能:性能优化下组织结构同步优化二全量同步增量同步断点续传实现方式

看到这一篇文章的 xdm，应该对组织构造同步有一些想法了吧，如果没有，能够看后面两篇文章，能够通过如下地址查看一下：

• 【性能优化上】第三方组织构造同步优化一，你 get 到了吗？

<!—->

• 坑爹，线上同步近 3w 个用户导致链路阻塞引入发的线上问题，你经验过吗？

这类文章，次要是冀望能给 xdm 带来不一样的思考，如有表述不当的中央，还请不吝赐教，冀望对你有帮忙😀

这篇文章次要是论述将长期表中的用户组数据 / 用户数组，依照既定的步骤同步到咱们的正式表，过程中遇到异常中断，能够对咱们的正式平台无影响，可能保障下一次同步工作过去依然能够进行断点续传

首先全量同步和增量同步别离指什么？🧐🧐

🔥全量同步

简略了解，全量同步，咱们就是将对方所有的数据，全副同步到咱们外部零碎中，对于组织构造同步的时候，咱们没有必要每一次都是全量的，个别是第一次，无到有的时候会用到全量同步，能够了解为全量笼罩

🔥增量同步

那么增量同步就比拟好了解了，此处的增量同步指的是，第三方数据对于目前外部零碎数据来说，哪一些是减少或者变动的数据，那么就同步这一部分数据到外部零碎中

那么对于咱们本次同步组织构造来说，就看外部零碎是否曾经存在了 /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 开始同步即可

至此，对于本次组织构造同步的内容更新结束，如果对你可能带来一些思考的话，欢送冒个泡吧

感激浏览，欢送交换，点个赞，关注一波 再走吧

欢送点赞，关注，珍藏

敌人们，你的反对和激励，是我保持分享，提高质量的能源

好了，本次就到这里

技术是凋谢的，咱们的心态，更应是凋谢的。拥抱变动，背阴而生，致力向前行。

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

文中提到的技术点，感兴趣的能够查看这些文章：

• 【性能优化上】第三方组织构造同步优化一，你 get 到了吗？

<!—->

• 坑爹，线上同步近 3w 个用户导致链路阻塞引入发的线上问题，你经验过吗？

<!—->

• OAUTH 之钉钉第三方受权