使用原因

需求

如果对一个短视频平台进行复刻，除却公共系统如客户端，账号系统评论系统等的架构设计，还需要构建短视频的生产消费架构。 以经典架构为分析：片源系统→审核系统→推荐系统

此架构中用户使用设备上传视频传输至服务器端以存储（源视频），抽帧并存储图片以供审核，转码不同码率视频存储于介质以供下载或实时观看。可见对存储的要求为这一架构的关键。

引入用户潜在数量这一变量考虑对存储的需求，考虑日需求量，月需求量和年需求量。作为时下的热门，短视频平台的市场潜力大，潜在用户量大，要求的存储量极大.

优势对比

各类存储回顾：

单个计算机的数据处理能力自然比不过多个计算机节点协同。

倒是挺想试试群晖建私有云来着

分布式数据库系统尽管所容纳的数据达上百亿条，单条记录的空间占用很小，容量计算下来并不高，大多数情况更加适合结构和半结构化的数据（如短视频平台视频的标签、评论等）

要存大量视频文件，只靠数据库是很南德拉，

分布式存储系统则将视频文件以对象或文件的形式进行存储，并通过分布式的方式将数据分散存储在多个节点上。这提供了更大的存储容量、高可靠性和高性能，也满足短视频平台对于大规模视频存储的需求。

分布式文件系统（HDFS）？对象存储（TOS）

HDFS和TOS均属于分布式存储系统。 具体的选择依据为以下三点 存储量，易用性和成本。

• TOS的存储量可达EB海量，且对象数量不受限制，HDFS存储量为PB→EB海量，文件数量会受到NameCode的限制。

（注： EB的数量级是PB的1000倍

对于HDFS，文件数量是受到名称节点（NameNode）的限制的，而不是存储容量本身。名称节点存储着HDFS文件系统的元数据，包括文件和目录的命名空间、访问权限、文件块的位置等信息。由于名称节点需要维护这些元数据，并提供文件系统的管理功能，因此它的处理能力和内存容量将直接影响到HDFS支持的文件数量。）

• TOS采用HTTP协议，将数据组织为对象，并为每个对象分配唯一的标识符（URL），可以随时随地在互联网设备访问存储云端进行上传和下载。其中包括一个存储桶（bucket）和多个数据对象（object）；接口简单，易于接入。

• HDFS采用TCP私有协议，无法直接使用HTTP访问；其中包括一个名称节点（NameNode）和多个数据节点（DataNode），即目录和目录下的多个文件；接口繁多，接入较复杂。

（注：每个Object都有一个唯一的键（Key），用于在特定的Bucket中标识和访问该对象(URL:{Bucket}/{Object Key})，另外包含与其相关的元数据（MetaData），如创建时间、大小、内容类型等，以及实际的数据内容（Data）。

名称节点负责管理文件系统的命名空间和元数据信息，而数据节点存储和提供数据块的读写操作。

HTTP协议是基于特定的请求-响应模型，要求遵循HTTP报文的格式和语义。）

• 二者均使用普通的X86服务器，但是TOS具备冷热数据分级存储能力，能够根据视频的流量转移存储文件到不同介质，成本更低。

海量，易用，便宜，选用对象存储为短视频平台存储便是最优解。

基本使用

在向云厂商申请了bucket后，便可以进行业务逻辑开发（功能区设计）

基本接口

对象存储一般提供RESTful接口，使用HTTP方法对资源操作 常见的 HTTP 方法和其对应的操作如下：

• GET：获取资源的信息，对应于读取操作。
• POST：创建新的资源，对应于写入操作。
• PUT：更新已存在的资源，对应于替换操作。
• DELETE：删除指定的资源。

基于以上方法设计对应功能：

• GET:下载视频
• PUT:上传视频，
• DELETE:删除视频，
• HEAD:查看视频元信息

MultiUpload接口

在传输G级大视频时，可能会造成网络卡顿，"MultiUpload" 是一种将大型文件分块上传的方法。当需要上传大文件时，将文件拆分为多个较小的块，并并行上传这些块。一旦所有块都上传完成，服务器就会将这些块合并成完整的文件。

listprefix接口

