CN113449065A - 一种面向数据删重的去中心化存储方法及存储装置 - Google Patents

Abstract

本发明提供一种面向数据删重的去中心化存储方法，以在客户端实现在线去重，包括：步骤1，将对象的命名与对象的存储位置进行解耦合；步骤2，将对象的内容利用数据指纹的方式，与存储位置建立映射关系，从而使得相同内容的对象会被放置到相同的位置，只需维护对象名字与数据位置之间的映射关系，从而相同的数据只需要保存一份，同时数据指纹本身也降低了副本一致性检查的开销，系统可以使得数据和元数据达到最终一致性。还提供了相应的面向数据删重的去中心化存储装置，包括：代理服务子系统及其接口；接口服务子系统及其接口；数据服务子系统及其接口；以及Windy客户端和系统网络互联子系统。

Description

一种面向数据删重的去中心化存储方法及存储装置

技术领域

本发明涉及分布式存储、区块链、存储数据重删技术领域，特别是涉及一种面向数据删重的去中心化存储方法及存储装置。

背景技术

随着社会信息化水平的不断提高和互联网技术的高速发展，各类非结构化数据，如图片、音视频、文本资料等呈现出爆炸性增长的趋势，在云存储服务为人们带来便利的同时，数据规模也在急剧膨胀，这对存储海量数据的能力提出了更高的要求。研究表明，数据中高达75％的部分是重复的，存储资源利用率不高的一个重要原因就是数据中存在大量的重复和冗余。

当前主流对象存储系统存在的不足：

Swift对象存储中接口服务对底层数据访问依然是直接访问文件系统的方式，对存储设备的抽象依然过于简单，同时对底层数据访问优化不足。Swift存储系统在设计时将接口信息与数据存储绑定在一起，二者是高耦合的，这种设计虽然在一定程度上简化了系统的结构和提高了性能，但是，对象命名、位置信息与数据存储没有分离，会对功能的扩展带来一系列问题：例如在Swift中对象的拷贝、重命名、共享操作就需要将原先对象的数据重新拷贝或迁移，会造成存储和网络资源的浪费，对于大对象，浪费问题尤其严重。

Swift在起初设计时，系统中的每个基本单位是对象，每个对象在一致性哈希空间中占据一个位置，对大小对象一视同仁，会造成磁盘利用的负载不均衡，在Grizzly版中虽然加入了大对象分段存储的机制，但其分段存储的流程过于复杂，接口上也并不整洁，故并未将此问题完全解决。该问题与前述对底层存储访问抽象的不足也是有很大联系的。

最重要的是，数据迅速膨胀的问题在Openstack生态系统中依然存在，并且Swift存储系统也并未完全解决，主要原因在于Swift对象存储系统中，对数据中存在大量的重复和冗余并未加以处理，造成存储和网络资源的浪费。上述两点Swift设计上的不足为引入数据去重优化对象存储带来了困难。在Openstack云计算环境下引入数据去重的方案是必要的。

因此，需要在云存储系统的需求场景中设计一种新的面向数据删重的去中心化存储方法及存储装置，以克服现有技术中的一些限制和缺陷。

发明内容

本发明的目的在于提供一种面向数据删重的去中心化存储方法及存储装置，针对Swift中数据存储大量重复的问题，在存储系统设计层面和对象寻址算法层面进行改进，有效提高了对象存储系统的存储设备和网络带宽的利用率，其发明构思在于结合基于内容寻址的优良特性，以及结合对象存储系统结构设计，采用对数据指纹进行一致性哈希放置的方法，有效解决重复的数据被多次存储导致存储空间浪费的问题，提高对象存储系统的存储设备和网络带宽使用效率。同时依据基于内容寻址的前提，设计实现相应的元数据管理策略和垃圾回收算法，以满足系统的正确性和高效性。

本发明第一方面，提供一种面向数据删重的去中心化存储方法，以在客户端实现在线去重，包括：

步骤1，将对象的命名与对象的存储位置进行解耦合；

步骤2，将对象的内容利用数据指纹的方式，与存储位置建立映射关系，从而使得相同内容的对象会被放置到相同的位置，只需维护对象名字与数据位置之间的映射关系，从而相同的数据只需要保存一份，同时数据指纹本身也降低了副本一致性检查的开销，系统可以使得数据和元数据达到最终一致性。

优选的，所述一种面向数据删重的去中心化存储方法包括：

元数据的管理和组织方法、基于内容寻址的数据放置算法和副本一致性算法以及反向引用和垃圾回收算法，其中：

所述元数据的管理和组织方法包括对元数据的维护，在实现时将数据序列化并存储到一个单独的文件中，文件名用写入时刻的时间戳表示，具体过程包括：

(1)每次POST请求记录时间戳信息，将元数据序列化后写入文件，存储到缓冲区；

(2)将缓冲区的文件加入队列，等待写入最终的存储位置；

(3)读取时对时间戳进行排序；

(4)读取时间戳最新的元数据；

(5)一个优化是在每次进行访问时，可以清除掉系统中陈旧的元数据文件；

所述副本一致性算法包括数据的副本一致性维护，其步骤包括：

(1)节点在本地完成数据校验，如果校验出错，将损坏的数据移入隔离区；

(2)Replicator进程遍历本地文件系统，每次检查远程节点中是否存在最新的副本，如果不存在，则直接主动推送一份本地数据，如果存在，则终止；

(3)Replicator进程持续工作，对于数据依然是循环检查，防止磁盘故障和节点故障；

所述反向引用和垃圾回收算法包括：

三个操作原语Create、Merge、Delete：Create原语用来生成一条反向引用信息backref，并放入对象的存储目录中；Merge原语负责将单条反向引用信息backref并入反向引用映射表backmap，backmap的时间版本信息为backref的最大时间戳；Delete原语负责将已并入反向引用映射表的单条反向引用信息backref删除；对于对象存储服务，接口中仅PUT和DELETE操作会发生对反向引用的操作，此时会调用Create原语；Replicator在进行元数据推送时会进行合并和删除已处理的backref；GC负责检查backmap中是否为空，如果为空则将该对象回收；对象回收采用的悲观的处理方式，Replicator在执行Merge操作时会对backmap加锁，此时GC直接放弃对backmap的访问，或者GC发现仍有未被并入的backref存在，都会在下一个清理时间片再处理该对象；由于垃圾回收的频率较低，Replicator仅进行单线程操作，加锁时仅针对backmap信息，对数据的访问没有影响，系统对于锁的开销较低，Replicator可根据系统的负载来设置反向引用合并的周期，以防止大量写操作生成大量小文件对文件系统造成压力。

优选的，对于元数据的一致性维护采用Quorum仲裁协议、反熵协议和时间戳检查，利用这三种机制使得元数据可达到最终一致性：首先，对于一个对象的元数据在这个系统最终要达到的一致状态，由带有最新时间戳的元数据文件决定；其二，对于元数据的写入，根据Quorum协议，需要超过半数的副本完成写入成功后才可返回，故在一次写入操作中系统中会保有超过半数的最新版本的元数据；其三，对于一个对象的每一个副本，都会向其余的所有副本推送本地时间戳最新的元数据，实际上是按照反熵协议在几份副本当中以泛洪的方式传播最新的数据，直到所有的副本都达到一致状态，即都达到了写入最新的版本。

优选的，所述方法还包括客户端对象划分步骤，包括：

(1)对象的数据片段组织，包括：在应用层存储基本单元与底层数据存储的基本单元之间引入一个映射关系，所述映射关系用一个manifest来组织，实质上是一个应用层对象到N个底层数据片段的映射关系，采用JSON格式存储所述映射关系；数据的哈希函数可以根据应用场景进行选择，并且在存储系统的运行当中是不改变的，哈希函数为md5哈希算法或哈希碰撞概率更低的sha-256哈希算法；

(2)对象划分与客户端实现，包括：windy客户端与swiftclient接口基本保持一致，在实现时主要在上传操作中加入了数据分段和指纹计算的功能；对数据的划分由客户端完成，全对象分块与定长分块相结合的方法，首先设定系统中定长分块的长度L，以该值作为阈值，检查对象的大小，对于大小小于L的对象进行全对象去重，并存储小数据片段的存储池，对于大小大于L的对象则进行固定长度分块；进行固定长度分块时，将长度为L的分段存入定长数据片段池，如果最后一个数据片段的长度不足L，也将存入小数据片段存储池，结合Chimes对象存储系统中建立的存储池，对数据片段进行合理的分配，将对象流转化为数据片段流，再将数据片段流进行重组；全对象分块对象级的去重方法，粒度较粗，适合对小文件处理；为了更细粒度的重复数据检测，将对象分割成固定大小的数据片段，也即基于静态分块的数据去重方法；客户端在去重时选择了全对象分块和定长分块，客户端和多个存储池能够支持变长分块算法；

(3)对象传输方法，包括：WindChimes存储系统外部由代理服务提供Swift API，内部由接口服务保存Swift API的相关信息，由Chimes对象存储系统保存对象的数据；进行对象传输时，由客户端、代理服务、接口服务、存储服务的共同配合完成。

优选的，所述对象传输方法包括：

(1)通过PUT接口实现对象的上传操作，包括：对象流中的对象n准备进行数据上传，客户端将该对象分段，计算每个数据片段的指纹值；客户端按照指纹值列表生成manifest；客户端将该生成的manifest上传到WindChimes代理服务器，代理服务器将manifest写入接口服务器中，并将manifest中的每个指纹值在指纹库中进行检索；对于存在于指纹库中的数据片段，直接建立数据链接，实际是数据片段到应用层的反向引用；代理服务向客户端返回查询结果manifest*；客户端指明需要上传的数据片段；客户端上传存储系统中不存在的数据片段，并建立新的数据片段对象；更新新建数据片段的反向引用；解除不在manifest*中数据片段的引用；对象的上传需要客户端、代理服务器、接口服务器、存储服务器的共同配合完成。代理服务器在获得了对象manifest之后应当立即完成对数据片段的反向引用，否则在manifest上传和数据片段上传的间隙当中已存在的数据片段有可能被垃圾回收服务清除；

