在整个同步过程中，我们都必须保证缓存中的数据和数据库的数据的更改需要一一对应。在增量同步的情况中，我们每次需要更新 / 删除数据库中的节点，都需要更新相应的缓存信息，来保证数据的一致性。

优化数据对比

内存使用

测试方法：使用工具 Instrument，用同一账号监控全量同步和增量同步分别在首次加载架构时的 App 内存峰值。

内存峰值测试结果

分析

随着架构的节点增多，全量同步方案的内存峰值会一直攀升，在极限情况下，会出现内存不足应用程序 crash 的情况（实际测试中，30w 节点下，iPhone 6 全量同步方案必 crash）。而增量同步方案中，总节点的多少并不会影响内存峰值，仅仅会增加同步分片的次数。

优化后，在腾讯域下，增量同步方案的 App 总内存使用仅为全量同步方案的 53.1%，且企业越大优化效果越明显。并且不论架构的总节点数有多少，增量同步方案都能将完整架构同步下来，达到了预期的效果。

流量使用

测试方法：在管理端对成员做增加操作五次，通过日志分析客户端消耗流量，取其平均值。日志会打印出请求的 header 和 body 大小并估算出流量使用值。

测试结果

分析

增加成员操作，针对增量同步方案仅仅会新拉单个成员的信息，所以无论架构里有多少人，流量消耗都是相近的。同样的操作针对全量同步方案，每次请求变更，服务端都会下发全量 hash 列表，企业越大消耗的流量越多。可以看到，当企业的节点数达到 20w 级别时，全量同步方案的流量消耗是增量同步方案的近 500 倍。

优化后，在腾讯域下，每次增量同步流量消耗仅为全量同步方案的 0.4%，且企业越大优化效果越明显。

写在最后

增量同步方案从方案上避免了架构同步不及时以及流量消耗过大的问题。通过用户反馈和数据分析，增量架构同步上线后运行稳定，达到了理想的优化效果。

作者介绍

胡腾，腾讯工程师，参与企业微信从无到有的整个过程，目前主要负责企业微信移动端组织架构和外部联系人等模块的开发工作。

今日荐文

技术漫谈：为何 KPI 毁了索尼，而 OKR 却成就了谷歌？