CN114385090B - 基于对象存储站点同步机制的数据自动处理方法及装置 - Google Patents

Abstract

本发明公开了一种基于对象存储站点同步机制的数据自动处理方法及装置，该方法包括如下步骤：S1、将处理参数和过程配置预配置为策略；S2、在上传对象时，自定义请求头携带策略id，业务RGW将策略记录在bilog和metadata中；S3、利用站点同步机制，在全量同步的时候通过metadata获取策略id，在增量同步的时候通过bilog获取策略id，并连同对象信息，生成处理请求，发往消息队列；S4、处理服务从存储拉取对象，根据策略进行处理。本发明利用ceph多站点数据同步功能，将数据分发到不同的处理服务，实现异步的数据处理功能，不需要依赖额外的组件实现数据转发，不影响存储基础功能使用。

Description

基于对象存储站点同步机制的数据自动处理方法及装置

技术领域

本发明涉及一种数据自动处理方法，特别是涉及一种基于对象存储站点同步机制的数据自动处理方法及装置。

背景技术

相关概念

对象存储

对象存储（Object Storage Service，OSS），也叫基于对象的存储，是一种解决和处理离散单元的方法，可提供基于分布式系统之上的对象形式的数据存储服务。对象存储和我们经常接触到的块和文件系统等存储形态不同，它提供RESTful API数据读写接口及丰富的SDK接口，并且常以网络服务的形式提供数据的访问。

Ceph

Ceph是一个统一的分布式存储系统，设计初衷是提供较好的性能、可靠性和可扩展性。

Ceph项目最早起源于Sage就读博士期间的工作（最早的成果于2004年发表），并随后贡献给开源社区。在经过了数年的发展之后，目前已得到众多云计算厂商的支持并被广泛应用。RedHat及OpenStack都可与Ceph整合以支持虚拟机镜像的后端存储。

RGW

RGW全称RADOS gateway，是Ceph对外提供的对象存储服务，接口与S3和Swift兼容。

RGW分为业务RGW和同步RGW两种：

业务RGW：主要负责通过s3或swift协议提供对象存储服务。

同步RGW：主要负载不同站点间数据同步。

Object metadata

对象元数据记录了对象的属性，包括所属桶、版本信息、自定义标签、权限等。

Bilog

对象操作日志，对象的每次修改都会记录一条单独的bilog。

Ceph multisite

Ceph RGW 多数据中心（multisite）功能旨在实现异地双活，提供了备份容灾的能力。并且具有多个数据中心供用户选择，存放资源。

主节点在对外提供服务时，用户数据在主节点落盘后即向用户回应“写成功”应答，然后实时记录数据变化的相关日志信息。备节点则实时比较主备数据差异，并及时将差异化数据拉回备节点。异步复制技术适用于远距离的容灾方案，对系统性能影响较小。

Ceph 数据同步

在ceph中，数据的存储单元是bucket，在索引池内，一个bucket会分为若干个bucket shard对象，用于记录对象元数据，bilog，gclog（垃圾回收日志），bucket header（对象存储单元头信息），合并大对象等功能。

客户端写入数据时，会用bucket id+对象名拼接出RGW对象的对象名，hash获得其对应的bucket shard对象，由于bucket id和对象名是固定的，下次put（把对象上传）或者get（把对象下载）都是落入同一bucket shard对象内，当元数据更新完成以后，在cls（Ceph的一个扩展模块）层会在bucket shard记录一次bilog，在RGW层会在datalog（即data_log，数据日志）对象记录一次datalog。

当某个bucket shard发生数据更新（put，delete，update）后，RGW会将该bucketshard记录到map，然后RGW每隔20多s会刷新一次，将map记录的所有bucket shard记录到对应的datalog对象里。这里bucket shard也是自身名通过hash计算出要写入的datalog对象。