(2)通过GET接口来获取对象，包括：在WindChimes存储系统中，每个Swift对象对应了一个manifest，其中记录了该对象每个数据片段在Chimes对象存储系统中的信息。进行数据下载时，客户端首先取得Swift对象的manifest，然后客户端根据manifest中的指纹值列表取得每个数据片段，并重组成一个完整的Swift对象。由于Chimes对象系统中每个对象有多份副本，代理服务首先轮询该对象各副本所在的存储节点是否可用，然后选择一个最优的副本进行读取，这个最优的副本一般可选时间戳最新的一份副本，如果该对象在Tier0中存在，则优先选择读取Tier0中副本；在循环取得每个数据片段的步骤中，对每个数据片段的获取可以是可并行的，在实现时可以采用多线程并发访问的方式；

(3)通过DELETE接口删除系统中的对象，包括：WindChimes在删除Swift对象时主要有两个工作，其一是删除对象的manifest文件，其二是解除每个数据片段到该Swift对象的反向引用，在删除对象manifest时采用异步的方式，即并不是在系统中直接移除manifest文件，而是在manifest所在目录中建立一个带有时间戳的tombstone文件，表示该manifest已经被删除，在对manifest读取时会返回失败，被删除的manifest会由存储服务器完成清理。在建立tombstone文件的同时，系统会向存储服务器发送异步请求来解除数据片段到Swift对象的反向引用；接口服务向存储服务发送异步请求时，删除命令会被加入一个消息队列，并且该队列会在系统中保存状态，在系统宕机恢复后未完成的更新命令可由更新服务Updater继续完成。

本发明的第二方面，提供一种面向数据删重的去中心化存储装置，包括：

代理服务子系统及其接口；

接口服务子系统及其接口；

数据服务子系统及其接口；以及

Windy客户端和系统网络互联子系统；

三个服务子系统没有设置门面接口，而是由不同子系统的节点之间直接通信，其中代理节点把握全局信息，完成数据流的控制，在数据的流转过程中提供路由所需的网络拓扑信息；在对接口服务和数据存储服务的部署时引入了区域概念以对服务器的物理位置进行隔离，一个区域为一块硬盘、一台服务器、一个机架、一个交换机，甚至是一个数据中心，在计算一致性哈希映射时不同的数据副本会被确保放在了不同的区域中；对于代理服务集群，各个代理节点是全对称的部署方式，每台代理节点都有完全相同的配置，并且代理节点中只保存软状态，在一台代理节点不可用时可以迅速完成服务的失效备援，外部的数据请求通过一个负载均衡器进行转发到各个代理节点上，转发时可以借助负载均衡器提供的策略，包括基于轮转、基于权重或者随机转发，并且注意负载均衡器是系统中的单点，需要做高可用处理。代理节点在部署时结合数据存储服务和接口服务的区域，在不同的区域中分别部署代理节点。

优选的，所述代理服务子系统及其接口负责接收外界请求，并对上传下载数据流进行调度，包括：负载均衡器和代理节点，并且认证鉴权系统可以由代理节点本身提供，也可由第三方服务提供，所述负载均衡器负责接受外部请求，将请求转发到各代理节点，其中的分配策略由负载均衡器提供，包括随机分配、轮转分配；由于系统只提供了唯一的对外接口，所述负载均衡器是系统中唯一的单点，应当在负载均衡器上进行高可用保护；所述代理节点全对称部署，每个代理节点是完全相同的，可以完成规模上的水平扩展和故障时的备援，所述代理节点负责除数据服务，元数据服务以外的所有功能，包括各项中间件，包括认证鉴权、访问控制、流量控制、存储配额，所述代理节点中不保存状态，故障发生时仅会使得本节点上正在进行的通讯失败，并不会造成错误的传播；对象的时间戳是完成并发访问控制和达到最终一致性的重要因素，而该时间戳是由所述代理节点生成，对于各代理节点时钟的同步需要进行集中控制，采用集中式的NTP时钟同步协议完成，NTP服务采用Master-Slave模式，各个代理节点主动向NTP服务器对时，对于NTP服务器的可用性和时钟的顺序一致，可交由监控系统完成，同时，可在代理服务集群中运行分布式的时钟同步协议；所述代理服务的访问接口用于代理服务作为系统内部与外部的交界面，对外所提供的完整的RESTAPI，并不向内部提供接口；代理服务包括中间件，用于对REST API表达能力的扩展，代理服务提供的中间件包括：

认证鉴权：代理服务对客户端的鉴权机制可以以中间件的形式存在，使用Swift系统提供的TempAuth、Openstack鉴权组件Keystone或者对鉴权部分进行定制；

访问控制：对系统中对象的访问控制通过中间件完成的，通过配置访问规则完成对不同用户对于不同容器和对象的访问控制；

存储配额：对容器和账户上传对象的大小、数目等方面进行限制；

数据缓存：系统中缓存信息的存放可以直接放在HTTP服务器的内存中，或使用第三方的memcached，通过中间件的形式抽象出统一的访问接口。

优选的，所述接口服务子系统及其接口用于完成系统对外接口Swift API向底层基于内容寻址的对象存储系统API的转换，是底层对象存储的一个视图，对Swift API，接口分为三个层次，分别是：账户、容器和对象(Object)。三者是从属关系，容器包含在账户之内，对象包含在容器之内，所述接口服务子系统包括Swift对象到底层的基于内容寻址的对象的映射和数据片段重组，账户和容器的管理可保持与Swift一致，对于三项服务，在数据分布方面采用一致性哈希算法，并引入虚节点以均衡数据在物理节点上的负载，在一致性维护方面，放弃强一致性，采用最终一致性模型，来达到高可用性和无限水平扩展能力；采用Quorum协议，并使R+W≤N，W为被写副本数量，R为被读副本数量，N为系统可用副本数量，为了保证数据的可靠性，写操作需要满足至少一半以上成功，即W>N/2，而读操作只需读取系统的一个可用副本，即R＝1，系统默认配置是N＝3，W＝2，R＝1，此种情况下在同一时刻被写的两份副本和被读的一份副本可能不交叠，故可能会读取到旧数据，数据在系统中的稳定状态是通过最新的时间戳来确定的，每个节点通过选择最新时间戳的一份副本来完成确定一个副本的一致状态，如果数据出现了不一致，后台服务进程会在一定时间窗口内通过检测和复制协议来完成数据同步，从而保证达到最终一致性；所述接口服务子系统还用于支持数据去重分块算法和对Swift Object对象数据进行重新组织，对于每个Swift对象，进行数据去重处理后会被分成若干个数据片段，在上传时完成拆分，拆成的每个数据片段对应了数据存储服务中的一个数据片段对象，对Swift对象进行访问时，对各个数据片段对象进行重组，对于每个Swift对象系统需要维护一张表manifest，该表中记录了组成Swift对象的数据片段信息，其中包括了数据片段在基于内容寻址存储系统中的唯一地址，长度和写入时间；同时，对于进行选择性上传的数据还应当完成对manifest的版本管理；接口服务的对外接口负责管理三类接口的数据，分别是Swift Account接口、Swift Container接口和Swift Object接口，三种接口都以REST API的形式存在，与Swift系统中内部API基本一致。

优选的，所述数据服务子系统及其接口包括：数据服务系统是一个完整的对象存储系统，对象通过一个扁平的命名空间寻址，遵循对象存储设备的设计原则，具有智能的自我管理能力，并能感知上层的存储应用；存储服务系统是一个大的容器，其中的基本元素是数据片段对象，同时，可以将具有类似特征的对象聚集在一起，放入一个存储池当中，存储池的设置为在每个存储池的底层部署不同特性的存储软硬件，利用异构存储资源提高数据的访问性能，数据服务子系统中设置一个或多个pool，每个pool采用一个独立的一致性哈希空间，每个pool之间保持逻辑上的独立，在物理部署上，单块磁盘只能属于一个pool，一个对象的完整命名应当是“/pool_id/hash”；pool_id的确定根据数据片段对象的固有特征，该特征必须是该数据片段在一个完整的生命周期中不变的信息，否则会影响到对象到存储节点的映射；利用数据片段大小来确定pool_id，根据pool_id来确定该对象数据所在一致性哈希环，然后通过数据片段对象的指纹确定该对象最终存储位置；同时，在每一个pool当中，按照replica_id来对对象的副本进行分层存储，根据对象在系统运行时的访问信息对对象的副本在各个存储层次上进行调度；数据服务是一个对象存储系统，基于数据片段的内容进行寻址，该子系统的数据访问接口采用RESTful的访问模式，数据服务的接口具有可编程能力，接口中主要包含5个操作，URL用来定位数据片段对象在存储节点上的位置，关于pool_id在代理节点上生成并通过pool_id获得节点的IP地址，故pool_id并不在存储服务的接口中出现；device表示对象位于存储节点上的磁盘位置，partition表示对象位于的虚节点，fingerprint是数据的指纹，由于其唯一性，直接用来完成一致性哈希中的寻址以及在节点上的数据定位；POST操作和HEAD操作负责更新和获取对象的元数据，应用层通过POST操作来自定义元数据项，以满足应用层的需求；PUSH操作用来像高性能的存储层推送对象；GET操作可通过fingerprint来直接获取数据片段内容；对于PUT操作，如果系统中不存在URL中所指的对象，则存储节点将新建一个对象，并通过PUT操作上传数据，如果系统中已经存在了该对象，则放弃数据上传，直接向应用层返回上传成功；DELETE操作在逻辑上是应用层删除对象后删除对应的数据片段，由于数据片段是共享的，不可直接删除，DELETE操作实际上是数据存储服务中一个解除引用的操作；在PUT和DELETE操作结束后，对象的反向引用，对象的被引用信息会被修改，完成对反向引用的维护；PUT操作是异步完成的，故应用层并无法确切知道对象上传完成后可用的时机；应用层可以选择不处理该情况，直接向客户端返回manifest，并不保证该manifest中所有数据片段是可用的，客户端并不知晓何时可获取完整的Swift对象；或者应用层维护manifest中所有数据片段是否全部准备好，待数据片段齐备后再向客户端返回manifest，则客户端一旦获取manifest就可直接顺利地进行数据下载，此时需要数据存储服务在对象可用后向应用层发送回调请求告知应用层该消息；PUT和DELETE操作的URL中包含反向引用的信息，并且在Header中要包含需要发送回调请求节点的位置信息。

