前言
近期，公司的云盘项目即将完成内测，这次给大伙分享一下在本地编辑保存这一场景下，用到的增量同步机制。
场景说明
首先，本地编辑的场景如下：
1、从服务端下载文件到本地；
2、使用本地应用程序打开文件进行编辑修改；
3、保存时，把文件修改内容同步到服务端；
4、再次编辑保存，再次把文件修改内容同步到服务端；
假设，这里的文件是 word 之类的格式，那么文件本身不大，整个上传占用的带宽少，时间也快。但如果，编辑的是 CAD 之类的文件，文件大小可以去到几百兆，那么占用带宽多，上传时间也随之变长。
但是，一个文件实际上是一长串的字节数据，我们可以把它分割成一块块来看。文件修改时，只会对其中一部分字节数据有所修改调整，其他大部分字节数据都不会改变。
因此，通过计算对比旧文件，可以让服务端自行复制大部分内容相同的文件字节块，客户端只针对修改过的字节块进行上传即可，这样一来，上传时间将大大缩短。
原理及操作步骤
具体的原理及步骤如下：
1、服务端以 500KB（步长根据文件大小情况调整）作为步长，把原文件进行分割，分别计算其 Alder32值（弱哈希）和 MD5值（强哈希）；
2、客户端把从服务端拿到的弱哈希值作为 key，强哈希值和块号作为值，构建出 map 映射表；
3、客户端对新文件字节数据，用同样的步长和滑动窗口计算哈希值。
（1）若弱哈希值存在，随后对比强哈希值，强哈希值也匹配，则认为文件块在原文件存在，请求服务器对新文件写入原文件中的指定文件块。
（2）若弱哈希值不存在，或者强哈希值不一致，则右移一位字节再计算，直到遇到存在的块，则把前面的字节上传到服务端写入新文件。
（3）直到把新文件字节数据全部遍历计算完成。
最终在服务端，会得到这样的一个数据数组。
图中，红色块表示在原文件已匹配上，不用传输。而白色块就是需要传输的内容，服务端会根据这些数据块重新生成新的文件。
通过只对变更的部分进行传送，其他相同文件块由服务端去复制写入，能大大减少数据的传输和加快大文件的上传速度。
对于像 CAD 等大文件编辑保存同步的场景下，尤为有效。
以上就是本期分享，如果大家对此感兴趣，欢迎各位关注、留言，大家的支持就是我的动力！