站点网络是通过zone里的配置实现的。 每个zone都会持有一个相同period（zone和zone group的状态信息），这个period主要记录各个站点的信息，RGW可以解析该period，可知道当前需要同步哪些zone，这些zone的同步端口是多少，即可建立同步网络。Ceph的多站点同步示意图如图1所示。

同步分为全量同步和增量同步

全量同步

Bucket shard同步需要初始化一次同步状态，最初的时候是构造一个空的bucketshard同步类，然后判断bucket是否存在，如果没有，就触发一次bucket元数据的同步。等元数据同步成功后，开始往下走，首先bucket的状态会被置为state_init，意为刚同步，需要初始化同步状态。获取对端bucket status记录的最新的版本和操作日志同步记录（实际没有写入最新的marker），将bucke status同步状态改为全量同步状态，将其写入到本地的bucket shard同步对象的bucket.sync-status.zone_id:bucketname:bucketid.shardid属性中。

全量同步：bucke status全量同步比较简单，实际就是同步端发送了查询桶信息的请求，全量列举该bucket shard的数据。获取到对象集合以后，RGW会逐个构造单次处理协程，处理单个对象的同步。当然协程数是有窗口限制的，全量同步完成以后，就会转为增量同步状态。

增量同步

为了规避某些bug，增量同步是从对端的bilog从头开始同步的（最初的同步标记为空）增量同步的方式也比较简单，先拿查询标记以后的bilog，拿到bilog后，逐个解析成对应的object，然后创建单次处理协程，同步单个对象。这里会有合并的过程，如果是对某个对象的反复操作，只需要同步最后一个覆盖写即可。有几个规则：

1、修改元数据（只同步元数据）不会作为最后一个合并的bilog。

2、如果有追加写操作，那么不能跳过删除的操作。

单个bucke status的增量同步协程是有时间限制的，当它处理完一组bilog后，需要判断是否超过特定的时间，超过特定时间时，就会往上层返回，当所有bucke status协程都返回后，该datalog协程就会进入休眠，等待唤醒。

数据处理

将存储在对象存储中的文件，根据不同的业务需求，进行二次加工，比如：针对图片，可以做图片的压缩、裁剪、水印；针对视频，可以做抽帧、裁剪； 针对一些文本格式的对象文件，可以做内容提取。

现有技术一的技术方案

现有技术公开了一种RADOS Gateway（RGW）的多媒体处理方法（CN110968704A），利用s3协议自定义元数据的特性，将多媒体的资源处理参数放在请求header中的用户自定义元数据字段中，如图2所示，客户端将请求发送至Openresty（基于NGINX和LuaJIT的Web平台）服务网关中，网关根据多媒体数据的大小选择同步或异步两种方式下发多媒体处理任务，Openresty将请求转发到RADOSGateway中，当RADOS Gateway完成操作后，同步方式使用http_image_filter_module模块直接处理多媒体数据并返回给客户端，异步方式将任务下发到Kafka再由多媒体处理程序进行处理，进而更新处理结果到数据库中以方便后续客户端查询。具体步骤为：

1、将多媒体数据处理参数写入到s3请求中的用户自定义元数据字段

定制S3协议中request header中自定义元数据字段，如为图片数据的resize处理定义x-meta-height和x-meta-width来声明resize后的高和宽，将多媒体处理的相关参数通过header的方式传给对象存储服务端。

2、复杂均衡层根据处理数据的大小决定同步还是异步进行多媒体数据的处理

请求发送到OpenResty以后，数据量小的时候直接向RADOS Gateway请求数据，拿到数据后利用http_image_filter_module模块完成对象数据的多媒体处理过程，处理结束后将结果返回给客户端；数据量大的时候，OpenResty先将请求转发到RADOS Gateway，返会后利用log_by_lua_file模块向多媒体处理服务端发送异步任务到kafka，然后多媒体处理程序进行处理并将处理状态存入数据库中，等待客户端查询。

3、多媒体数据处理状态的返回