优选的，所述Windy客户端和系统网络互联子系统用于完成数据分块、数据上传和数据访问，所述Windy客户端对Swift API进行编程，为用户提供更加友好的数据访问方式，以及根据去重算法对上传数据进行分段，并计算指纹信息；同时，客户端应当对代理服务中的鉴权机制有完整的支持；WindChimes对象存储系统的各个子系统之间虽然在功能上各司其职，但是在网络互联上是全连接的，扁平化的，在物理部署时同样是位于同一局域网内，任意两个节点之间可以互相通信。

本发明的有益效果：

本发明设计并实现了一种基于内容寻址的分布式对象存储系统，结合基于内容寻址与去中心化的特性，以及结合对象存储系统结构设计，采用对数据指纹进行一致性哈希放置的方法，充分利用基于内容寻址的优良特性，研究了基于数据指纹进行对象放置的一致性哈希算法，以及基于反向引用的元数据组织和垃圾回收算法，有效解决了重复的数据被多次存储导致存储空间浪费的问题，提高了对象存储系统的存储设备和网络带宽使用效率，从而推动了海量数据存储系统结构的发展；将对象大小、指纹值、创建时间等信息进行保存，并维护对象的时间戳和版本，为对象的存储打下基础；给出了基于数据指纹进行对象放置的一致性哈希算法，达到重复数据删除的目的，以及副本之间的异步同步方法，使得系统达到最终一致性；解决了系统中对象删除时的引用管理问题，清理了系统中的孤儿对象，提高了存储的利用率。这种基于内容寻址的对象存储系统所具有的上述优点，与传统的以Swift为代表的对象存储系统相比，本发明在保证了对象存取性能的同时，在存储资源和网络带宽的利用率上得到了较大的提高，以及系统提出的基于内容寻址的对象存储方法也普适于其他分布式存储系统。故本发明在大规模分布式对象存储系统实践中具有很高的技术价值和实用价值。

根据下文结合附图对本发明具体实施例的详细描述，本领域技术人员将会更加明了本发明的上述以及其他目的、优点和特征。

附图说明

后文将参照附图以示例性而非限制性的方式详细描述本发明的一些具体实施例。附图中相同的附图标记标示了相同或类似的部件或部分。本领域技术人员应该理解，这些附图未必是按比例绘制的。本发明的目标及特征考虑到如下结合附图的描述将更加明显，附图中：

附图1为根据本发明实施例的系统反向引用管理算法流程图及代码；

附图2为根据本发明实施例的系统外部接口示意图；

附图3为根据本发明实施例的系统内部接口示意图；

附图4为根据本发明实施例的系统体系结构图；

附图5为根据本发明实施例的代理服务网络互联结构示意图；

附图6为根据本发明实施例的接口服务网络结构示意图；

附图7为根据本发明实施例的Chimes对象存储系统体系结构图；

附图8为根据本发明实施例的数据划分策略示意图；

附图9为根据本发明实施例的对象流到数据片段流的转换和重组原理示意图；

附图10为根据本发明实施例的数据分段上传示意图；

附图11为根据本发明实施例的对象上传时序图；

附图12为根据本发明实施例的对象下载时序图；

附图13为根据本发明实施例的对象删除时序图；

附图14为根据本发明实施例的系统实验环境网络拓扑图；

附图15为根据本发明实施例的实验数据集对象大小分布图；

附图16为根据本发明实施例的实验中存储空间占用对比图；

附图17为根据本发明实施例的实验中上传时间对比图。

具体实施方式

本实施例的需求和场景对该对象存储系统进行体系结构层面的优化时提出了几点非功能性要求和前提：

(1)可靠性：系统应当保证数据不丢失，需要提供多份副本和复制的机制。

(2)可扩展性：能够支持该系统大规模部署，并且可在系统不停服务的前提下，对数据处理能力和存储能力进行水平扩展。

(3)可用性：在系统中存在单点故障的情况下依然能够持续提供服务。

(4)最终一致性：以上应用场景中，对于系统的高性能比原子的并发读写的要求要高。如1)是周期性的读写交替操作；2)、3)、4)是一次写、多次读；5)是连续写、少量读；6)是一次读、连续写，并由客户端完成。可见，以上场景中对同一对象的写操作大都是串行的而非并发的，并且并发的读写操作较少。故系统应当达到最终一致性，对于并发写操作，按照最新一次写为准。

(5)接口兼容性：系统应当兼容现有的Swift API，以及Amazon S3 API。

(6)高性能：系统应尽量保持数据去重对用户的透明，减小去重造成的性能损失。

由CAP理论可知，系统无法同时满足强一致性(Consistency)、可用性(Availability)、分区容忍性(Partition tolerance)，而构建大规模分布式系统时，网络分区是给定的，往往需要对强一致性和可用性进行取舍。同时，以上应用场景中客户端对系统中的不一致窗口存在一定的包容能力。故而在类似的需求下，目前大规模分布式系统往往选择最终一致性来满足系统的高可用性和高并发度。此类系统包括Amazon S3，Dynamo，Cassandra，以及现有Openstack对象存储系统Swift。

该部分需求与Openstack现有的开源对象存储系统Swift一致，所以系统在进行体系结构层面的优化时延续Swift的部分设计思想，仍以最终一致性为目标，同时保证可靠性、可扩展性和高可用性。

在外部接口方面，由于Swift对象存储系统是Openstack的核心组件之一，已在生产环境中得到了广泛的部署，本系统的目的在于从设计层面优化Swift在大数据存储方面的不足，前提是在Openstack生态系统中保持与Swift API的兼容，可以与其他现有组件Glance、Cinder的兼容，并在数据去重方面对Swift API和swift-client进行扩展。同时，系统应当有能力扩展支持Amazon S3接口。

本实施例利用重复数据删除和软件定义存储等技术来优化系统的存储和网络资源利用率。研究的思路是，对Swift存储系统在系统结构层面进行重新设计，以对重复数据进行删除，并且基于去重方案，完成系统中网络开销和一致性维护开销的改进。因此，在去重方案选择方面本系统在进行设计层面的优化时要遵循如下的功能性需求：

(1)面向分布式系统全局的去重，需要完成跨节点的数据去重。

(2)去重算法是可选择的，对全对象的去重，固定分块，变长分块，增量编码等去重算法都要有相应的支持能力。由于针对不同的应用场景，去重算法的适应性也不同，系统应当提供可配置的去重算法。

(3)系统应当在客户端方面对数据去重进行支持，REST API需要保证与Swift API的向前兼容，并对数据去重进行扩展。数据去重造成性能上的损失往往是无法避免的，但是应当将该开销尽量减小。为了尽量减少数据通讯的网络资源开销，并减小服务器的缓存压力，在数据的分段和指纹计算应当在客户端完成。

(4)在线去重。离线去重往往只能采用服务器端去重的方式，灵活性不足，并且无法优化网络通信。并且，离线去重的方法往往是采用数据节点进行分布式处理，数据量和搜索空间都较大，网络中会产生大量的查询流量，而最终一致性的系统中本身存在大量的数据同步流量，会使网络负担加重；同时设计中往往数据节点并不提供较强的计算能力；利用数据传输中的校验码，同时完成传输可靠性保证和计算数据指纹的工作，可分摊一部分计算压力。

系统在优化设计时基于几点假设：

首先，系统中假定本文中的哈希算法和数据指纹算法发生哈希碰撞的概率非常小，在实际应用中几乎是不会发生的(如SHA-512)，关于哈希碰撞的分析将超出本文的讨论范围，本文中将把此类算法看做可配置的模块，具体算法在系统部署时可以进行选择。

其次，在使用客户端协同完成去重时，将应用范围锁定在可信的网络环境下，即不存在哈希碰撞攻击和数据指纹欺骗，如私有云环境。如上传操作是可信的，则该范围可以适当放宽。

再次，系统中假设在一定时钟精度的要求下，存在多机的时钟同步，为了简化工程实现，使用ntp协议同步，而不采用向量时钟。

在大规模对象存储系统的设计的过程中，如何解决系统设计时的各种矛盾因素是一个重要的问题，故本系统在进行优化设计的过程中面临了各种考虑和权衡：

1、去重算法的引入本身是空间和时间上的取舍，是用一定的数据隔离性、系统结构复杂性、计算时间来换取网络传输时间和存储空间。去重本身会使数据分块，其计算过程一定程度上消耗CPU资源，无论从客户端还是从服务器端都会引起性能的下降，并且，数据分块后会使网络连接次数和磁盘IO次数增加，被引用次数较多的数据块会吸引大量的数据访问，可能成为系统瓶颈；但是从另一个角度讲，数据去重首先会消除系统中的冗余数据，对数据有一个更精简的表示，对设备成本和功耗成本上讲都是很大的优化，数据分块后对大对象的访问有优化作用，来自不同节点的块可以并行访问。同时，利用基于内容寻址的存储系统，一方面对于热数据的定位更加精确，另一方面，会大大减小系统的一致性维护开销。对于数据去重带来的性能下降，可以通过多方面的优化手段弥补。

2、可用性与一致性的选择：客户端应用更加需要一个高可用性和大规模的存储系统，但根据CAP理论，分布式系统无法同时满足强一致性、可用性、分区容忍，故本系统将放弃强一致性，而选择最终一致性的，以最新的更新时间戳为准，本系统中最终一致性是通过Quorum协议、反熵协议和时间戳管理达到的；但是，最终一致性的系统中存在一个“不一致窗口”，并发的读写操作可能会出现读到旧数据或读失败。系统在设计和实现时应当尽量减小系统的“不一致窗口”，该“不一致窗口”受系统负载、网络延迟和同步周期的影响，一方面应当消除系统中不必要的系统和网络负载，另一方面要合理安排数据同步周期。此外，客户端需要对读到脏数据和旧数据是具有一定包容能力，客户端应用层应当在数据返回时做一定的处理和校验。

