![]()
分布式文件存储系统主要被分为三种类型：分布式文件存储、块存储、对象存储。这三种存储系统都有着自己的特点和适用场景。
其中分布式文件存储和对象存储是联系非常紧密的，大多对象存储系统都是在分布式文件系统基础上实现的。
很幸运自己在过去的工作中对这三种系统都有过或深或浅的接触，因此有了想要把这其中零散的知识点做一个整理，毕竟才疏学浅，希望跟有兴趣的同学共同进步。
对于分布式文件存储系统，我们常常根据它的特点和功能模块做划分，才能从各个不同的角度去学习、了解和实现一个分布式文件存储系统
系统架构
对于目前所接触到的主流分布式文件系统来看，根据系统架构的特点大多可做如下划分：
这两种架构都有着自己明显的优势和缺点，对整个分布式文件系统的实现起决定作用，直接影响采用何种一致性协议保持备份间的一致性，以及集群如何管理，数据丢失或损坏该如何恢复、数据清理等等功能的实现，后面会单独对此做阐述和说明
集群管理
集群管理主要解决以下几个问题：
- 存储节点上下线通知，自动剔除不可用节点等
- 集群各节点心跳和状态的维护，是否健康，可读可写
- 维护系统的逻辑模型，如分区、用户等逻辑概念的关系，如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