当异步完成多媒体数据处理时，客户端向Openresty层发起任务查询请求，Openresty接收到请求后去数据库中查询相应的处理状态返回给客户端。

该现有技术的不足：现有的数据转发,需要借用OpenResty进行数据转发, 增加了额外的依赖；使用自定义请求头携带全部处理参数,导致请求头臃肿。

发明内容

本发明提供一种基于对象存储站点同步机制的数据自动处理方法及装置，以解决对象存储中数据二次加工的问题。

本发明的技术问题通过以下的技术方案予以解决：

一种基于对象存储站点同步机制的数据自动处理方法，包括如下步骤：S1、将处理参数和过程配置预配置为策略；S2、在上传对象时，自定义请求头携带策略id，业务RGW将策略记录在bilog和metadata中；S3、利用站点同步机制，在全量同步的时候通过metadata获取策略id，在增量同步的时候通过bilog获取策略id，并连同对象信息，生成处理请求，发往消息队列；S4、处理服务从存储拉取对象，根据策略进行处理。

在一些实施例中，还包括如下改进：

步骤S3中包含解析请求头步骤，其进一步包括：在通过restful api上传对象到存储时，携带自定义请求头，值为策略id；业务RGW发现请求头，将策略id记录到metadata和bilog中。

步骤S3中包含利用站点同步机制过滤出待处理对象的步骤，其包括：全量同步：从主站点获取对象的metadata，根据metadata中的策略信息过滤是否需要进行处理；增量同步：从主站点获取bilog，根据bilog中的策略信息过滤是否需要进行处理。

还包括同步站点配置步骤，其包括：创建数据站点，作为数据源，供处理站点进行数据同步；创建处理站点，同时将数据站点作为数据源注册到处理站点；创建业务RGW，通过业务RGW管理数据站点数据；配置数据站点同步RGW，负责将变化的数据同步到处理站点；配置处理站点同步RGW，负责接收数据站点同步RGW发送的同步通知，并根据处理策略配置生成处理请求，转发到数据处理服务。

同步站点配置完成后，还包含创建策略步骤，其包括：通过策略管理api，配置图片处理参数，包括缩放比例，生成缩略图存放位置。

同步站点配置完成后，还包含上传对象步骤：通过s3 put object api上传对象，设置请求头。

上传对象包括如下步骤：客户端在上传对象的请求中，携带请求头，该请求头为处理策略id；业务RGW接收到上传请求后，解析请求，存储对象数据；业务RGW解析`x-mos-handle-policy`请求头，将请求头配置的策略id记录在对象元数据中；记录一条数据写入的bilog；向同站点同步RGW发送数据写入通知消息；响应客户端请求结束；客户端结束数据上传，对象上传成功。

上传对象步骤之后还包括同步RGW流程，其包括如下步骤：同步RGW接收到业务RGW的数据同步通知消息；解析通知消息，发起拉取元数据的请求；业务RGW接收到元数据读取请求，读取对象元数据传输给同步RGW；根据获取到的对象元数据，解析其中的策略id；根据策略id读取策略信息；根据对象信息/策略信息生成数据处理请求；根据策略信息中注册的服务信息，决定发往哪个服务；处理完成后，更新本地bilog同步记录marker。

同步RGW除了在接收到同步通知时会进行数据同步，还会定时从数据站点获取最新的bilog进行同步。

同步RGW在第一次启动时，会进行一次全量同步，从数据站点同步所有数据。

还包括处理服务流程，其包括：处理服务受到请求，解析对象信息和策略信息；从业务RGW拉取对象到本地；根据策略中处理参数配置，进行处理；将处理结果输出。

本发明还提供一种基于对象存储站点同步机制的数据自动处理装置，包括处理器和存储器，其特征在于，所述存储器中存储有计算机程序，所述计算机程序可被处理器读取并执行以实现如上所述的方法。