3、目前在访问大规模分布式存储时两种方案可选，其一是客户端直连数据服务器或元数据服务器通信，其二是设置代理节点与内部系统进行通信。本系统中采用第二种方式的原因在于：设置代理节点的主要目的在于将分布式系统中对副本的读写控制和故障检查与数据服务分离，同时，本系统需要在云环境下提供IaaS或者SaaS的服务，需要对认证鉴权、访问控制、存储配额、数据安全、协议转换等服务进行支持和集中控制。设置代理节点后，存储节点可尽最大努力减小计算负载，则存储节点可选用高密度、低成本的存储服务器，有利于功耗控制和成本控制。同时，在基于一致性哈希的大规模存储系统中，客户端需要得到系统的部署配置，在公网环境下，一方面会有对节点进行拒绝服务攻击的隐患，另一方面，服务器端的节点故障无法对客户端进行有效屏蔽。但是，设置代理节点会造成系统中网络连接数的增加和网络负载的增大，所以系统在设计时应当充分考虑这两个情况，一个优化方案是将代理节点按照区域的划分，与存储网关服务放置在相同的节点上，可减小一定的网络开销。同时，在引入副本机制后，会使得客户端方案网络流量的优势变得并不明显。

4、元数据的更新方案大致可分成两种：一种是同步更新，即写操作必须在数据和元数据同时更新成功后才返回；另一种是异步更新，即写操作在数据更新成功之后立即返回，元数据的更新异步完成。对于本系统而言，数据与元数据分别放置在不同的服务当中，在分布式环境下，尤其是系统中存在网络拥塞、节点故障的情况下，提高系统的可用性是首要目标。同步更新的过程中存在写操作的等待，一方面长时间的等待操作会引起系统可用性下降，另一方面同步更新对应对系统中存在的网络和节点故障容忍性不足。故本系统对元数据的更新方式是，由代理节点直接向数据节点进行数据的写操作，在数据写入完毕后，由数据节点向元数据服务发送更新请求，如果此次请求失败，则将数据放入更新队列，由后台进程完成异步的更新。

5、存储节点需要对象本身特征以及对象在运行中的特征进行建池和存储分层：根据访问频率，将具有相似时间特性的数据进行归类，放到不同性能特征的存储层次(Tier)中，对于频繁访问的数据应放到高性能的存储层中，提高响应速度，而冷数据应放到性能较低的存储设备上以节约成本，同时磁盘平均转速较低也有利于节约能耗；面向对象大小建池：将小对象重新组织，放入面向小文件订制的存储池当中，消除inode对cache和内存的压力，大对象与小对象可利用不同的去重策略，提高的去重的效率，弥补了全对象去重的不足，同时，基于内容存储的存储系统中对象只写一次，大小是固定的，在面向对象大小建池时没有数据迁移的问题。但是，池化方案也会带来系统复杂度的提高：面向性能建池需要正确处理数据迁移中的一致性问题和数据调度策略；面向对象大小建池要对底层存储接口进行重新设计。

6、去重位置的选择：客户端去重是较好的方案，因为往往网络资源对于存储资源来说更加宝贵(磁盘容量提高的速度比网络带宽提高速度快，磁盘的成本也比网络带宽要低)。同时，基于内容寻址在寻址之前要生成数据片段的指纹值，由客户端在上传时生成指纹在实现时逻辑上更加合理，所以本系统支持客户端的去重。系统需要保证与Swift API等RESTful接口的兼容性，故对Swift API在数据去重方面做了扩展。

7、调度器和监视器选择对单机施加HA保护来完成，而未采用分布式架构。根据Openstack的设计思想，单点的设计是需要摒弃的，但本系统在设计时主要考虑到以下几点：首先，单机计算能力足以支撑监视器和调度器的计算任务，并不需要分布式处理；第二，监测数据的存储的可靠性可交由数据库本身完成，数据库本身也可是分布式的；第三，调度器的可用性是设计时最需要考虑的问题，但是Tier0本身只为了优化读操作，系统对调度器的宕机具有一定的容忍能力，通过HA保护可以大大简化调度器的设计，从而在调度器设计的复杂性和容错能力上做了折衷。

一、元数据管理和组织

对象的元数据信息主要有对象大小、指纹值、创建时间等，由于数据的写入是一次性的，数据片段在被垃圾收集器回收前是不变的，所以此部分元数据信息较稳定，可以与数据部分保存在一起，与数据一起完成同步。元数据组织时可以支持两种方式：元数据信息与数据信息按照json格式进行编码，保存到一个文件中，数据作为一个blob对象；元数据信息存储在文件的扩展属性(xattrs)中，但需要文件系统的支持，可选用XFS作为底层的文件系统，XFS将xattrs存储在inode中，只需在格式化文件系统时设置合适的inode大小。

对于元数据的维护，在实现时将数据序列化并存储到一个单独的文件中，文件名用写入时刻的时间戳表示。具体过程如下：

1.每次POST请求记录时间戳信息，将元数据序列化后写入文件，存储到缓冲区。

2.将缓冲区的文件加入队列，等待写入最终的存储位置。

3.读取时对时间戳进行排序。

4.读取时间戳最新的元数据。

5.一个优化是在每次进行访问时，可以清除掉系统中陈旧的元数据文件。

二、基于内容寻址的数据放置算法和副本一致性算法。

通过基于内容寻址，分布式存储系统可获得多个特别的性质。首先，数据中包含了指纹信息，每个存储位置只对应一次写入，所以对于对象的数据区来说，一致性开销非常小。存储节点只需要定期检查系统中对象数据是否有损坏，其同步操作的频率相比基于位置寻址的分布式存储系统要低得多。其次，系统为了进行垃圾回收，需要在对象中保存对象的被引用信息，而这些引用信息则是会被频繁更新的，这样引用信息就存在的写入性能和一致性维护的问题。所以对象的引用信息管理和一致性保证是系统中需要首要和重点解决的问题。

本实施例中，对象存储时寻址需要生成对象的指纹信息，此时已完成对数据片段的一次完整的扫描和指纹计算。在数据放置方面，采用扩展的一致性哈希算法，与目前主流对象存储系统(如Swift)思路类似。在对象副本的一致性维护方面，分为数据的一致性维护和元数据的一致性维护。一个对象存储时分为数据和元数据部分：数据部分由于只写一次，并且内容与位置一一对应，故副本一致性维护的开销较小；而元数据部分主要需要处理大量的引用操作，以及应用层自定义的元数据更新，变动较大，是副本一致性维护的主要对象。

对于数据和元数据的一致性维护步骤是类似的，只是对于数据而言，并不存在版本的管理问题。数据的副本一致性维护的基本步骤如下：

1.节点在本地完成数据校验，如果校验出错，将损坏的数据移入隔离区。

2.Replicator进程遍历本地文件系统，每次检查远程节点中是否存在最新的副本，如果不存在，则直接主动推送一份本地数据，如果存在，则终止。

3.Replicator进程持续工作，对于数据依然是循环检查，主要目的是防止磁盘故障和节点故障。

对于元数据的一致性维护采用Quorum仲裁协议、反熵协议和时间戳检查，利用这三种机制使得元数据可达到最终一致性：

首先，对于一个对象的元数据在这个系统最终要达到的一致状态，由带有最新时间戳的元数据文件决定。

其二，对于元数据的写入，根据Quorum协议，以3冗余度为例，需要超过半数即两份副本完成写入成功后才可返回，故在一次写入操作中系统中会保有两份最新版本的元数据，在数据的可靠性、可用性和一致性方面取得了较好的折衷。

其三，对于一个对象的每一个副本，都会向其余的所有副本推送本地时间戳最新的元数据，实际上是按照反熵协议在几份副本当中以泛洪的方式传播最新的数据，直到所有的副本都达到一致状态，即都达到了写入最新的版本。

三、反向引用和垃圾回收算法

目前对于对象的引用管理和回收有两种方式：一种是引用计数的方式；一种是反向引用的方式。对于分布式存储，其中存在大量的并发访问，利用计数的方式需要进行严格的加锁操作，并且在大量并发时会由于竞争锁使得系统的读写性能急剧下降。

本实施例采用反向引用的方法，通过该方法可获得两点好处：其一，反向引用可以进行异步操作，由于设置引用的目的与数据的读写本身无关，只与数据的垃圾回收有关，垃圾回收是异步操作，故而引用操作并没有必要是同步的操作；其二，由于应用层系统和底层的对象存储系统都是最终一致性的，引用和解引用对应于应用层的写操作和删除操作，为了保证系统达到最终一致性，系统中的更新操作都采用异步的方式，并且保存状态以应对拥塞和失败。

对于系统中的数据对象，数据只被写一次，故是稳定的，但是数据的引用和解引用是频繁的操作，并且要处理并发问题。对于反向引用主要包含三个操作原语Create、Merge、Delete：Create原语用来生成一条反向引用信息backref，并放入对象的存储目录中；Merge原语负责将单条反向引用信息backref并入反向引用映射表backmap，backmap的时间版本信息为backref的最大时间戳；Delete原语负责将已并入反向引用映射表的单条反向引用信息backref删除。

算法具体步骤如图1所示，可知对于对象存储服务，接口中仅PUT和DELETE操作会发生对反向引用的操作，此时会调用Create原语。Replicator在进行元数据推送时会进行合并和删除已处理的backref。GC则负责检查backmap中是否为空，如果为空则将该对象回收。但是对象回收采用的悲观的处理方式，Replicator在执行Merge操作时会对backmap加锁，此时GC直接放弃对backmap的访问，或者GC发现仍有未被并入的backref存在，都会在下一个清理时间片再处理该对象。由于垃圾回收的频率较低，Replicator仅进行单线程操作，加锁时仅针对backmap信息，对数据的访问没有影响，故系统对于锁的开销较低，Replicator可根据系统的负载来设置反向引用合并的周期，以防止大量写操作生成大量小文件对文件系统造成压力。

