说说分布式文件存储系统

本文涉及的产品
对象存储 OSS,20GB 3个月
对象存储 OSS,恶意文件检测 1000次 1年
对象存储 OSS,内容安全 1000次 1年
简介:
 
 
 

分布式文件存储系统主要被分为三种类型:分布式文件存储、块存储、对象存储。这三种存储系统都有着自己的特点和适用场景。

其中分布式文件存储和对象存储是联系非常紧密的,大多对象存储系统都是在分布式文件系统基础上实现的。

很幸运自己在过去的工作中对这三种系统都有过或深或浅的接触,因此有了想要把这其中零散的知识点做一个整理,毕竟才疏学浅,希望跟有兴趣的同学共同进步。

对于分布式文件存储系统,我们常常根据它的特点和功能模块做划分,才能从各个不同的角度去学习、了解和实现一个分布式文件存储系统

系统架构

对于目前所接触到的主流分布式文件系统来看,根据系统架构的特点大多可做如下划分:

  • 有无中心管理节点
  • 存储节点是否有主从之分

这两种架构都有着自己明显的优势和缺点,对整个分布式文件系统的实现起决定作用,直接影响采用何种一致性协议保持备份间的一致性,以及集群如何管理,数据丢失或损坏该如何恢复、数据清理等等功能的实现,后面会单独对此做阐述和说明

集群管理

集群管理主要解决以下几个问题:

  • 存储节点上下线通知,自动剔除不可用节点等
  • 集群各节点心跳和状态的维护,是否健康,可读可写
  • 维护系统的逻辑模型,如分区、用户等逻辑概念的关系,如swift系统中提到的region,zone,node,patition等逻辑概念及从属关系

数据定位

即客户端如何根据文件名快速查找到数据的位置并获取到文件内容,目前接触到分布式存储系统在解决数据定位问题上,有两种方式。一种可以称作为计算方式,即最常见的hash算法定位,另外一种可称为查询时,将映射关系存储起来,通过查询的方式定位文件位置。

其中,哈希算法是最常见的数据分布方式,其方法是按照数据的某一特征计算哈希值,并将哈希值与机器中的磁盘建立映射关系,以swift为代表的一致性哈希算法也属于此类的改良品种,用哈希的方式优点是明显的,不需要记录的元信息,任何节点只需要知道哈希函数的计算方式即可以知道数据存储的位置,但是也存在一些问题,及增加或减少节点势必或多或少都会引起数据的迁移。

而讲到的另外一种查询的方式,一般不会集中去存储文件映射的元数据信息,因为随着集群规模的增长,元数据服务器较为容易成为瓶颈,所以常常是采用多个元数据服务机制去解决这个问题。

存储引擎

存储引擎,即数据最终是以何种形式存储在单机系统上。大多分布式文件系统的底层存储形式都是依赖本地文件系统接口,如Swift,Ceph等底层文件存储,毕竟分布式文件系统本身已经很复杂了,很难从上层一直到底层存储都自己去实现,而本地文件系统已经很成熟完善,所以大部分分布式文件系统都是依赖本地文件系统去实现的。

对不同的分布式文件系统在单机上的存储格式是不一样的,以swift为例它是以一个个文件的形式存储在单机文件系统中,即一个文件就对应在单机上也就是一个文件(忽略对象存储那一层的大文件映射关系),而还有另外一种分布式文件系统,在单机文件系统中是多个文件合并存储,以一个大文件的形式存储在单机文件系统中,同时记录每个文件的操作日志,可以理解为对小文件进行了合并。

这两种存储方式都有各自的利弊,并有各自的适用场景。对文件进行合并的日志文件系统,虽然会有文件的二次定位问题,但它有一个明显的优势,即小文件的读写性能会有明显的提升,而对于swift采用的这种不进行合并存储的系统来说,实现相对容易,但小文件的读写磁盘必然会成为性能的瓶颈。

存储副本

副本(replica/copy)的存在是为保证分布式系统中数据冗余,在不同的节点上持久化同一份数据,当出现某一个节点的存储的数据丢失时,可以从副本上读到数据,是分布式系统解决数据丢失异常的唯一手段。