当按照指定的前缀条件逐页获取对象列表，可以使用分页列举（listprefix）的接口，用于获取大量对象的列表，并在一次请求中只返回部分结果，以便于处理和管理。

分页列举接口通常包含以下参数：

1. 前缀（Prefix）：指定要列举对象的前缀条件。
2. 分页大小（Page Size）：指定每页返回的对象数量。
3. 分页标记（Page Token）：指定当前页的标记或令牌，用于获取下一页的数据。

使用分页列举接口可以首先发送一个初始请求，指定前缀、分页大小等参数，系统会返回第一页的对象列表以及一个分页标记。然后，通过提供该标记作为下一页请求的参数，可以获取下一页的对象列表，以此类推，直到所有对象都被列举完毕。

后期研发

为应对投入市场后增长的云使用量和数据量，需要自研对象存储。

以下为经典架构存储结构：

（写入，读取元信息）元信息层←接入层（处理接口）→存储引擎层（写入读取元内容）

通过分析负责的业务：容量型（存储，转码），QPS型（抽帧） 总结业务面临挑战：可扩展性（容量和单位处理请求量），成本，持久度（保存能力）。

对于对象存储系统或其他服务，QPS可以表示系统在一秒钟内能够处理的特定操作的请求数量，如上传文件、下载文件、删除对象等。通过监控和评估系统的QPS，可以了解系统的负载情况，从而进行容量规划和性能优化。

可扩展性解法之partition

将不同数据通过某种规则（如哈希（Hash）或范围（Range））划分到不同的分区，数据量增加时通过扩容机器新建分区partition，将数据按照规则划分即可。

分区规则（partition logic）

哈希分区：

• 数据均匀性：哈希函数能够将数据均匀地散列到不同的分区中，避免了数据倾斜问题，保证了数据的负载均衡。
• 随机性：哈希函数产生的输出是随机的，这样可以防止数据在特定分区上的聚集现象，提高系统的性能和可扩展性。
• 增量扩展：由于哈希分区的随机性，增加新的分区时不会对现有数据进行迁移操作，只需将新数据哈希到新的分区即可。
• 查询效率较低：特别是在需要查找具体数据时，需要对所有分区进行遍历或使用哈希索引技术。

范围分区：

• 有序性：范围分区将数据按照某种顺序划分到不同的分区中，使得相邻的数据可能在相邻的分区中，有利于范围查询和有序访问的性能优化。
• 可预测性：相比哈希分区，范围分区的分区结果更可控。可以根据业务需求和数据特征进行合理的范围划分，更好地满足不同查询模式的需求。
• 数据不均匀性：能导致数据分布不均衡的问题，某些分区可能会比其他分区拥有更多的数据。

总结优劣：

考虑到分布式存储中分布式概念为存储均匀分布，压力均匀分布，计算均匀分布；范围（Range）并不能够很好控制数据的均匀性，故哈希分区应当是在多数情况下优于范围分区。

分区均衡的维系：

• 动态调整分区：根据实际数据变化情况动态调整分区。如果发现某个分区的数据过多或过少，可以重新划分或合并分区，使得数据能够更均匀地分布到不同的分区中。
• 实时监控与负载均衡算法：监控每个分区的负载情况，根据实时的负载情况来动态地调整数据的路由。可以采用负载均衡算法，如轮询、加权轮询、最少连接等，将请求均匀地分配到各个分区，避免某个分区过载。
• 自动化管理：引入自动化管理机制，例如自动故障检测和恢复机制，能够快速发现和处理分区的失效或负载过重等问题，保证分区的负载均衡。
• 数据迁移与重新平衡：当数据发生变化时，例如新增数据或删除数据，需要进行数据迁移和重新平衡操作，将数据重新分布到各个分区中，保持负载均衡。

持久度解决之Replication

通过拷贝副本并通过多机架，多机房，多Region存储，得到数据的高持久度（即便某个副本不可用，其他副本提供服务）和强吞吐能力（多个副本提供服务，并行处理请求分担系统负担）

复制方式