本发明与现有技术对比的有益效果包括：本发明提供的基于对象存储站点同步机制的数据自动处理方法，利用ceph多站点数据同步功能，将数据分发到不同的处理服务，实现异步的数据处理功能，不需要依赖额外的组件实现数据转发（比如减少了对Openresty的依赖），不影响存储基础功能使用；模板化的处理策略，通过组合不同处理功能，实现复杂业务需求，降低单个处理服务复杂度；处理参数提取为策略, 上传对象时只需要携带策略id,即可指定处理参数, 缩减了请求头数量。

附图说明

图1是现有技术的Ceph的多站点同步示意图。

图2是现有技术的基于Ceph的的多媒体处理方法的流程图。

图3是本发明的数据自动处理方法的流程图。

图4是本发明的总体架构示意图。

图5是本发明的对象写入流程图。

图6是本发明的业务站点同步流程图。

图7是本发明的数据处理站点定时同步流程图。

图8是本发明的数据处理站点全量同步流程图。

具体实施方式

下面对照附图并结合优选的实施方式对本发明作进一步说明。需要说明的是，在不冲突的情况下，本申请中的实施例及实施例中的特征可以相互组合。

需要说明的是，本实施例中的左、右、上、下、顶、底等方位用语，仅是互为相对概念，或是以产品的正常使用状态为参考的，而不应该认为是具有限制性的。

缩略语和关键术语定义

Ceph：一个统一的分布式存储系统

Bilog：bilog ceph【ceph是是一个统一的分布式存储系统】同步日志【下文提到bilog是对象操作日志，对象的每次修改都会记录一条单独的bilog】

Gclog：垃圾回收日志

Metadata：metadata ceph对象元数据

Bucket：bucket ceph对象存储单元

bucket shard：bucket shard ceph中bucket切分成多个bucket shard管理对象

RGW：rados gateway ceph对象存储网关

MQ：message queue消息队列

zone：zone 站点

data_log：data_log 记录bucket shard中数据的变化状态

bucket status：bucket的状态

state_init：bucket的一种状态，意为刚同步

RESTful：典型的基于HTTP的协议

RESTful API：REST风格的API

RedHat：一种开源技术

OpenStack：一种开源技术

bucket header：对象存储单元头信息

hash：哈希操作

put：把对象上传

get：把对象下载

cls：Ceph的一个扩展模块，它允许用户自定义对象的操作接口和实现方法，为用户提供了一种比较方便的接口扩展方式

datalog：数据日志

period：zone和zone group的状态信息

zone group：由多个zone组成，一个zone group内的zone之间可以自动同步data和meta

x-mos-handle-policy：指定处理策略的http请求头

2.1 本发明下述实施例所要解决的技术问题

本发明下述实施例提供一种基于对象存储站点同步机制的数据自动处理方法，以解决对象存储中数据处理问题, 同时将处理流程和配置提取为策略, 处理请求只需携带策略id即可, 解决请求头臃肿的问题。

2.2 本发明下述实施例技术的详细阐述

本章节为2.3章节的主要步骤说明

如图3所示，本发明的基于对象存储站点同步机制的数据自动处理方法包括以下步骤：

S1、将处理参数和过程配置预配置为策略；

S2、在上传对象时,自定义请求头携带策略id,业务RGW将策略记录在bilog和metadata中；

S3、利用站点同步机制,在全量同步的时候通过metadata获取策略id,在增量同步的时候通过bilog获取策略id,并连同对象信息,生成处理请求,发往消息队列；

S4、处理服务从存储拉取对象,根据策略进行处理。

本发明实施例的总体架构图如图4所示。

2.2.1 解析请求头

如图5所示，在通过restful api上传对象到存储时,携带自定义请求头“x-mos-handle-policy”,指定预创建策略。

业务RGW发现请求头,将策略id记录到metadata和bilog中。

2.2.2 利用站点同步机制过滤出待处理对象

站点同步是通过同步RGW,将一个站点的数据变化同步到其他属于同一zonegroup的站点的过程。

