背景
云存储网关支持通过文件协议 NFS/SMB 来访问 OSS Bucket 里面的数据, 用户通过创建 NFS/SMB 共享并绑定 OSS Bucket 从而实现以文件协议对 OSS Bucket 进行操作和管理. 为了访问网关共享对应的 OSS Bucket 里面的存量数据, 或者想获取到 OSS Bucket 里面新增加的文件的话, 就需要将 OSS Bucket 里面的数据同步到云存储网关的共享里面. 云存储网关主要提供了反向同步和极速同步两种方法来同步 OSS Bucket 里面的数据到网关侧的共享里. 本文将对这两种数据同步的方法均做下介绍, 给出它们的实现原理以及分别适用的场景.
反向同步
首先是反向同步的功能, 这个是网关从公测开始就有的功能. 用户可以在创建共享的时候打开反向同步功能或者通过共享设置页面动态的打开关闭这个功能.
和反向同步功能相关的一个非常重要的参数就是 "反向同步时间间隔". 假设反向同步的时间间隔是 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 消息队列, 网关从消息队列获取到增量变化之后再应用到网关本地.
更详细的极速同步相关操作步骤可以参见文件网关秒级同步 OSS 变更对象初体验.
小结
相信到了这里大家已经对反向同步和极速同步两种数据同步方案的机制有所了解了. 反向同步是基于对文件夹进行全量扫描比对的方式来发现 OSS Bucket 里面的数据变化, 极速同步则是基于 OSS Bucket 数据变化增量的方式来实现的. 明白了这两种方法的原理, 也就明白了为什么在数据量大的情况下, 开启反向同步时访问文件夹有时候会有卡顿, 但是极速同步的情况下则不会. 实现机制的不同实际上决定了它们在处理这种情况下的不同行为. 相信看到这里您也明白了反向同步能做的事情极速同步基本都能做, 而且能做的更好. 具体来说:
极速同步的访问体验相较反向同步来说要好, 避免了全量扫描的方式, 所以一般不会有明显的卡顿.
极速同步的增量发现原理注定它能够更快的处理 OSS Bucket 到网关共享的数据同步, 因为它不需要等到用户访问某个文件夹的时候再去做比对并触发同步. 一般来说基本都是秒级就能感知到 OSS Bucket 里面的数据变化, 并在用户未访问时就已经在网关共享里面应用了增量.
最后提一下很多用户非常关心的费用问题. 开通极速同步同时需要开通阿里云 MNS 消息队列服务, 这个需要一定的费用, 但是如果 OSS Bucket 里面数据量比较大或者用户访问的非常频繁的话, 实际上这种方案反而更加实惠, 因为反向同步扫描 OSS Bucket 时也会产生大量的 API 调用次数. 因为各个用户的访问频率以及数据量均有不同, 用户可以根据自己的情况自己选择, 不过基于极速同步良好的用户体验, 绝对值得一试.
来源: https://yq.aliyun.com/articles/746659