• 全同步复制：在写操作完成之前，要求所有副本都完成数据的复制。
• 异步复制：在写操作完成后，不等待所有副本完成数据复制，而是立即返回给客户端。副本的复制过程会在后台异步进行。
• 半同步复制：结合了全同步复制和异步复制的特点。在写操作完成之前，至少有一个副本完成了数据的复制。
• 延迟复制：在数据复制过程中引入一定的延迟，使得副本的数据比主要数据有一定的时间差。
• 多主复制：允许多个节点进行写操作，并将写操作的数据复制到其他节点。

一致性问题解决

• 基于主节点复制：在多副本中指定一个主节点负责接收写操作，然后将写操作应用到其他副本。主节点可以使用同步或半同步复制方式，等待至少一个副本确认写操作已完成后才返回成功给客户端。
• 基于多数副本复制：要求写操作达到多数副本的确认才返回成功。比如，如果有三个副本，至少有两个副本确认写操作后才认为写操作成功。这样可以确保多数副本之间的数据一致性。
• 基于一致性协议：使用一致性协议（如Paxos、Raft等）来协调副本之间的写操作顺序和状态变更。通常包括消息传递、投票和状态机等步骤，以确保副本之间的数据操作按照一定的顺序执行。
• 基于向量时钟：一种用于区分事件顺序的逻辑时钟。每个副本都有自己的向量时钟，记录了它观察到的事件顺序。当副本之间要进行数据合并时，可以使用向量时钟来判断事件的因果关系，从而解决冲突并保持数据的一致性。

成本解法之EC

使用EC将数据进行编码和分片可以减少传统的数据复制方式中文件复制到不同位置时消耗的带宽，并且分片代码即使丢失也可以通过其他代码还原。增加了额外的编码计算步骤但是成本较单纯的多副本低

EC采用的编码技术

• RAID：RAID是一种基于硬件的冗余存储方案，通过将数据分布在多个磁盘上并使用校验信息，实现数据的冗余和恢复。
• 哈希-冗余码：利用哈希函数对数据进行切分和编码，生成冗余数据块。这样可以通过校验和的校验来验证数据的完整性，并在部分数据丢失时进行恢复。
• 带宽优化的编码方案：这类编码方案主要针对带宽有限的情况，通过降低数据冗余度来减少传输的数据量。例如，网络编码（Network Coding）可以将不同来源的数据进行混合编码，以减少传输所需的带宽。

多机房的EC实现

• 数据切分：将原始数据按照片段进行切分，确保每个片段的大小适中。这样可以提高数据冗余度和容错能力，并方便后续的编码操作。
• 编码方案选择：选择适合多机房环境的编码方案。常见的编码方案包括Reed-Solomon编码、Cauchy矩阵编码等。这些编码方案都可以实现数据切片和冗余数据的生成，并且可以通过修复算法在部分数据丢失时进行数据恢复。
• 冗余数据分布：将生成的冗余数据块在不同的机房中进行分布。这样可以确保即使发生机房故障，仍然有足够的冗余数据可供恢复使用。
• 跨机房传输：在多机房之间进行数据传输时，需要考虑网络延迟和带宽限制等因素。为了减少网络传输的负载，可以采用压缩、增量传输等技术来优化数据传输性能。
• 数据恢复：当某个机房发生故障导致数据丢失时，需要进行数据恢复操作。根据具体的编码方案，使用修复算法对丢失的数据进行重建。
• 故障检测与容错：定期检测每个机房的状态，发现故障并及时采取相应的措施。当一个机房发生故障时，从其他机房中的冗余数据恢复数据，确保系统的可用性和数据的完整性。

成本解决之温冷转换：根据视频的发布时间或者流量大小，将冷数据存储在性能差且廉价的存储介质中

可用性解决之集群拆分：一个集群不可用后，其他集群不被影响，业务不至于瘫痪

可用性解决之镜像灾备：完全镜像的主备Bucket，实现增量同步双向同步，在主Bucket不可用后，备Bucket处理请求。

总结

对象存储在互联网应用市场中具有海量的存储需求，并且凭借其海量，便宜，易用的特性成为存储最优解。尽管针对当下EB级的需求已经发展了解决方案，数量级增长的容量存储要求、存储成本、稳定性优化，以及未来大数据生态联系着其未来前景。