每个站点都需要有一个或者多个同步RGW处理同步业务。

同步分为全量和增量,同步RGW初次创建会进行一次全量同步,之后通过业务RGW通知或者定时方式进行增量同步。

当数据有变化后,业务RGW会在记录metadata和bilog后,给当前站点的同步RGW发送通知；

全量同步:

从主站点获取对象的metadata,根据metadata中的策略信息过滤是否需要进行处理。

增量同步:

从主站点获取bilog,根据bilog中的策略信息过滤是否需要进行处理。

在本发明中,将不同的数据处理服务模拟成不同的zone,利用站点同步机制,在同一个存储集群中执行zone之间的数据同步,达到将待处理对象同步到不同处理服务的目的。

2.3本发明技术的具体流程

根据2.2章节内容,下面以一张图片数据的缩放请求同步过程过程作为示例。

2.3.1同步站点配置

步骤S1：

Ceph中站点分为两类：数据站点和处理站点。

数据站点：提供数据存储功能。

处理站点：提供数据处理功能。

两个站点通过同步机制进行数据流转。

同步站点配置步骤如下：

1. 创建数据站点, 作为数据源, 供处理站点进行数据同步

2. 创建处理站点, 同时将数据站点作为数据源注册到处理站点

3. 创建业务RGW, 通过业务RGW管理数据站点数据

4. 配置数据站点同步RGW, 负责将变化的数据同步到处理站点

5. 配置处理站点同步RGW, 负责接收数据站点同步RGW发送的同步通知, 并根据处理策略配置生成处理请求, 转发到数据处理服务

2.3.2创建策略

步骤S1：

策略管理api由同步RGW提供,每个处理站点的同步RGW负责管理本站点处理策略的前提为：

1.同步站点配置完成；

2.每个站点都配置了同步RGW。

创建策略的步骤如下：

1.通过策略管理api, 配置图片处理参数, 包括缩放比例, 生成缩略图存放位置, 缩略图命名方式。

e.g.策略格式如下json所示：

{

"enable": true,

"id": 12,

"name": "image",

"operators": [

{

"api": 1,

"params": {

"width": "10",

"height": "10"

},

"service": "image-convert",

"type": "idpp"

}

]

}

2.3.3上传图片

步骤S2：

上传图片的前提为：

1.同步站点配置完成；

2.每个站点都配置了同步RGW。

上传图片的步骤如下：

通过s3 put object api上传对象,设置请求头`x-mos-handle-policy`: 12

2.3.4业务RGW流程

步骤S2：

业务RGW的前提为：

1.同步站点配置完成；

2.每个站点都配置了同步RGW。

业务RGW的步骤如下：

1.客户端在上传对象的请求中,携带`x-mos-handle-policy`请求头,该请求头为处理策略id；

2.业务RGW接收到上传请求后,解析请求,存储对象数据；

3.业务RGW解析`x-mos-handle-policy`请求头,将请求头配置的策略id记录在对象元数据中；

4.记录一条数据写入的bilog；

5.向同站点同步RGW发送数据写入通知消息；

6.响应客户端请求结束；

7.客户端结束数据上传,对象上传成功

2.3.5同步RGW流程

步骤S3：

同步RGW的前提为：

1.同步站点配置完成；

2.每个站点都配置了同步RGW。

如图6所示，同步RGW的步骤如下：

1.同步RGW接收到业务RGW的数据同步通知消息；

2.解析通知消息,发起拉取元数据的请求；

3.业务RGW接收到元数据读取请求,读取对象元数据传输给同步RGW；

4.根据获取到的对象元数据,解析其中的策略id；

5.根据策略id读取策略信息；

6.根据对象信息/策略信息生成数据处理请求；

7.根据策略信息中注册的服务信息,决定发往哪个服务；

8.处理完成后,更新本地bilog同步记录marker。

2.3.6同步RGW流程-定时同步