下面参照附图，对本发明的内容的实施方式进行详述，正如发明内容中所描述的，本发明中基于内容寻址的对象存储系统主要包括：(1)元数据管理和组织，(2)基于内容寻址的数据放置算法和副本一致性算法，(3)反向引用和垃圾回收算法。

本实施例系统基于对象的内容进行寻址，该子系统的数据访问接口依然遵循RESTful的访问模式。本系统接口应当具有可编程能力，以满足更复杂的应用层需求，如更好地支持大对象的分片存储。系统对外接口如图2所示，内部接口如图3所示。

系统体系结构图如图4所示，包括应用层、对象访问层、存储访问层、块存储接口层以及磁盘，其中对象访问层包括审计服务、同步服务、更新服务以及垃圾回收的功能模块，所述块存储接口包括XFS接口、EXT4接口等。

一、代理服务子系统及其接口描述

(一)代理服务系统结构

代理服务是WindChimes中最核心的子系统，负责接收外界请求，并对上传下载数据流进行调度。由负载均衡器和代理节点组成，并且认证鉴权系统可以由代理节点本身提供，也可由第三方服务提供，其互联结构如图5所示：

负载均衡器负责接受外部请求，将请求转发到各代理节点，其中的分配策略可以由负载均衡器提供，可包括随机分配、轮转分配等。由于系统只提供了唯一的对外接口(如域名等)，此处的负责均衡器是系统中唯一的单点，应当在负载均衡器上进行高可用(HighAvailability)保护。

代理节点全对称部署，每个代理节点是完全相同的，可以完成规模上的水平扩展和故障时的备援(failover)。代理节点负责了除数据服务，元数据服务以外的所有功能，包括各项中间件，如认证鉴权、访问控制、流量控制、存储配额等。代理节点中几乎不保存状态，故障发生时仅会使得本节点上正在进行的通讯失败，并不会造成错误的传播。

对象的时间戳是完成并发访问控制和达到最终一致性的重要因素，而该时间戳是由代理节点生成，对于各代理节点时钟的同步需要进行集中控制，本系统中在实现时采用集中式的NTP时钟同步协议完成，NTP服务采用Master-Slave模式，各个代理节点主动向NTP服务器对时，对于NTP服务器的可用性和时钟的顺序一致，可交由监控系统完成。同时，也可在代理服务集群中运行分布式的时钟同步协议。

(二)代理服务的访问接口

代理服务作为系统内部与外部的交界面，对外需要提供完整的REST API，本系统中需要实现Swift API完整的语义，同时，需要能够对其他接口如Amazon API、分布式文件系统接口的支持。同时，代理服务对下是以“拉取”的方式获得数据，故并不向内部提供接口。仅针对与本文密切相关的Swift API的对象部分进行列举，如表1所示：

表1 Swift API中对象部分

此外，代理服务中可以提供各类中间件以增强系统的灵活性，以及提高适应多种应用需求的能力，中间件的主要作用是对REST API表达能力的扩展，代理服务提供的中间件主要包括但不限于以下几个方面：

认证鉴权：代理服务对客户端的鉴权机制可以以中间件的形式存在，可以使用Swift系统提供的TempAuth、Openstack鉴权组件Keystone，也可以对鉴权部分进行定制。

访问控制：存储系统的权限和访问控制是一个重要的内容，但是对REST访问接口则是透明的，故对系统中对象的访问控制是通过中间件完成的。通过配置访问规则可以完成对不同用户对于不同容器和对象的访问控制。

存储配额：存储配额在实际的公有存储和私有存储部署中都具有重要的意义，主要是对容器和账户上传对象的大小、数目等方面进行限制，

数据缓存：系统中缓存信息(如访问令牌，账户信息等)的存放可以直接放在HTTP服务器的内存中，也可使用第三方的memcached，通过中间件的形式抽象出统一的访问接口，使得系统的灵活性更强。

二、接口服务子系统及其接口描述

(一)接口服务系统结构

接口服务的主要作用是完成系统对外接口(如Swift API)向底层基于内容寻址的对象存储系统API的转换，是底层对象存储的一个视图(View)。其内部结构如图6所示。

与底层基于内容寻址的对象存储系统扁平化的数据访问方式不同，对Swift API，其接口分为三个层次，分别是：账户(Account)、容器(Container)、对象(Object)。三者是从属关系，容器包含在账户之内，对象包含在容器之内。该服务最重要的部分是Swift对象到底层的基于内容寻址的对象的映射和数据片段重组，账户和容器的管理可保持与Swift一致。

对于三项服务，依然需要充分保持其可用性和可扩展性，在设计思路上与Swift基本一致。在数据分布方面仍采用一致性哈希算法，并引入虚节点以均衡数据在物理节点上的负载。在一致性维护方面，放弃强一致性，采用最终一致性模型，来达到高可用性和无限水平扩展能力。为了实现这一目标，采用Quorum协议，并使R+W≤N，为了保证数据的可靠性，写操作需要满足至少一半以上成功，即W>N/2，而读操作只需读取系统的一个可用副本，即R＝1。系统默认配置是N＝3，W＝2，R＝1，此种情况下在同一时刻被写的两份副本和被读的一份副本可能不交叠，故可能会读取到旧数据。数据在系统中的稳定状态是通过最新的时间戳来确定的，每个节点通过选择最新时间戳的一份副本来完成确定一个副本的一致状态。如果数据出现了不一致，后台服务进程会在一定时间窗口内通过检测和复制协议来完成数据同步，从而保证达到最终一致性。

接口服务中最重要的任务是支持数据去重分块算法和对Swift Object对象数据进行重新组织。对于每个Swift对象，进行数据去重处理后会被分成若干个数据片段，在上传时完成拆分，拆成的每个数据片段对应了数据存储服务中的一个数据片段对象。对Swift对象进行访问时，需要对各个数据片段对象进行重组。对于每个Swift对象系统需要维护一张表manifest，该表中记录了组成Swift对象的数据片段信息，其中包括了数据片段在基于内容寻址存储系统中的唯一地址，长度和写入时间。同时，对于进行选择性上传的数据还应当完成对manifest的版本管理。

(二)接口服务的对外接口

接口服务主要负责管理三类接口的数据，分别是Swift Account接口、SwiftContainer接口和Swift Object接口，三种接口都以REST API的形式存在，与Swift系统中内部API基本一致。下面以Object接口为例进行简述：

Object接口主要针对两方面：一方面是面向代理服务的接口，主要用来完成代理服务向接口服务中写入与Swift对象管理相关的元数据；一方面是面向数据存储服务的接口，负责接收存储更新向接口服务发送的回调请求，数据管理接口如下表2所示：

表2接口服务的Swift Object接口

接口中主要包含5个操作，如表1所示，GET和PUT操作负责下载和上传manifest，DELETE操作负责删除manifest，POST和HEAD操作负责更新和获取对象的元数据。几个操作的URL是相同的，device表示数据位于接口服务节点上的磁盘位置，partition表示数据位于的虚节点，/account/container/object表示对象属于的account和container，以及object的对象名，利用这三部分信息可以获得对象在一个节点上的存储位置。

三、数据服务子系统及其接口描述

(一)数据服务系统结构

数据服务系统的互联结构图如图7所示。

数据服务系统是一个完整的对象存储系统，对象通过一个扁平的命名空间寻址，遵循对象存储设备(OSD)的设计原则，具有智能的自我管理能力，并能感知上层的存储应用。存储服务系统是一个大的容器，其中的基本元素是数据片段对象，同时，可以将具有类似特征的对象聚集在一起，放入一个存储池当中。存储池的设置可以为上层应用提供更好的支撑，如在每个存储池的底层部署不同特性的存储软硬件，利用异构存储资源提高数据的访问性能。

系统中可以设置一个或多个pool，每个pool采用一个独立的一致性哈希空间，每个pool之间保持逻辑上的独立，在物理部署上，单块磁盘只能属于一个pool，一个对象的完整命名应当是“/pool_id/hash”。pool_id的确定根据数据片段对象的固有特征，该特征必须是该数据片段在一个完整的生命周期中不变的信息，否则会影响到对象到存储节点的映射。本系统在实现时利用数据片段大小来确定pool_id，根据pool_id来确定该对象数据所在一致性哈希环，然后通过数据片段对象的指纹确定该对象最终存储位置。

同时，在每一个pool当中，可以按照replica_id来对对象的副本进行分层存储，根据对象在系统运行时的访问信息对对象的副本在各个存储层次上进行调度，这种自动分层存储的设计也能够极大发挥异构存储资源的性能。

(二)数据服务的接口设计

数据服务是一个完成对象存储系统，基于数据片段的内容进行寻址，该子系统的数据访问接口依然遵循RESTful的访问模式。数据服务的接口应当具有可编程能力，以满足更复杂的应用层需求，如更好地支持大对象的分片存储。数据存储服务的对外接口如下表3所示：

表3数据存储服务接口

