背景
云存储网关支持通过文件协议NFS/SMB来访问OSS Bucket里面的数据，用户通过创建NFS/SMB共享并绑定OSS Bucket从而实现以文件协议对OSS Bucket进行操作和管理。为了访问网关共享对应的OSS Bucket里面的存量数据，或者想获取到OSS Bucket里面新增加的文件的话，就需要将OSS Bucket里面的数据同步到云存储网关的共享里面。云存储网关主要提供了反向同步和极速同步两种方法来同步OSS Bucket里面的数据到网关侧的共享里。本文将对这两种数据同步的方法均做下介绍，给出它们的实现原理以及分别适用的场景。
反向同步
首先是反向同步的功能，这个是网关从公测开始就有的功能。用户可以在创建共享的时候打开反向同步功能或者通过共享设置页面动态的打开关闭这个功能。
![reversesync]( "reversesync")
和反向同步功能相关的一个非常重要的参数就是“反向同步时间间隔”。假设反向同步的时间间隔是10s，它的含义是说在用户访问某个文件夹或者它下面的某个文件时，网关会检查这个文件夹的同步时间，如果发现这个文件夹已经有超过10s没有同步了，则会从OSS里面同步一次该文件夹的内容，并更新该文件夹的同步时间。这个地方“同步”的含义主要是说会将该文件夹下面的子文件和子文件夹的元数据在网关侧做更新，真正的文件数据部分的读取还是会在用户真正读某个文件的时候才会发生(除非用户指定说需要读取数据部分)。所以说实际上这是一个按需同步的功能，主要是为了节省API调用次数，毕竟OSS的API是按照调用次数收费的。需要注意的是它并不是说每10s网关就会对这个文件夹自动从OSS里面同步一次。
网关每次同步某个文件夹的时候，要将当前OSS Bucket里面对应文件夹下一级的子目录和子文件都检查一遍看是否有变动，网关要检查完所有的下一级的子文件和子目录才会返回。实际上一般会同步两层目录结构，因为访问某个文件夹的时候，客户端的操作系统同时也会访问这个文件夹下面所有子项的属性，如果子项里面有文件夹的话，就会再触发一次该子文件夹的同步。
所以在子文件或者子目录数目比较多的情况下，反向同步其实是个很耗时的动作，从用户的角度来看就是在Windows下用户浏览某个文件夹的时候，会感觉到明显的卡顿，在Linux下cd进入某一个目录的时候会有类似的体验。不过如果整个OSS Bucket里面的数据分布是比较均衡的话，就是说每个文件夹下一级的子项并不是很多，可能只有几百甚至几十，但是整个Bucket层次比较深的情况下，反向同步的体验其实也能满足很多用户的需要，因为这个时候需要从OSS Bucket同步的文件数目会明显少于上一节的情况。
极速同步
从前面的介绍可以看到反向同步虽然能够将数据同步到网关侧的共享里面，但是在某些情况下它的缺点也比较明显。即使某个文件夹下面的数据没有任何变化，在反向间隔时间过去之后，用户再次访问这个文件夹，还是要从OSS Bucket里面做一次到网关共享的同步，影响用户的体验。为了解决这个痛点，网关在1.1.0版本提出了一种可以同步OSS Bucket里面数据增量的方法。
简单来说极速同步的工作原理是说刚启用的时候，它会同步一次所有OSS Bucket里面的数据，在第一次全量的数据同步完成之后就会监听OSS Bucket里面的文件的变化，当某个文件变化了，网关就会去新建/删除/更新对应的网关侧的文件，这样就完全不再需要通过时间间隔定时去OSS Bucket里面同步某个文件夹。
所以从用户体验的角度来说，最开始启用极速同步的时候需要等待一段时间做全量OSS Bucket里面数据的同步，访问共享会慢一些。一旦同步完成之后，后面所有的更新就都是增量的了，用户几乎不会感觉到任何的操作延迟，因为访问文件夹的时候不再需要比对文件夹下面的所有文件。
极速同步的配置最关键的是需要创建一个同步组，这个同步组就是网关共享和OSS Bucket之间的桥梁，通过这个同步组，网关共享就可以捕获到OSS Bucket里面的文件增量变化。OSS会将变化推送到阿里云MNS消息队列，网关从消息队列获取到增量变化之后再应用到网关本地。
![syncgroup]( "syncgroup")
更详细的极速同步相关操作步骤可以参见文件网关秒级同步OSS变更对象初体验。
小结
相信到了这里大家已经对反向同步和极速同步两种数据同步方案的机制有所了解了。反向同步是基于对文件夹进行全量扫描比对的方式来发现OSS Bucket里面的数据变化，极速同步则是基于OSS Bucket数据变化增量的方式来实现的。明白了这两种方法的原理，也就明白了为什么在数据量大的情况下，开启反向同步时访问文件夹有时候会有卡顿，但是极速同步的情况下则不会。实现机制的不同实际上决定了它们在处理这种情况下的不同行为。相信看到这里您也明白了反向同步能做的事情极速同步基本都能做，而且能做的更好。具体来说：
- 极速同步的访问体验相较反向同步来说要好，避免了全量扫描的方式，所以一般不会有明显的卡顿。
- 极速同步的增量发现原理注定它能够更快的处理OSS Bucket到网关共享的数据同步，因为它不需要等到用户访问某个文件夹的时候再去做比对并触发同步。一般来说基本都是秒级就能感知到OSS Bucket里面的数据变化，并在用户未访问时就已经在网关共享里面应用了增量。
最后提一下很多用户非常关心的费用问题。开通极速同步同时需要开通阿里云MNS消息队列服务，这个需要一定的费用，但是如果OSS Bucket里面数据量比较大或者用户访问的非常频繁的话，实际上这种方案反而更加实惠，因为反向同步扫描OSS Bucket时也会产生大量的API调用次数。因为各个用户的访问频率以及数据量均有不同，用户可以根据自己的情况自己选择，不过基于极速同步良好的用户体验，绝对值得一试。
