[发明专利]元数据交互方法及系统

说明书

本发明的目的是提供一种元数据交互方法及系统，通过前端机从所述后端机上拉取元数据，并将拉取到的元数据存储至前端机所在地域的本地存储系统，并向所述后端机回复当前已经拉取的元数据的位置，所述后端机根据所述位置删除其内部存储的所述已经拉取的元数据，后端机不需要存储所有的元数据，只需要存储还未拉取到本地存储系统，可以避免后端机的单机存储性能的下降和存储容量的限制，数据存储站点数量受一致性协议Quorum节点数的限制的问题，达到整个系统的数据一致性、正确性与健壮性，另外，前端机和本地存储系统可以实现按需要进行扩展。

技术领域

本发明涉及计算机领域，尤其涉及一种元数据交互方法及系统。

背景技术

在设计跨地域一致性元数据系统时，最核心的基础组件是后端一致性系统(Quorum)，如业界的zookeeper，chubby。但是在全球化的场景下，单纯的利用一致性系统存储元数据如log(日志)和snapshot(快照)，会造成单机存储性能的下降和存储容量的限制，数据存储站点数量受一致性协议Quorum节点数的限制，而且每个地域(region)读取数据性能低。其中，Log为事务性日志，也就是用户发送的请求数据，在后端一致性系统中统一称为Log；Snapshot为快照，也就是后端一致性系统中某一时刻内存中全量数据的快照。

在设计跨地域一致性元数据存储系统架构中，最核心的是需要分布式一致性系统来保证全球元数据的一致性。业界通用的做法是利用zookeeper或者chubby，或者基于paxos实现的一致性系统，如图1所示，它们的通用架构是：

每个地域(region)需要一个本地存储系统(storage system)，可以是mysql或者分布式数据库等。这种架构的组件比较少，交互协议设计比较简单。分布式一致性系统会每隔一段时间将snapshot打到存储系统中，每个地域的client/user就会从存储系统中获取解析数据。但是,这种架构中，Quorum中的每个机器包括主服务器(Leader)和从服务器(Follower),还是需要存储所有的snapshot，主服务器(Leader)和从服务器(Follower)的内存中还是存储着全量的log数据。

在此,可以明显看出上述这种一致性系统存在着明显的可扩展性，单机性能瓶颈，磁盘和内存数据容量受限的问题。而且本地存储系统(storage system)还是得需要从一致性系统中获取数据，这样还得需要Quorum系统中的Leader接入mysql/storage system，主动将snapshot数据发送到mysql/storage system，其性能不佳。因此，这样的架构协议虽然简单，一致性系统不需要任何修改，只要每隔一段时间将snapshot数据推送到mysql/storage system中就可以了，但是，这种架构只是解决了每个地域的用户client/user的读取请求而已，并没有解决全球化跨地域的一致性元数据访问的难点。

如上所述，直接使用分布式一致性系统作为跨地域核心后端系统，协议设计简单，系统也不容易出错，但是面临着众多性能和机器存储容量的问题，也不具备可扩展性，这样的分布式系统没法在云计算这么复杂的场景下使用。

发明内容

本发明的一个目的是提供一种元数据交互方法及系统，能够解决单纯的利用一致性系统存储元数据，会造成单机存储性能的下降和存储容量的限制，数据存储站点数量受一致性协议Quorum节点数的限制的问题。

根据本发明的一个方面，提供了一种前端机上的元数据交互方法，该方法包括：

接收用户的更新元数据请求，通过向后端机发送所述用户的更新元数据请求，将对应的元数据更新入后端机；

从所述后端机上拉取元数据，并将拉取到的元数据存储至前端机所在地域的本地存储系统，并向所述后端机回复当前已经拉取的元数据的位置，以供所述后端机根据所述位置删除其内部存储的所述已经拉取的元数据。