步骤S3：

同步RGW除了在接收到同步通知时会进行数据同步,还会定时从数据站点获取最新的bilog进行同步。

同步RGW-定时同步的前提为：

1.同步站点配置完成；

2.每个站点都配置了同步RGW。

如图7所示，同步RGW-定时同步的步骤如下：

1. 从本地bilog同步记录中获取当前同步进度marker；

2. 根据同步进度marker,向数据站点业务RGW发起获取bilog请求；

3. 业务RGW接收到bilog读取请求,从marker位置开始,将新的bilog传输给同步RGW；

4. 同步RGW根据获取到的bilog,解析其中的策略id；

5. 根据策略id读取策略信息；

6. 根据对象id,从业务RGW读取对象信息；

7. 根据对象信息/策略信息生成数据处理请求；

8. 根据策略信息中注册的服务信息,决定发往哪个服务；

9. 处理完成后,更新本地bilog同步记录marker。

2.3.7同步RGW流程-全量同步

步骤S4：

同步RGW在第一次启动时,会进行一次全量同步,从数据站点同步所有数据。

同步RGW-全量同步的前提为：

1.同步站点配置完成；

2.每个站点都配置了同步RGW。

如图8所示，同步RGW-全量同步的步骤如下：

1. 向数据站点的业务RGW发起获取全量数据请求；

2. 业务RGW接收到请求,分批发送对象元数据到处理站点的同步RGW；

3. 同步RGW接收到对象元数据,解析其中的策略id,过滤掉不存在策略id的对象；

4. 存在策略id的对象元数据,认为是需要进行数据处理的对象,根据策略id, 获取策略信息,生成数据处理请求,发往数据处理服务；

5. 数据处理请求发送成功后,记录同步进度marker；

6. 重复上述步骤3-5,直到全部元数据完成,结束全量同步过程。

2.3.8处理服务流程

处理服务的前提为：

1.同步站点配置完成；

2.每个站点都配置了同步RGW。

处理服务的步骤如下：

1.处理服务收到请求,解析对象信息和策略信息；

2.从业务RGW拉取对象到本地；

3.根据策略中处理参数配置,进行处理；

4.将处理结果输出。

本发明还提供一种基于对象存储站点同步机制的数据自动处理装置，包括处理器和存储器，存储器中存储有计算机程序，计算机程序可被处理器读取并执行以实现如上方法。

本发明实施例的创新思想体现在：

a、利用ceph multisite同步功能，实现数据的异步处理。

b、通过自定义请求头，在写入对象时携带预定义的处理策略id。

c、业务RGW读取到请求头，将策略信息记录在对象metadata和bilog中。

d、同步RGW进行全量同步时，通过metadata读取策略信息；增量同步时，通过bilog读取策略信息。

e、同步RGW读取到策略信息后，根据对象信息和策略信息，生成处理请求，发往不同的处理服务。

f、处理服务接收到请求后，根据业务能力，进行同步或异步处理。

此外，通过策略配置处理流程和处理参数, 支持串联多种不同处理服务, 实现更复杂处理能力。

以上内容是结合具体的优选实施方式对本发明所作的进一步详细说明，不能认定本发明的具体实施只局限于这些说明。对于本发明所属技术领域的技术人员来说，在不脱离本发明构思的前提下，还可以做出若干等同替代或明显变型，而且性能或用途相同，都应当视为属于本发明的保护范围。

Claims (12)

1.一种基于对象存储站点同步机制的数据自动处理方法，其特征在于，包括如下步骤：

S1、将处理参数和过程配置预配置为策略；

S2、在上传对象时，自定义请求头携带策略id，业务RGW将策略记录在bilog和metadata中，bilog是对象操作日志;

S3、利用站点同步机制，在全量同步的时候通过metadata获取策略id，在增量同步的时候通过bilog获取策略id，并连同对象信息，生成处理请求，发往消息队列；