接口中主要包含5个操作，URL用来定位数据片段对象在存储节点上的位置，关于pool_id在代理节点上生成并通过pool_id获得节点的IP地址，故pool_id并不在存储服务的接口中出现。device表示对象位于存储节点上的磁盘位置，partition表示对象位于的虚节点，fingerprint是数据的指纹，由于其唯一性，可直接用来完成一致性哈希中的寻址以及在节点上的数据定位。POST操作和HEAD操作负责更新和获取对象的元数据，应用层可以通过POST操作来自定义元数据项，以满足应用层的需求。PUSH操作用来像高性能的存储层推送对象。GET操作可通过fingerprint来直接获取数据片段内容。对于PUT操作，如果系统中不存在URL中所指的对象，则存储节点将新建一个对象，并通过PUT操作上传数据，如果系统中已经存在了该对象，则放弃数据上传，直接向应用层返回上传成功。DELETE操作在逻辑上是应用层删除对象后删除对应的数据片段，但是由于数据片段是共享的，不可直接删除，故DELETE操作实际上是数据存储服务中一个解除引用的操作。在PUT和DELETE操作结束后，对象的反向引用(对象的被引用信息)会被修改，故要完成对反向引用的维护。另外，系统放弃了强一致性，PUT操作是异步完成的，故应用层并无法确切知道对象上传完成后可用的时机。一方面，应用层可以选择不处理该情况，直接向客户端返回manifest，并不保证该manifest中所有数据片段是可用的，客户端并不知晓何时可获取完整的Swift对象；一方面，应用层可以维护manifest中所有数据片段是否全部准备好，待数据片段齐备后再向客户端返回manifest，则客户端一旦获取manifest就可直接顺利地进行数据下载，此时需要数据存储服务在对象可用后向应用层发送回调请求告知应用层该消息。应用层可根据应用需求的不同选择这两种方案，但数据存储服务应当预留向应用层发送回调请求的接口，故PUT和DELETE操作的URL中包含反向引用的信息，并且在Header中要包含需要发送回调请求节点的位置信息。

四、客户端设计和系统网络互联

(一)客户端设计

由于客户端Windy是WindChimes对象存储系统的重要组件之一，主要的任务是完成数据分块、数据上传和数据访问。客户端的主要任务一方面是对Swift API进行编程，为用户提供更加友好的数据访问方式，另一方面是根据去重算法对上传数据进行分段，并计算指纹信息。同时，客户端应当对代理服务中的鉴权机制有完整的支持。

(二)系统网络互联

WindChimes对象存储系统的各个子系统之间虽然在功能上各司其职，但是在网络互联上是全连接的，扁平化的。在物理部署时同样是位于同一局域网内，任意两个节点之间可以互相通信。

三个服务子系统虽然之间的任务分工非常明确，但是为了保证系统中不存在单点，每个子系统并没有设置门面(facade)接口，而是由不同子系统的节点之间直接通信。代理节点把握全局信息，完成数据流的控制，在数据的流转过程中提供路由所需的网络拓扑信息。

集群中的节点可能都在一个机架上，一旦发生断电或网络故障，整个集群可能无法响应用户请求，因此在对接口服务和数据存储服务的部署时引入了区域(zone)概念以对服务器的物理位置进行隔离。一个zone可以是一块硬盘、一台服务器、一个机架、一个交换机，甚至是一个数据中心，在计算一致性哈希映射时不同的数据副本会被确保放在了不同的zone中。

对于代理服务集群，各个代理节点是全对称的部署方式，每台代理节点都有完全相同的配置，并且代理节点中只保存软状态，在一台代理节点不可用时可以迅速完成服务的失效备援(failover)。外部的数据请求通过一个负载均衡器进行转发，到各个代理节点上，转发时可以借助负载均衡器提供的策略，如基于轮转、基于权重或者随机转发等，并且注意负载均衡器是系统中的单点，需要做高可用处理。代理节点在部署时同样应当满足可靠性的要求，较为稳妥的方式是结合数据存储服务和接口服务的zone，在不同的zone中分别部署代理节点，可保证代理服务的可靠性。

本实施例仅给出系统网络互联的部分原则，以及中等规模下的部署实例。在大规模数据中心网络环境下其网络互联本身就是一个复杂的问题，本系统需要基于数据中心网络优化设计的相关理论进行部署，以期获得更好的网络性能和可靠性，但这部分内容已超出了本文的讨论范围。

本实施例主要对基于数据去重的对象传输和对象访问中的性能问题进行优化，目的为了完成系统对于网络传输负载的优化和系统对于磁盘访问负载的优化。首先，将从客户端的角度研究对象的划分和元数据组织方法，并描述客户端的实现。然后基于数据分段，从整个系统的数据流层面研究了对象的传输方法和时序关系，以及相应的实现。同时，本实施例研究在数据访问过程中产生的热点数据优化方法，拟采用自动存储分层技术。

五、客户端对象划分方法研究与实现

Windy客户端是WindChimes存储系统的重要组成部分，主要负责将完整的数据划分成数据片段、生成Swift对象的数据片段列表(manifest)，以及完成数据的上传下载。以下主要描述数据划分的相关方法。

(一)对象的数据片段组织方法

本系统在设计中的一个重要方法是在应用层存储基本单元与底层数据存储的基本单元之间引入一个映射关系。这个关系可用一个manifest来组织，实质上是一个应用层对象到N个底层数据片段的映射关系。本系统中将采用JSON格式存储这一关系，JSON格式是一种轻量级的数据交换格式，表达精简，目前已经广泛应用于各类互联网应用中。

以下将以一个示例来描述系统中manifest的组织，如：系统中存在一个对象，其manifest信息包括两个部分，分别是元数据meta和数据片段映射表data_map。元数据中表明了对象的基本信息，例如名称name，建立时间timestamp，大小size等。数据片段映射表表明了对象的组成信息：首先，指明了对象与数据划分相关的信息，如数据划分算法algorithm字段，哈希函数hash_function字段，映射表的时间戳timestamp字段，数据片段数量count字段；其次，是各个数据片段的信息，包括每个数据片段的指纹信息fingerprint，数据片段长度length等。

需要注意的是，数据的哈希函数可以根据应用场景进行选择，并且在存储系统的运行当中是不改变的，本例中采用的是md5哈希算法，也可采用哈希碰撞概率更低的sha-256哈希算法，但会引起计算和存储开销的增大，需要根据应用场景对哈希算法进行权衡。

(二)对象划分方法与客户端的实现

对应于Swift API，客户端对用户提供了以6类命令，主要完成了在账户、容器、对象三个层面数据的操作，如表4所示：

表4客户端用户接口

windy客户端与swiftclient接口基本保持一致，在实现时主要在上传操作中加入了数据分段和指纹计算的功能。

对数据的划分主要由客户端完成，全对象分块方法与定长分块方法实现简单、计算开销小，应用广泛，但在去重效果方面略。本文将采用全对象分块与定长分块相结合的方法，首先设定系统中定长分块的长度L，以该值作为阈值，检查对象的大小，对于大小小于L的对象进行全对象去重，并存储小数据片段的存储池，对于大小大于L的对象则进行固定长度分块。进行固定长度分块时，将长度为L的分段存入定长数据片段池，如果最后一个数据片段的长度不足L，也将存入小数据片段存储池。利用这种方法可以在一定程度上克服全对象分段粒度过大的情况，针对图片等低频率修改的小对象有较好的适应性，结合Chimes对象存储系统中建立的存储池，可以对数据片段进行合理的分配。数据的划分策略可用图8表示：

形式上，是完成了一个将对象流转化为数据片段流，再将数据片段流进行重组的过程，如图9所示。

全对象分块对象级的去重方法，粒度较粗，适合对小文件处理；为了更细粒度的重复数据检测，可以将对象分割成固定大小的数据片段，也即基于静态分块的数据去重方法。为了使得用户尽量感知不到去重的过程，客户端在去重时选择了计算开销较小的全对象分块和定长分块，同时，客户端和多个存储池的方案也有能力支持变长分块算法。

一、对象传输方法设计和实现

WindChimes存储系统外部由代理服务提供Swift API，内部由接口服务保存SwiftAPI的相关信息，由Chimes对象存储系统保存对象的数据。进行对象传输时，需要客户端、代理服务、接口服务、存储服务的共同配合完成，本节将针对Swift API中对象部分的关键传输命令PUT、GET、DELETE进行详细分析，阐述对象的上传、下载、删除的流程和时序。对于账户和容器相关的Swift API，由于其与Swift系统保持完全兼容，故在本文中不再赘述，对于Swift API对象部分的HEAD、POST接口，其作用是获得和更新Swift对象的元数据，由于其功能和实现都较为简单，在本节中也不赘述。

(一)PUT接口的设计和实现

PUT接口主要用来完成对象的上传操作。对于已经存在于Chimes对象存储系统中的对象，会按照其指纹值和由一致性哈希进行放置，每一个指纹值代表了一个唯一的位置。当有新的对象流到达后，客户端会首先将该对象流中的每一个对象进行分段，计算这些数据片段或按照全对象的指纹值生成一个manifest，将该manifest上传到代理服务器，代理服务器将manifest中的每个指纹值与已经存储在指纹值库值进行比较，如果发现指纹值已经存在，则不需要进行数据上传。如果发现指纹值还不存在，则可以判定该数据片段没有在存储系统中，除了将数据上传到服务器之外，还要更新指纹库。可知，全对象分块是定长分块方法的一个特例，以下结合图10以固定长度分块为例来对数据上传的过程进行详细描述：

1.对象流中的对象n准备进行数据上传，客户端将该对象分段，计算每个数据片段的指纹值。

2.客户端按照指纹值列表生成manifest。

3.客户端将该生成的manifest上传到WindChimes代理服务器，代理服务器将manifest写入接口服务器中，并将manifest中的每个指纹值在指纹库中进行检索。

4.对于存在于指纹库中的数据片段，直接建立数据链接，实际是数据片段到应用层的反向引用。

5.代理服务向客户端返回查询结果manifest*。

6.客户端指明需要上传的数据片段。

7.客户端上传存储系统中不存在的数据片段，并建立新的数据片段对象。

8.更新新建数据片段的反向引用。

9.解除不在manifest*中数据片段的引用。

至此，一个对象的数据片段分段上传完成。对象上传的时序图如图11所示。

通过时序图分析可以看出，对象的上传需要客户端、代理服务器、接口服务器、存储服务器的共同配合完成。代理服务器在获得了对象manifest之后应当立即完成对数据片段的反向引用，否则在manifest上传和数据片段上传的间隙当中已存在的数据片段有可能被垃圾回收服务清除。

值得注意的是，对manifest*中所指的数据片段进行上传时可以是并行的。

(二)GET接口的设计与实现

