分布式对象存储学习笔记（六）——数据冗余和即时修复

本文介绍数据冗余的概念和 RS码技术。介绍如何利用RS码实现对象存储系统的数据余策略，并详细述即时修复的实现方式

数据冗余的概念

去重是帮助我们避免同一个对象在系统中到处都被保存一份副本，而冗余是在完全受我们控制的情况下增加这个对象数据的稳定性。

数据丢失和数据不可用

数据丢失是指信息在存储、传输或处理的过程中由于错误或遗漏而发生损失。

• 数据在传输过程中的丢失通常是由于网络不稳定导致的，对数据进行校验可以有效检测出传输过程中发生的数据丢失，然后服务端就可以拒绝接收有损的数据。
• 数据处理过程中的丢失则可能是由于软件或人为的错误而造成的。对于软件错误我们需要对其进行修复并重新部署。对于人为错误，我们需要制定严格的操作规范。
• 存储硬件损坏是数据在存储过程中丢失的最常见的原因，可能发生的硬件损坏从某个硬盘出现坏道到整个数据中心受灾等不一而足，使用数据备份以及灾难恢复可以在一定程度上弥补损失，但是这通常都会造成几小时到几天不等的停机时间，而且系统最后一次备份点之后加入的数据也依然是无法恢复的。
• 服务器的维护可能导致数据暂时的不可用，比如预先安排的服务器重启等。在服务器重启过程中如果恰好有用户需要对其上的对象进行访问，那么同样会表现成数据丢失。
• 数据降解。数据降解是由数据存储设备的非关键故障累积导致的数据逐渐损坏。即使在没有发生任何软件错误或硬件损坏的情况下，存储介质上的数据依然有可能随时间的推移而丢失。

为了保护用户的数据，在计算机存储领域，依靠数据冗余来对抗数据丢失。 数据冗余不仅可以在一定程度上克服数据丢失，而且在发生数据丢失的时候还可以帮助我们对其进行修复。

数据冗余

在计算机领域，数据冗余是指在存储和传输的过程中，除了实际需要的数据，还存在一些额外数据用来纠正错误。这些额外的数据可以是一份简单的原始数据的复制，也可以是一些经过精心选择的校验数据，允许我们在一定程度上检测并修复损坏的数据。

对象存储系统的数据冗余策略

最显而易见的冗余策略是每个对象都保留两个或更多副本，由接口服务负责将其存储在不同的数据服务节点上。

跟去重之前完全无控制的状况不同，多副本冗余是受接口服务控制的有限副本冗余，副本对象的数量有限，而不是散落在每一个数据服务节点上。

多副本冗余的策略胜在实现简单，但是代价也比较高，我们实现的冗余策略比多副本冗余复杂，叫作 Reed Solomon 纠删码。

在编码理论学中，RS 纠删码属于非二进制循环码，它的实现基于有限域上的一元多项式，并被广泛应用于 CD、DVD、蓝光、QR码等消费品技术，DSL、WMAX等数据传输技术，DVB、ATSC等广播技术以及卫星通信技术等。

RS纠删码允许我们选择数据片和校验片的数量，我们选择了 4个数据片加两个校验片，也就是说会把一个完整的对象平均分成6 个分片对象，其中包括 4 个数据片对象，每个对象的大小是原始对象大小的 25%，另外还有两个校验片，其大小和数据片一样。这6个分片对象被接口服务存储在6个不同的数据服务节点上，只需要其中任意4个就可以恢复出完整的对象。

要在对象存储系统中评价一个余策略的好坏，主要是衡量该策略对存储空间的要求和其抗数据损坏的能力。

对存储空间的要求是指我们采用的冗余策略相比不使用冗余要额外支付的存储空间，以百分比表示。
抗数据损坏的能力以允许损坏或丢失的对象数量来衡量。

使用4+2的RS码的策略，我们的存储空间要求是150%，抵御能力是 2(可以丢失6个分片对象中的任意两个)。

对于一个 M+N RS 码(M 个数据片加N个校验片)，其对存储空间的要求是(M+N)/M*100%，抵御能力是 N。

• RS 码余策略对存储空间的要求更低，而抵御数据损坏的能力却更强。
• RS码将一个大对象拆分成多个分片对象分别存储，有助于数据服务层的负载均衡。

使用了 RS码余策略之后，对象存储系统单个节点的维护就不会导致整个系统的停机。只要我们每次维护的节点数小于N，那么任意对象的分片数依然大于M，对象就可以正确恢复。

数据余的实现

REST接口

底层使用的数据冗余策略对上层的接口不产生任何影响。

对象PUT流程

这里略过了那些没有发生变化的地方，比如接口服务计算对象散列值以及当散列值不一致时的处理。

接口服务会将客户端 PUT 上来的数据流切成4+2 的分片，然后向6个数据服务节点上传临时对象.X，同时计算对象散列值。如果散列值一致，6 个临时对象会被转成正式的分片对象.X，其内容被保存在 STORAGE_ROOT/objects/.X.文件中。其中X 的取值范围为0~5 的整数，表示该分片的 id，0~3是数据片，4和5则是校验片。是该分片的散列值，在转正时通过计算临时对象的内容得到。

对象GET流程

接口服务发送针对对象散列值的定位信息，含有该对象分片的数据服务共有 6个，它们都会发送反馈的消息。接口服务在收到所有反馈消息后向响应的数据服务分别 GET 分片对象.X。数据服务读取分片X 的内容并响应接口服务的请求，然后接口服务将数据片0到3 的内容组合成对象来响应客户端的请求。

接口服务在进行定位时的超时和之前一样是 1s如果在 1s 内收到所有6个定位反馈则定位成功：如果在 1s 超时后收到的定位大于等于 4，那我们依然可以恢复出完整的对象；如果定位反馈小于等于3，则定位失败。

当数据服务的接口收到的请求对象是.X，数据服务需要自己去STORAGE_ROOT/objects 目录下寻找.X 开头的文件.X.，然后在返回该文件内容时还需要进行数据校验，确保其内容的散列值和一致。如果不一致，则需要删除该分片对象并返回 404 Not Found。这是为了防止该分片对象被上一节介绍过的数据降解破坏。

接口服务可能由于分片定位失败或分片散列值不一致等原因无法获取某个分片的数据。如果失败的分片数小于等于 2，接口服务会根据成功获取的分片重塑数据，并将新的分片写入随机的数据服务; 如果失败的分片数大于等于 3，我们对这样的数据丢失无能为力，只能向客户端返回404 Not Found。

小结

本章介绍了数据损坏的成因以及用数据冗余防止数据损坏的技术，并实现了 4+2 RS码的数据余策略。使用这种数据分片技术的余策略

• 好处是在抵御数据丢失风险的同时，并没有显著增加对存储空间的要求，而且变相提高了整个存储系统的负载均衡。
• 缺点则是实现较为复杂，参与单个对象上传下载流程的节点数量显著增加。

我们采取了比较激进的修复策略:查到任何数据发生丢失都会立即进行修复。对象存储服务在上线以后，由于软件升级、硬件维护、服务器宕机等各种原因导致的暂时性数据不可用十分常见，我们的修复策略需要考虑到这样的情况，而适当放宽修复的标准。比如，我们可以放过还有 5 个分片的对象，只修复有 4 个分片的对象。

本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！