如何同步OSS Bucket数据到云存储网关SMB/NFS共享
背景
云存储网关支持通过文件协议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调用次数。因为各个用户的访问频率以及数据量均有不同,用户可以根据自己的情况自己选择,不过基于极速同步良好的用户体验,绝对值得一试。
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Spring Boot(十三):实现热部署
一、前言 在实际开发过程中,每次修改代码就得将项目重启,重新部署,对于一些大型应用来说,重启时间需要花费大量的时间成本。对于一个后端开发者来说,重启过程确实很难受。在java开发领域,热部署一直是一个难以解决的问题,目前的java虚拟机只能实现方法体的热部署,对于整个类的结构修改,仍然需要重启虚拟机,对类重新加载才能完成更新操作。 二、原理 深层原理是使用了两个ClassLoader,一个ClassLoader加载那些不会改变的类(第三方jar包),另一个ClassLoader加载会改变的类,称为restartClassLoader,这样在有代码更改的时候,原来的restartClassLoader被丢弃,重新创建一个restartClassLoader,由于需要加载的类相对少,所以实现了较快的重启时间。 三、springboot实现热部署的三种方式 (一)Spring Loaded Spring Loaded是一个用于在JVM运行时重新加载类文件更改的JVM代理,Spring Loaded允许你动态的新增、修改、删除某个方法、字段、构造方法,同样可以修改作用在类、方法、字段、构造方法...
- 下一篇
【云栖号案例 | 交通&物流】启迪公交上云助力北京公交二维码乘车业务系统顺利上线
云栖号案例库:【点击查看更多上云案例】不知道怎么上云?看云栖号案例库,了解不同行业不同发展阶段的上云方案,助力你上云决策! 公司介绍 我们公司是国内领先的公交出行服务提供商,通过承接公交信息化和智慧化项目建设,应用最先进的互联网商业模式,将“人、车、线、站”的大数据资源及相关配套资源进行商业化转换,实现行业引领,提升公交系统的创新能力和服务水平。 业务痛点 使用传统IT架构,缺少可靠的数据传输机制。 使用传统IT架构,缺少有效的对硬件设备安全管控的机制,以及对设备远程监控和管理的能力。 解决方案 解决方案逻辑图 方案细节: 阿里云物联网平台为车载刷卡机提供安全可靠的连接通信能力,支撑了约6万个车载刷卡机设备数据采集上云。同时,向管理平台提供云端API,方便管理平台通过调用云端API将指令下发至设备端,实现远程应用更新、远程参数下发等功能。 上云价值 北京公交二维码乘车业务系统方案基于阿里云物联网平台开发。通过使用阿里云物联网平台,车载刷卡机可方便的应用阿里云设备端SDK快速连接上云,效率和安全性高,便于拓展业务。 阿里云物联网平台具有亿级设备的连接管理能力、百万级并发处理能力,架构支撑...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
推荐阅读
最新文章
- Windows10,CentOS7,CentOS8安装Nodejs环境
- Red5直播服务器,属于Java语言的直播服务器
- CentOS6,CentOS7官方镜像安装Oracle11G
- CentOS关闭SELinux安全模块
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS7编译安装Gcc9.2.0,解决mysql等软件编译问题
- SpringBoot2整合Thymeleaf,官方推荐html解决方案
- CentOS7安装Docker,走上虚拟化容器引擎之路
- CentOS7,CentOS8安装Elasticsearch6.8.6
- CentOS8,CentOS7,CentOS6编译安装Redis5.0.7