GET接口主要用来获取对象。在WindChimes存储系统中，每个Swift对象对应了一个manifest，其中记录了该对象每个数据片段在Chimes对象存储系统中的信息。进行数据下载时，客户端首先取得Swift对象的manifest，然后客户端根据manifest中的指纹值列表取得每个数据片段，并重组成一个完整的Swift对象。由于Chimes对象系统中每个对象有多份副本，代理服务首先轮询该对象各副本所在的存储节点是否可用，然后选择一个最优的副本进行读取，这个最优的副本一般可选时间戳最新的一份副本，如果该对象在Tier0中存在，则优先选择读取Tier0中副本。GET命令的时序图如图12所示。

值得注意的是，在循环取得每个数据片段的步骤中，对每个数据片段的获取可以是可并行的，在实现时可以采用多线程并发访问的方式。

(三)DELETE接口的设计和实现

DELETE接口主要用来删除系统中的对象。WindChimes在删除Swift对象时主要有两个工作，其一是删除对象的manifest文件，其二是解除每个数据片段到该Swift对象的反向引用。本系统在删除对象manifest时采用异步的方式，即并不是在系统中直接移除manifest文件，而是在manifest所在目录中建立一个带有时间戳的tombstone文件，表示该manifest已经被删除，在对manifest读取时会返回失败，被删除的manifest会由存储服务器完成清理。在建立tombstone文件的同时，系统会向存储服务器发送异步请求来解除数据片段到Swift对象的反向引用。DELETE命令的时序图如图13所示。

值得注意的是，接口服务向存储服务发送异步请求时，删除命令会被加入一个消息队列，并且该队列会在系统中保存状态，在系统宕机恢复后未完成的更新命令可由更新服务Updater继续完成。

本实施例如图14-17所示在真实的应用环境中对系统设计进行了验证。结果证明，由于对传统的对象存储系统体系结构进行改进，引入了基于对象数据哈希指纹的寻址方式，设计并实现了对象的反向引用和垃圾回收算法，真正做到了基于去中心化存储的数据删重。

虽然本发明已经参考特定的说明性实施例进行了描述，但是不会受到这些实施例的限定而仅仅受到附加权利要求的限定。本领域技术人员应当理解可以在不偏离本发明的保护范围和精神的情况下对本发明的实施例能够进行改动和修改。

Claims (10)

1.一种面向数据删重的去中心化存储方法，其特征在于：以在客户端实现在线去重，包括：

步骤1，将对象的命名与对象的存储位置进行解耦合；

步骤2，将对象的内容利用数据指纹的方式，与存储位置建立映射关系，从而使得相同内容的对象会被放置到相同的位置，只需维护对象名字与数据位置之间的映射关系，从而相同的数据只需要保存一份，同时数据指纹本身也降低了副本一致性检查的开销，系统可以使得数据和元数据达到最终一致性。

2.根据权利要求1所述的一种面向数据删重的去中心化存储方法，其特征在于所述一种面向数据删重的去中心化存储方法包括：

元数据的管理和组织方法、基于内容寻址的数据放置算法和副本一致性算法以及反向引用和垃圾回收算法，其中：

所述元数据的管理和组织方法包括对元数据的维护，在实现时将数据序列化并存储到一个单独的文件中，文件名用写入时刻的时间戳表示，具体过程包括：

(1)每次POST请求记录时间戳信息，将元数据序列化后写入文件，存储到缓冲区；

(2)将缓冲区的文件加入队列，等待写入最终的存储位置；

(3)读取时对时间戳进行排序；

(4)读取时间戳最新的元数据；

(5)一个优化是在每次进行访问时，可以清除掉系统中陈旧的元数据文件；

所述副本一致性算法包括数据的副本一致性维护，其步骤包括：

(1)节点在本地完成数据校验，如果校验出错，将损坏的数据移入隔离区；

(2)Replicator进程遍历本地文件系统，每次检查远程节点中是否存在最新的副本，如果不存在，则直接主动推送一份本地数据，如果存在，则终止；

(3)Replicator进程持续工作，对于数据依然是循环检查，防止磁盘故障和节点故障；

所述反向引用和垃圾回收算法包括：

三个操作原语Create、Merge、Delete：Create原语用来生成一条反向引用信息backref，并放入对象的存储目录中；Merge原语负责将单条反向引用信息backref并入反向引用映射表backmap，backmap的时间版本信息为backref的最大时间戳；Delete原语负责将已并入反向引用映射表的单条反向引用信息backref删除；对于对象存储服务，接口中仅PUT和DELETE操作会发生对反向引用的操作，此时会调用Create原语；Replicator在进行元数据推送时会进行合并和删除已处理的backref；GC负责检查backmap中是否为空，如果为空则将该对象回收；对象回收采用的悲观的处理方式，Replicator在执行Merge操作时会对backmap加锁，此时GC直接放弃对backmap的访问，或者GC发现仍有未被并入的backref存在，都会在下一个清理时间片再处理该对象；由于垃圾回收的频率较低，Replicator仅进行单线程操作，加锁时仅针对backmap信息，对数据的访问没有影响，系统对于锁的开销较低，Replicator可根据系统的负载来设置反向引用合并的周期，以防止大量写操作生成大量小文件对文件系统造成压力。

3.根据权利要求2所述的一种面向数据删重的去中心化存储方法，其特征在于：对于元数据的一致性维护采用Quorum仲裁协议、反熵协议和时间戳检查，利用这三种机制使得元数据可达到最终一致性：首先，对于一个对象的元数据在这个系统最终要达到的一致状态，由带有最新时间戳的元数据文件决定；其二，对于元数据的写入，根据Quorum协议，需要超过半数的副本完成写入成功后才可返回，故在一次写入操作中系统中会保有超过半数的最新版本的元数据；其三，对于一个对象的每一个副本，都会向其余的所有副本推送本地时间戳最新的元数据，实际上是按照反熵协议在几份副本当中以泛洪的方式传播最新的数据，直到所有的副本都达到一致状态，即都达到了写入最新的版本。

4.根据权利要求1所述的一种面向数据删重的去中心化存储方法，其特征在于所述方法还包括客户端对象划分步骤，包括：

(1)对象的数据片段组织，包括：在应用层存储基本单元与底层数据存储的基本单元之间引入一个映射关系，所述映射关系用一个manifest来组织，实质上是一个应用层对象到N个底层数据片段的映射关系，采用JSON格式存储所述映射关系；数据的哈希函数可以根据应用场景进行选择，并且在存储系统的运行当中是不改变的，哈希函数为md5哈希算法或哈希碰撞概率更低的sha-256哈希算法；

(2)对象划分与客户端实现，包括：windy客户端与swiftclient接口基本保持一致，在实现时主要在上传操作中加入了数据分段和指纹计算的功能；对数据的划分由客户端完成，全对象分块与定长分块相结合的方法，首先设定系统中定长分块的长度L，以该值作为阈值，检查对象的大小，对于大小小于L的对象进行全对象去重，并存储小数据片段的存储池，对于大小大于L的对象则进行固定长度分块；进行固定长度分块时，将长度为L的分段存入定长数据片段池，如果最后一个数据片段的长度不足L，也将存入小数据片段存储池，结合Chimes对象存储系统中建立的存储池，对数据片段进行合理的分配，将对象流转化为数据片段流，再将数据片段流进行重组；全对象分块对象级的去重方法，粒度较粗，适合对小文件处理；为了更细粒度的重复数据检测，将对象分割成固定大小的数据片段，也即基于静态分块的数据去重方法；客户端在去重时选择了全对象分块和定长分块，客户端和多个存储池能够支持变长分块算法；

(3)对象传输方法，包括：WindChimes存储系统外部由代理服务提供Swift API，内部由接口服务保存Swift API的相关信息，由Chimes对象存储系统保存对象的数据；进行对象传输时，由客户端、代理服务、接口服务、存储服务的共同配合完成。

5.根据权利要求4所述的一种面向数据删重的去中心化存储方法，其特征在于所述对象传输方法包括：

(1)通过PUT接口实现对象的上传操作，包括：对象流中的对象n准备进行数据上传，客户端将该对象分段，计算每个数据片段的指纹值；客户端按照指纹值列表生成manifest；客户端将该生成的manifest上传到WindChimes代理服务器，代理服务器将manifest写入接口服务器中，并将manifest中的每个指纹值在指纹库中进行检索；对于存在于指纹库中的数据片段，直接建立数据链接，实际是数据片段到应用层的反向引用；代理服务向客户端返回查询结果manifest*；客户端指明需要上传的数据片段；客户端上传存储系统中不存在的数据片段，并建立新的数据片段对象；更新新建数据片段的反向引用；解除不在manifest*中数据片段的引用；对象的上传需要客户端、代理服务器、接口服务器、存储服务器的共同配合完成。代理服务器在获得了对象manifest之后应当立即完成对数据片段的反向引用，否则在manifest上传和数据片段上传的间隙当中已存在的数据片段有可能被垃圾回收服务清除；

(2)通过GET接口来获取对象，包括：在WindChimes存储系统中，每个Swift对象对应了一个manifest，其中记录了该对象每个数据片段在Chimes对象存储系统中的信息。进行数据下载时，客户端首先取得Swift对象的manifest，然后客户端根据manifest中的指纹值列表取得每个数据片段，并重组成一个完整的Swift对象，由于Chimes对象系统中每个对象有多份副本，代理服务首先轮询该对象各副本所在的存储节点是否可用，然后选择一个最优的副本进行读取，这个最优的副本一般可选时间戳最新的一份副本，如果该对象在Tier0中存在，则优先选择读取Tier0中副本；在循环取得每个数据片段的步骤中，对每个数据片段的获取可以是可并行的，在实现时可以采用多线程并发访问的方式；

(3)通过DELETE接口删除系统中的对象，包括：WindChimes在删除Swift对象时主要有两个工作，其一是删除对象的manifest文件，其二是解除每个数据片段到该Swift对象的反向引用，在删除对象manifest时采用异步的方式，即并不是在系统中直接移除manifest文件，而是在manifest所在目录中建立一个带有时间戳的tombstone文件，表示该manifest已经被删除，在对manifest读取时会返回失败，被删除的manifest会由存储服务器完成清理。在建立tombstone文件的同时，系统会向存储服务器发送异步请求来解除数据片段到Swift对象的反向引用；接口服务向存储服务发送异步请求时，删除命令会被加入一个消息队列，并且该队列会在系统中保存状态，在系统宕机恢复后未完成的更新命令可由更新服务Updater继续完成。

