离进行的，防止出现并行分区调整，最终导致服务可用性受影响的问题。EndpointSystem作为接口，隔离了元数据存储本身和对元数据的访问操作，方便了针对各种不同的应用场景进行相应的后台存储引擎(即传统数据库)的选型和调整。在一个系统中，如果有必要，甚至可以并行采用不同的传统数据库引擎，分别满足不同用户的需求。
[0083]数据库管理模块(DatabaseManagementSystem),用于对元数据库的存储引擎进行配置和管理；具体的，DatabaseManagementSystem负责后台数据库存储引擎的配置和管理。对于EndpointSystem后面的传统数据库的管理，包括主从配置、索引建立等具体的数据库相关操作，是由DatabaseManagementSystem完成的,这样极大的简化了数据的可用性和可靠性支持。对元数据进行异地部署、同步和容灾处理，也通过该系统对后台数据库的配置管理进行支持。
[0084]审计模块(AuditingSystem)，用于对元数据请求和各种异常情况进行监控和数据收集，作为计费和系统运营、维护、优化、升级的依据。
[0085]维护模块(MaintainanceSystem),用于对云存储元数据处理系统的其它各个模块进行部署、运维、调整工作。具体的，云存储元数据系统要求内部各个子系统都可以平滑的部署，动态升级，不影响其他组件以及对外服务，当中的协调工作，由MaintainanceSystem全权负责。
[0086]优选的，所述认证模块根据各个模块间的调用接口性质的不同，采用不同强度的认证方式，包括:
[0087]对于外部接口调用，采用严格的AccessyKey+HMAC+SHAl的Hash认证方式；
[0088]对于内部的接口调用，采用简单的Basic Auth认证方式。
[0089]优选的，所述分区驱动模块生成的分区调整指令包括:
[0090]如果某个元数据单元包括的元数据量过多，对该元数据单元进行细化分裂的操作；
[0091]如果某些连续元数据单元的元数据数据量过少,对这些连续元数据单元进行合并操作。具体的，在用户对元数据进行修改和写入操作的时候，采用日志结构合并树的方案，对元数据进行定期的小范围调整，在用户数据量不断增大的时候，及时采取数据区域分裂的方式，确保某个数据单元的数据量控制在一定的范围内，并及时更新全局配置，确保数据的访问性能。相对于放弃元数据的数据存储方案，本发明可以有效地提供按区域查询和条件过滤的功能，同时在分区调整的时候，影响范围小，易于管理；相对于保持分布式B+/Trie树的方案，本发明的每次查询附加次数是固定的I次，与树结构本身的层数没有关系，实现起来也简单的多。
[0092]优选的，所述元数据库中的每个元数据中除保存实际数据对象的具体存储位置夕卜，也保存相应的条件检查字段和校验和。具体的，在元数据中除保存实际数据对象的具体存储位置外，也保存相应的条件检查字段，供后续条件匹配过滤查询使用。为确保数据的可靠性，即保证其不在传输和存储过程中损坏，每条数据都配备有校验和。
[0093]优选的，所述元数据库为传统的数据库，所述传统的数据库本身具有高可用方案和复制方案。例如，所述传统的数据库为关系型数据库或NoSQL数据库。具体的，所有的元数据都是保存在传统的数据库中的，至于该数据库是普通的关系型数据库(如MySQL)或者是较新型的NoSQL数据库(如MongoDB)，并不作特别的限定，但要求数据库可以对多个数据项做索引，以此支持条件查询。利用传统数据库本身的高可用方案和复制方案，进行跨地域数据同步，支持元数据系统所需要提供的按区域查询、跨地域快速访问，异地灾备等功能，并实现元数据的可靠性和可用性。这种实现方式的最大优势是，省去了自行开发存储引擎带来的各种复杂度，充分利用了各种现有实现，选型的自由度也很大。如图1所示，在实现上，可由独立的应用提供操作接口，屏蔽存储引擎的选型和实现细节。
[0094]优选的，所述元数据库中的每个元数据单元的划分同时满足如下条件:
[0095]第一，每一条元数据都单独的属于唯一的一个数据单元，所有的数据单元合到一起，形成一个完整的元数据空间；
[0096]第二，每个元数据单元内包括一个完整元数据区间；
[0097]第三，同一个用户的元数据都相互邻接的保存在连续的元数据单元中。具体的，传统的数据库，受单机内存和性能的限制，无法支持海量数据(如TB及以上级别的元数据)的存储。本发明的方案参考了日志结构合并树的思想，按照特定的原则即所述元数据库中的每个元数据单元的划分需要同时满足的条件对元数据进行划分，以固定大小作为一个单元，每个单元分配到一组跨地域的传统数据库中，并把这种单元划分作为全局配置即分区配置进行保存。如图2所示，在响应用户的操作时，元数据系统首先根据分区配置定位所操作的实际数据的元数据所在的数据库，再具体定位于数据库中的元数据单元中，获取具体元数据的信息，找到实际数据的存储地址。上述元数据库中的每个元数据单元的划分同时满足的条件中的第二和第三个条件是为了支持云存储服务提供按区域查询(Range Get)和条件过滤(Filter)这两个功能。
[0098]优选的，元数据库分为本地元数据库和异地元数据库，所述本地元数据库的数量为多个。相应的，对于元数据的存储，若有N个本地元数据库，必须有W个写入操作和R个读取操作成功，所述接入模块才判断数据访问操作为成功。具体的，传统的数据库高可用方案，是通过配置replicat1n的方式实现的,在本发明中，数据库级别的replicat1n也会使用，主要用于提供跨地域访问和异地容灾支持。另一方面，在应用层，本发明提出了自己的高可用和一致性方案。本发明对于数据的存储，要求按照一定的策略(R+W>N)进行判断，即假设有N份数据副本，要求写入必须满足W份副本以上成功，读取必须R份副本以上成功，整个的数据访问操作才视做成功，其中R、W、N的设置由用户自定义决定，但三个数字必须满足上述不等式。如果实际操作不满足上述不等式，系统会返回用户“具体结果不明”，本发明要求用户应用自行设置在写入异常时候的相应策略，因为毕竟只有用户才了解最适合应用本身的应对方式。
[0099]优选的，所述元数据库包括静态和动态数据库，其中，静态数据库保存相对长期的数据，而动态数据库保存短期的数据操作日志。相应的，所述终端模块还用于定期将所述动态数据库中的短期的数据操作日志整理成静态的数据记录并保存至所述静态数据库中。具体的，本发明采用动静分离的方式进行数据读写，即把数据分别保存在动、静态两组数据库中，静态数据库保存相对长期的数据，而动态数据库保存短期的数据操作日志，类似于append only的方案，写操作只涉及动态数据的修改，而读操作涉及动、静态两组数据库，这样可以很好的分散数据库的访问压力。在大多数情况下，数据的修改操作是短时间的，另一方面，为了防止append的日志过多导致数据库访问压力过大，性能过慢，在过了一个稳定的时间短之后，本发明会要求把动态的数据操作日志整理成静态的数据记录。在进行动静数据合并的过程中，必须进行精细化的配置变更，确保在数据合并的过程中，用户仍然可以进行正常的读写操作，而且在这期间进行的修改，在数据合并后仍然有效，同时分区的调整的粒度和持续时间必须细化和可控。
[0100]优选的，所述数据库管理模块对元数据库的存储引擎进行配置和管理包括对元数据库进行主从配置、索引建立、异地部署、同步和容灾处理。
[0101]如图4所示，本发明一实施例的数据访问流程由元数据服务的用户驱动，具体如下:
[0102]A.云存储服务访问AccessSystem,声明需要进行的操作,所属用户，针对的对象，需要进行的具体操作(增删改查)，认证信息。
[0103]B.AccessSystem访问AuthorizeSystem,对请求认证信息和操作权限进行检查。
[0104]C.AuthorizeSystem对认证信息进行确认，把结果(通过认证或是失败)返回给AccessSystem。
[0105]D.如果AuthorizeSystem返回认证失败，AccessSystem直接返回用户拒绝操作。
[0106]E.如果认证通过,AccessSystem向Partit1nConfigSystem询问用户操作所针对的命名空间和分区情况。
[0107]F.Partit1nConfigSystem查询当前的配置，返回AccessSystem该操作所具体针对的EndpointSystem列表,尽