客户端无法过滤无效数据。客户端不理解 hash 值的具体含义，导致在本地对比 hash 值时不能过滤掉无效 hash 的情况，可能出现组织架构展示错误。

优化组织架构同步方案越来越有必要。

寻找优化思路

寻求同步方案优化点，我们要找准原来方案的痛点以及不合理的地方，通过方案的调整来避免这个问题。

组织架构同步难点

准确且耗费最少资源同步组织架构是一件很困难的事情，难点主要在：

组织架构架构数据量大。消息 / 联系人同步一次的数据量一般情况不会过百，而企业微信活跃企业中有许多上万甚至几十万节点的企业，意味着架构一次同步的数据量很轻松就会上千上万。移动端的流量消耗是用户非常在乎的，且内存有限，减少流量的消耗以及减少内存使用并保证架构树的完整同步是企业微信追求的目标。

架构规则复杂。组织架构必须同步到完整的架构树才能展示，而且企业微信里的涉及到复杂的隐藏规则，为了安全考虑，客户端不应该拿到隐藏的成员。

修改频繁且改动大。组织架构的调整存在着新建部门且移动若干成员到新部门的情况，也存在解散某个部门的情况。而员工离职也会通过组织架构同步下来，意味着超大型企业基本上每天都会有改动。

技术选型－提出增量更新方案

上述提到的问题，在大型企业下会变得更明显。在几轮方案讨论后，我们给原来的方案增加了两个特性来实现增量更新：

增量。服务端记录组织架构修改的历史，客户端通过版本号来增量同步架构。

分片。同步组织架构的接口支持传阈值来分片拉取。

在新方案中，服务端针对某个节点的存储结构可简化为：

vid 是指节点用户的唯一标识 id，departmentid 是指节点的部门 id，is_delete 表示该节点是否已被删除。

若节点被删除了，服务端不会真正的删除该节点，而将 is_delete 标为 true。

若节点被更新了，服务端会增大记录的 seq，下次客户端来进行同步便能同步到。

其中，seq 是自增的值，可以理解成版本号。每次组织架构的节点有更新，服务端增加相应节点的 seq 值。客户端通过一个旧的 seq 向服务器请求，服务端返回这个 seq 和 最新的 seq 之间所有的变更给客户端，完成增量更新。

图示为：

通过提出增量同步方案，我们从技术选型层面解决了问题，但是在实际操作中会遇到许多问题，下文中我们将针对方案原理以及实际操作中遇到的问题进行讲解。

增量同步方案

本节主要讲解客户端中增量同步架构方案的原理与实现，以及基础概念讲解。

增量同步方案原理

企业微信中，增量同步方案核心思想为:

服务端下发增量节点，且支持传阈值来分片拉取增量节点，若服务端计算不出客户端的差量，下发全量节点由客户端来对比差异。

增量同步方案可抽象为四步完成：

客户端传入本地版本号，拉取变更节点。

客户端找到变更节点并拉取节点的具体信息。

客户端处理数据并存储版本号。

判断完整架构同步是否完成，若尚未完成，重复步骤 1，若完成了完整组织架构同步，清除掉本地的同步状态。

忽略掉各种边界条件和异常状况，增量同步方案的流程图可以抽象为：

接下来我们再看看增量同步方案中的关键概念以及完整流程是怎样的。

版本号

同步的版本号是由多个版本号拼接成的字符串，版本号的具体含义对客户端透明，但是对服务端非常重要。

版本号的组成部分为：

版本号回退

增量同步在实际操作过程中会遇到一些问题：

服务端不可能永久存储删除的记录，删除的记录对服务端是毫无意义的而且永久存储会占用大量的硬盘空间。而且无效数据过多也会影响架构读取速度。当 is_delete 节点的数目超过一定的阈值后，服务端会物理删除掉所有的 is_delete 为 true 的节点。此时客户端会重新拉取全量的数据进行本地对比。

一旦架构隐藏规则变化后，服务端很难计算出增量节点，此时会下发全量节点由客户端对比出差异。