6.一种面向数据删重的去中心化存储装置，用于实施权利要求1-5任一所述的面向数据删重的去中心化存储方法，其特征在于包括：

代理服务子系统及其接口；

接口服务子系统及其接口；

数据服务子系统及其接口；以及

Windy客户端和系统网络互联子系统；

三个服务子系统没有设置门面接口，而是由不同子系统的节点之间直接通信，其中代理节点把握全局信息，完成数据流的控制，在数据的流转过程中提供路由所需的网络拓扑信息；在对接口服务和数据存储服务的部署时引入了区域概念以对服务器的物理位置进行隔离，一个区域为一块硬盘、一台服务器、一个机架、一个交换机，甚至是一个数据中心，在计算一致性哈希映射时不同的数据副本会被确保放在了不同的区域中；对于代理服务集群，各个代理节点是全对称的部署方式，每台代理节点都有完全相同的配置，并且代理节点中只保存软状态，在一台代理节点不可用时可以迅速完成服务的失效备援，外部的数据请求通过一个负载均衡器进行转发到各个代理节点上，转发时可以借助负载均衡器提供的策略，包括基于轮转、基于权重或者随机转发，并且注意负载均衡器是系统中的单点，需要做高可用处理。代理节点在部署时结合数据存储服务和接口服务的区域，在不同的区域中分别部署代理节点。

7.根据权利要求6所述的一种面向数据删重的去中心化存储装置，其特征在于：所述代理服务子系统及其接口负责接收外界请求，并对上传下载数据流进行调度，包括：负载均衡器和代理节点，并且认证鉴权系统可以由代理节点本身提供，也可由第三方服务提供，所述负载均衡器负责接受外部请求，将请求转发到各代理节点，其中的分配策略由负载均衡器提供，包括随机分配、轮转分配；由于系统只提供了唯一的对外接口，所述负载均衡器是系统中唯一的单点，应当在负载均衡器上进行高可用保护；所述代理节点全对称部署，每个代理节点是完全相同的，可以完成规模上的水平扩展和故障时的备援，所述代理节点负责除数据服务，元数据服务以外的所有功能，包括各项中间件，包括认证鉴权、访问控制、流量控制、存储配额，所述代理节点中不保存状态，故障发生时仅会使得本节点上正在进行的通讯失败，并不会造成错误的传播；对象的时间戳是完成并发访问控制和达到最终一致性的重要因素，而该时间戳是由所述代理节点生成，对于各代理节点时钟的同步需要进行集中控制，采用集中式的NTP时钟同步协议完成，NTP服务采用Master-Slave模式，各个代理节点主动向NTP服务器对时，对于NTP服务器的可用性和时钟的顺序一致，可交由监控系统完成，同时，可在代理服务集群中运行分布式的时钟同步协议；所述代理服务的访问接口用于代理服务作为系统内部与外部的交界面，对外所提供的完整的REST API，并不向内部提供接口；代理服务包括中间件，用于对REST API表达能力的扩展，代理服务提供的中间件包括：

认证鉴权：代理服务对客户端的鉴权机制可以以中间件的形式存在，使用Swift系统提供的TempAuth、Openstack鉴权组件Keystone或者对鉴权部分进行定制；

访问控制：对系统中对象的访问控制通过中间件完成的，通过配置访问规则完成对不同用户对于不同容器和对象的访问控制；

存储配额：对容器和账户上传对象的大小、数目等方面进行限制；

数据缓存：系统中缓存信息的存放可以直接放在HTTP服务器的内存中，或使用第三方的memcached，通过中间件的形式抽象出统一的访问接口。

8.根据权利要求6所述的一种面向数据删重的去中心化存储装置，其特征在于：所述接口服务子系统及其接口用于完成系统对外接口Swift API向底层基于内容寻址的对象存储系统API的转换，是底层对象存储的一个视图，对Swift API，接口分为三个层次，分别是：账户、容器和对象(Object)。三者是从属关系，容器包含在账户之内，对象包含在容器之内，所述接口服务子系统包括Swift对象到底层的基于内容寻址的对象的映射和数据片段重组，账户和容器的管理可保持与Swift一致，对于三项服务，在数据分布方面采用一致性哈希算法，并引入虚节点以均衡数据在物理节点上的负载，在一致性维护方面，放弃强一致性，采用最终一致性模型，来达到高可用性和无限水平扩展能力；采用Quorum协议，并使R+W≤N，W为被写副本数量，R为被读副本数量，N为系统可用副本数量，为了保证数据的可靠性，写操作需要满足至少一半以上成功，即W>N/2，而读操作只需读取系统的一个可用副本，即R＝1，系统默认配置是N＝3，W＝2，R＝1，此种情况下在同一时刻被写的两份副本和被读的一份副本可能不交叠，故可能会读取到旧数据，数据在系统中的稳定状态是通过最新的时间戳来确定的，每个节点通过选择最新时间戳的一份副本来完成确定一个副本的一致状态，如果数据出现了不一致，后台服务进程会在一定时间窗口内通过检测和复制协议来完成数据同步，从而保证达到最终一致性；所述接口服务子系统还用于支持数据去重分块算法和对Swift Object对象数据进行重新组织，对于每个Swift对象，进行数据去重处理后会被分成若干个数据片段，在上传时完成拆分，拆成的每个数据片段对应了数据存储服务中的一个数据片段对象，对Swift对象进行访问时，对各个数据片段对象进行重组，对于每个Swift对象系统需要维护一张表manifest，该表中记录了组成Swift对象的数据片段信息，其中包括了数据片段在基于内容寻址存储系统中的唯一地址，长度和写入时间；同时，对于进行选择性上传的数据还应当完成对manifest的版本管理；接口服务的对外接口负责管理三类接口的数据，分别是Swift Account接口、Swift Container接口和Swift Object接口，三种接口都以REST API的形式存在，与Swift系统中内部API基本一致。

9.根据权利要求6所述的一种面向数据删重的去中心化存储装置，其特征在于：所述数据服务子系统及其接口包括：数据服务系统是一个完整的对象存储系统，对象通过一个扁平的命名空间寻址，遵循对象存储设备的设计原则，具有智能的自我管理能力，并能感知上层的存储应用；存储服务系统是一个大的容器，其中的基本元素是数据片段对象，同时，可以将具有类似特征的对象聚集在一起，放入一个存储池当中，存储池的设置为在每个存储池的底层部署不同特性的存储软硬件，利用异构存储资源提高数据的访问性能，数据服务子系统中设置一个或多个pool，每个pool采用一个独立的一致性哈希空间，每个pool之间保持逻辑上的独立，在物理部署上，单块磁盘只能属于一个pool，一个对象的完整命名应当是“/pool_id/hash”；pool_id的确定根据数据片段对象的固有特征，该特征必须是该数据片段在一个完整的生命周期中不变的信息，否则会影响到对象到存储节点的映射；利用数据片段大小来确定pool_id，根据pool_id来确定该对象数据所在一致性哈希环，然后通过数据片段对象的指纹确定该对象最终存储位置；同时，在每一个pool当中，按照replica_id来对对象的副本进行分层存储，根据对象在系统运行时的访问信息对对象的副本在各个存储层次上进行调度；数据服务是一个对象存储系统，基于数据片段的内容进行寻址，该子系统的数据访问接口采用RESTful的访问模式，数据服务的接口具有可编程能力，接口中主要包含5个操作，URL用来定位数据片段对象在存储节点上的位置，关于pool_id在代理节点上生成并通过pool_id获得节点的IP地址，故pool_id并不在存储服务的接口中出现；device表示对象位于存储节点上的磁盘位置，partition表示对象位于的虚节点，fingerprint是数据的指纹，由于其唯一性，直接用来完成一致性哈希中的寻址以及在节点上的数据定位；POST操作和HEAD操作负责更新和获取对象的元数据，应用层通过POST操作来自定义元数据项，以满足应用层的需求；PUSH操作用来像高性能的存储层推送对象；GET操作可通过fingerprint来直接获取数据片段内容；对于PUT操作，如果系统中不存在URL中所指的对象，则存储节点将新建一个对象，并通过PUT操作上传数据，如果系统中已经存在了该对象，则放弃数据上传，直接向应用层返回上传成功；DELETE操作在逻辑上是应用层删除对象后删除对应的数据片段，由于数据片段是共享的，不可直接删除，DELETE操作实际上是数据存储服务中一个解除引用的操作；在PUT和DELETE操作结束后，对象的反向引用，对象的被引用信息会被修改，完成对反向引用的维护；PUT操作是异步完成的，故应用层并无法确切知道对象上传完成后可用的时机；应用层可以选择不处理该情况，直接向客户端返回manifest，并不保证该manifest中所有数据片段是可用的，客户端并不知晓何时可获取完整的Swift对象；或者应用层维护manifest中所有数据片段是否全部准备好，待数据片段齐备后再向客户端返回manifest，则客户端一旦获取manifest就可直接顺利地进行数据下载，此时需要数据存储服务在对象可用后向应用层发送回调请求告知应用层该消息；PUT和DELETE操作的URL中包含反向引用的信息，并且在Header中要包含需要发送回调请求节点的位置信息。

10.根据权利要求6所述的一种面向数据删重的去中心化存储装置，其特征在于：所述Windy客户端和系统网络互联子系统用于完成数据分块、数据上传和数据访问，所述Windy客户端对Swift API进行编程，为用户提供更加友好的数据访问方式，以及根据去重算法对上传数据进行分段，并计算指纹信息；同时，客户端应当对代理服务中的鉴权机制有完整的支持；WindChimes对象存储系统的各个子系统之间虽然在功能上各司其职，但是在网络互联上是全连接的，扁平化的，在物理部署时同样是位于同一局域网内，任意两个节点之间可以互相通信。

Images