对于可靠性要求高的数据进行三备份存储,甚至要求副本跨分区存储;而对于可靠性要求低的数据,两备份就能满足需求。随着存储的数据量增加,多副本存储会导致存储成本增加,因此有了纠删码的方式,可以极大的节省存储成本,并且可以提升数据的可靠性。

多副本存储引发出了一些需要解决的关键问题,如副本数据的一致性,如何保证副本数量和位置正确等等。

一致性协议

一致性协议是分布式文件系统核心问题之一,说的是如何保持副本内容的一致性。常见的三种一致性模型如下:

  • 强一致性:当更新操作在某个副本上执行成功后,之后所有的读操作都要能够获得最新的数据。
  • 弱一致性:当更新某数据时,用户读到最新的数据需要一段时间。
  • 最终一致性:它是一种特殊形式的弱一致性。它不能保证当某个数据X更新后,在所有后续对X的操作能够看到新数据,而是在经过一个时间片段之后,才能保证。在这个时间片段内,数据可能是不一致的。

在多个副本节点没有主从之分的分布式系统中,数据一致性的保证往往由客户端保证,这里的客户端指的是分布式文件系统的接入层,如swift的proxy节点,swift采用的是Quorum 仲裁协议,即 R+W>N。Swift 默认配置是 N=3,W=2>N/2,R=1 或 2,即每个对象会存在 3 个副本,这些副本会尽量被存储在不同区域的节点上;W=2 表示至少需要更新 2 个副本才算写成功;当 R=1 时意味着某一个读操作成功便立刻返回,此种情况下可能会读取到旧版本(弱一致性模型);当 R=2 时,需要通过在读操作请求头中增加 x-newest=true 参数来同时读取 2 个副本的元数据信息,然后比较时间戳来确定哪个是最新版本(强一致性模型)

而当多副本之间是有主从节点之分的系统中,数据的一致性大多由主节点保证,客户端的写请求发往主节点,主节点更新成功,同时将请求转发至从节点,收到所有从节点的成功响应后,再返回成功(强一致模型)。

两种方式的优缺点后续会从实现以及性能角度展开说明。

数据恢复

对于有中心控制节点和无中心控制节点的分布式文件系统,数据恢复的实现也会大为不同

有中心节点的系统,数据恢复大多是由中心节点负责控制调度,因为只有它有存储节点和存储介质的全局信息,而每个存储节点能做的就是等待中心节点的调度执行数据恢复的任务

无中心节点的系统,数据恢复的实现只能由各个存储节点负责,如swift,根据ring的信息获取副本的位置,通过数据恢复的进程,维持副本的数量和位置的正确性

数据清理

对于用户调用删除接口进行删除的数据,是直接删除?还是标记删除?直接删除固然是最简洁方便的,但是同时也意味着如果是误删的情况下数据无法找回,而对于标记删除,需要一个额外的模块对标记删除的数据进行扫描,再实施真正的删除,在某种程度上减少了数据丢失的风险。

异常处理

异常处理是分布式系统中需要处理的核心问题之一,只有合理处理了各种可预知的和未知的异常,才能保证分布式存储系统的可用性和可靠性。常见的异常有节点宕机、网络异常、硬件故障等等,异常处理不恰当导致不可用和系统性能问题都有经历过,而对于分布式文件系统改如何处理遗产个,以及如何通过压力异常测试保证系统可用性等等,都是比较大的话题,在后续进行展开。

通信协议

通信协议主要指的是分布式文件系统中节点之间的通信主要采取何种协议,以swift为例的节点间所有的通信都采用的是HTTP协议,另外一种常见的通信协议即采用RPC协议进行通信。

采用HTTP协议,从系统的使用和可测性角度来说是有利的,但同时也意味着一次请求到达不同的节点都会经过不断的解析和封装,势必是会有些损耗的,尤其是在跟rpc协议相比,之前做过性能对比,但对于存储系统来说,这点延时就不算什么了。

采用RPC协议,在代码实现上来说是简单方便的,但跟HTTP协议比起来,在做一些分层的功能和性能测试时,可测性会受到影响,就是稍微麻烦一些的,但总的说来还可接受。