S4、处理服务从存储拉取对象，根据策略进行处理。

2.如权利要求1所述的基于对象存储站点同步机制的数据自动处理方法，其特征在于，步骤S3中包含解析请求头步骤，其进一步包括：

在通过restful api上传对象到存储时，携带自定义请求头，值为策略id；

业务RGW发现请求头，将策略id记录到metadata和bilog中。

3.如权利要求1所述的基于对象存储站点同步机制的数据自动处理方法，其特征在于，步骤S3中包含利用站点同步机制过滤出待处理对象的步骤，其包括：

全量同步：从主站点获取对象的metadata，根据metadata中的策略信息过滤是否需要进行处理；

增量同步：从主站点获取bilog，根据bilog中的策略信息过滤是否需要进行处理。

4.如权利要求1所述的基于对象存储站点同步机制的数据自动处理方法，其特征在于，还包括同步站点配置步骤，其包括：

创建数据站点，作为数据源，供处理站点进行数据同步；

创建处理站点，同时将数据站点作为数据源注册到处理站点；

创建业务RGW，通过业务RGW管理数据站点数据；

配置数据站点同步RGW，负责将变化的数据同步到处理站点；

配置处理站点同步RGW，负责接收数据站点同步RGW发送的同步通知，并根据处理策略配置生成处理请求，转发到数据处理服务。

5.如权利要求4所述的基于对象存储站点同步机制的数据自动处理方法，其特征在于，同步站点配置完成后，还包含创建策略步骤，其包括：

通过策略管理api，配置图片处理参数，包括缩放比例，生成缩略图存放位置。

6.如权利要求4所述的基于对象存储站点同步机制的数据自动处理方法，其特征在于，同步站点配置完成后，还包含上传对象步骤：通过s3 put object api上传对象，设置请求头。

7.如权利要求6所述的基于对象存储站点同步机制的数据自动处理方法，其特征在于，上传对象包括如下步骤：

客户端在上传对象的请求中，携带请求头，该请求头为处理策略id；

业务RGW接收到上传请求后，解析请求，存储对象数据；

业务RGW解析`x-mos-handle-policy`请求头，将请求头配置的策略id记录在对象元数据中；

记录一条数据写入的bilog；

向同站点同步RGW发送数据写入通知消息；

响应客户端请求结束；

客户端结束数据上传，对象上传成功。

8.如权利要求7所述的基于对象存储站点同步机制的数据自动处理方法，其特征在于，上传对象步骤之后还包括同步RGW流程，其包括如下步骤：

同步RGW接收到业务RGW的数据同步通知消息；

解析通知消息，发起拉取元数据的请求；

业务RGW接收到元数据读取请求，读取对象元数据传输给同步RGW；

根据获取到的对象元数据，解析其中的策略id；

根据策略读取策略信息；

根据对象信息/策略信息生成数据处理请求；

根据策略信息中注册的服务信息，决定发往哪个服务；

处理完成后，更新本地bilog同步记录marker。

9.如权利要求8所述的基于对象存储站点同步机制的数据自动处理方法，其特征在于，同步RGW除了在接收到同步通知时会进行数据同步，还会定时从数据站点获取最新的bilog进行同步。

10.如权利要求8所述的基于对象存储站点同步机制的数据自动处理方法，其特征在于，同步RGW在第一次启动时，会进行一次全量同步，从数据站点同步所有数据。

11.如权利要求1所述的基于对象存储站点同步机制的数据自动处理方法，其特征在于，还包括处理服务流程，其包括：

处理服务受到请求，解析对象信息和策略信息；

从业务RGW拉取对象到本地；

根据策略中处理参数配置，进行处理；

将处理结果输出。

12.一种基于对象存储站点同步机制的数据自动处理装置，包括处理器和存储器，其特征在于，所述存储器中存储有计算机程序，所述计算机程序可被处理器读取并执行以实现如权利要求1-11任一所述的方法。

Images