读写流程

分布式文件系统的架构决定了其读写流程必然会有些不同,如有中心节点的系统,客户端的写操作首先会到中心节点获取该写到哪个节点的信息,而对于有主从之分的存储节点来说,客户端的读操作一般会优去主节点读。。。

以上,简单的给自己列了一个框架,然后再分别将其填满。靡不有初,鲜克有终,希望自己可以坚持!

 
作者:左琴
来源:51CTO
相关实践学习
借助OSS搭建在线教育视频课程分享网站
本教程介绍如何基于云服务器ECS和对象存储OSS,搭建一个在线教育视频课程分享网站。
目录
相关文章
|
4天前
|
存储 运维 负载均衡
构建高可用性GraphRAG系统:分布式部署与容错机制
【10月更文挑战第28天】作为一名数据科学家和系统架构师,我在构建和维护大规模分布式系统方面有着丰富的经验。最近,我负责了一个基于GraphRAG(Graph Retrieval-Augmented Generation)模型的项目,该模型用于构建一个高可用性的问答系统。在这个过程中,我深刻体会到分布式部署和容错机制的重要性。本文将详细介绍如何在生产环境中构建一个高可用性的GraphRAG系统,包括分布式部署方案、负载均衡、故障检测与恢复机制等方面的内容。
41 4
构建高可用性GraphRAG系统:分布式部署与容错机制
|
23天前
|
消息中间件 中间件 数据库
NServiceBus:打造企业级服务总线的利器——深度解析这一面向消息中间件如何革新分布式应用开发与提升系统可靠性
【10月更文挑战第9天】NServiceBus 是一个面向消息的中间件,专为构建分布式应用程序设计,特别适用于企业级服务总线(ESB)。它通过消息队列实现服务间的解耦,提高系统的可扩展性和容错性。在 .NET 生态中,NServiceBus 提供了强大的功能,支持多种传输方式如 RabbitMQ 和 Azure Service Bus。通过异步消息传递模式,各组件可以独立运作,即使某部分出现故障也不会影响整体系统。 示例代码展示了如何使用 NServiceBus 发送和接收消息,简化了系统的设计和维护。
38 3
|
30天前
|
消息中间件 存储 监控
消息队列系统中的确认机制在分布式系统中如何实现
消息队列系统中的确认机制在分布式系统中如何实现
|
30天前
|
消息中间件 存储 监控
【10月更文挑战第2天】消息队列系统中的确认机制在分布式系统中如何实现
【10月更文挑战第2天】消息队列系统中的确认机制在分布式系统中如何实现
|
29天前
|
存储 开发框架 .NET
C#语言如何搭建分布式文件存储系统
C#语言如何搭建分布式文件存储系统
59 2
|
29天前
|
分布式计算 Hadoop 网络安全
Hadoop-08-HDFS集群 基础知识 命令行上机实操 hadoop fs 分布式文件系统 读写原理 读流程与写流程 基本语法上传下载拷贝移动文件
Hadoop-08-HDFS集群 基础知识 命令行上机实操 hadoop fs 分布式文件系统 读写原理 读流程与写流程 基本语法上传下载拷贝移动文件
27 1
|
29天前
|
存储 机器学习/深度学习 缓存
Hadoop-07-HDFS集群 基础知识 分布式文件系统 读写原理 读流程与写流程 基本语法上传下载拷贝移动文件
Hadoop-07-HDFS集群 基础知识 分布式文件系统 读写原理 读流程与写流程 基本语法上传下载拷贝移动文件
39 1
|
19天前
|
消息中间件 存储 监控
消息队列系统中的确认机制在分布式系统中如何实现?
消息队列系统中的确认机制在分布式系统中如何实现?
|
19天前
|
SQL NoSQL MongoDB
一款基于分布式文件存储的数据库MongoDB的介绍及基本使用教程
一款基于分布式文件存储的数据库MongoDB的介绍及基本使用教程
35 0
|
29天前
|
存储 分布式计算 监控
C# 创建一个分布式文件存储系统需要怎么设计??
C# 创建一个分布式文件存储系统需要怎么设计??
29 0

热门文章

最新文章