自制文件系统 —— 05 总结：一切都为了狙击“文件”

发表于 3年以前 | 总阅读数：268 次

坚持思考，就会很酷

为什么会有这个系列？

自制文件系统系列的开端，主要是因为绝大部分人用到了文件这个概念，但是总**是不以为然或者讳莫如深**。其实关键还是对其原理缺乏了解。总有朋友对 inode，文件的管理，权限等等有疑问，而这些只是最基础的概念。

自制文件系统的诞生理由就来源于此，目的是让大家认清楚，文件是怎么来的，权限是怎么来的，文件系统不过如此，朴实无华。

自制 FS 系列的特点

自制文件系统系列是一个完整的系列，从最开始教你看文件系统，介绍 FUSE 框架，最后做一个只读的文件系统，再做一个可写的分布式文件系统，是层层递进的。

[03篇] ，[04 篇] 介绍了原理并且附有完整的 Go 实现代码，可以让 0 基础的朋友，也能完整的制作出来，至于领悟多少，就看个人发挥了。

自制文件系统系列是典型的实战系列，着眼于动手，而不是纯粹的讲解。并且笔者也尽可能的把复杂的，非主干的知识剔除，目的是让你感受纯粹的文件系统，文件的概念。

我们学到了什么？

亲自参与了文件的组织管理，权限的配置，内容的处理，加密存储，解密读取；
亲自参与了数据的跨节点传输；
亲手捕捉了来自内核的 IO 请求；

分布式存储远不止如此！

你以为文件系统就这样了吗？不不不，还远远不够。

我们在 [04 篇 ] 里提到了分布式文件系统的架构，分为 Client，元数据中心，Server 这三大部分。

1 客户端

Client 一般会有哪些功能在里面？如下图：

哈希策略

客户端主要是承接用户请求，然后把请求分发到后端服务器，这里就涉及到怎么分发的策略了。

一般有 3 类分发策略：

轮询：请求依次分发，这样能保证每一个后段节点都能得到请求；
普通哈希：普通的哈希策略，这个考量一定的随机性，一般可以选定一个随机因子。比如时间戳，请求数等等；
一致性哈希：这个方式在扩缩容的场景有比较好的表现，能够保证在扩缩容的保证迁移量控制在一个常数级别；

轮询下发示意图：

思考问题：哈希策略是为了后端节点的请求均衡，那如果由于各种原因已经导致了不均衡，怎么办？

这时候就要提到重要话题了：均衡迁移，一般也叫做 balance ，目的就是为了每个节点的数量平衡。

由于 balance 迁移一般会跟正常业务抢占 IO 资源，所以这里会涉及到 Qos 的策略，并且 balance 的触发时机和力度都是必须要考虑的。

哈希均衡是一个分布式系统里重要的模块功能，关系到怎么才能合理利用分布式机器节点。balance 的一个重要考量是：迁移尽量少的数据，避免过多的资源浪费。

副本策略

副本就是数据存储多个副本的意思，这样就避免单点问题，数据就算丢了一份，还有其他份，这样可以提高可靠性。多副本说起来简单，但其实有很有讲究，其中最关键就是一致性的问题。

怎么能保证写下去的数据是一致的？这里就关乎策略了，都写成功了才算成功，还是写部分成功了就报告成功？

上面分别对应两大类策略：WARO（Write ALl Read One），Quroum。这两大策略被统一在 CAP 理论里面，你要可用性高，那么必然要容忍一段时间的不一致。要数据完全一致，同一个副本组那么可用性就会拉跨。副本策略一般用 WRAO 是最简单的实现。

WRAO

Quroum

现在讲了副本的策略，那么组成副本的形式又有哪几种呢？

这个其实可以按照粒度来区分，一般有几种形式组成副本：

文件级别
磁盘级别
主机级别

主机级别

优点：这个简单了，把多台主机组成副本镜像，主机的数据完全一致，互成镜像；
缺点：修复的粒度太大，扩容、缩容的粒度必须是副本数倍数的主机数，而且要是同构的机器，这个给资源准备提出了高要求；

磁盘级别

优点：磁盘镜像（这个跟 raid 1 很像，区别在分布式上）实现比主机级别的复杂点，这个是把多个磁盘组成副本镜像组。这个扩容、缩容的粒度就可以做到磁盘级别；
缺点：实现自然是比主机镜像要复杂，修复粒度还是较大，副本粒度还可以再做小一点；

文件级别

优点：把多个文件组成副本镜像组，副本粒度更小，调度更灵活。并且可以实现全局打散，让一块磁盘和所有的主机产生副本关系。这样在修复盘的时候，效率最高；
缺点：但同样的，粒度越小实现越复杂，元数据膨胀，越难管理；

纠删码策略

纠删码也是数据冗余的一种策略，和副本不同，纠删码能够做到更高的可靠性和更低的冗余度。什么意思？

举个例子：

在 3 副本系统中，1 TiB 的用户数据，需要 3 TiB 的物理空间。只能容许一个副本节点损坏；
在 6+3 的纠删码系统中，1T 的用户数据，只需要 1.5 TiB 的空间，能够容许 3 个节点损坏；

纠删码的优势够大，对吧？特别是在这个数据为王的时代。公有云厂商如果用更低的价格存储了更多的数据，那就有极大的竞争力。

俗话说的好，天下没有免费的早餐。纠删码也是如此，虽然有更高的可靠性，还有更低的冗余度。但是却带来更复杂的管理，还有更多的计算能力要求。

划重点：校验块是要用算法计算出来的，吃 CPU ，所以纠删码的节点，CPU 不能太差。因为写的时候要计算，修复读的时候要计算。注意，纠删码通常是用 Quroum 来提高可用性。

修复策略

修复策略，这个跟冗余策略是关联的。

副本镜像策略的话，修复就是数据拷贝成镜像即可，把数据源拷贝到目的文件；
纠删码的修复就是通过算法计算出缺失的数据块，然后写到目的地（这里是要吃计算能力的）；

修复策略跟副本镜像级别有很大关联，如果是文件级别，那么修复粒度可以做到文件，如果是磁盘级别，那么修复的数据量就会响应的大了。

2 元数据中心

元数据中心一般有哪些功能？

顾名思义，就是元数据集中放置的地方，一般会放置一些用户的元数据，当然还有集群本身的元数据。这是一个非常重要的角色，但是由于过于重要，所以问题也常常会出现在这里，比如性能瓶颈，单点故障，那遇到这种情况，你会怎么做呢？

怎么解决单点故障？

划重点：以前说过的，使用冗余的节点是解决单点故障的唯一途径。 多节点随之而来的是一致性，所以一般用 Paxos，raft 或者其他一致性算法来管理管理多节点，形成一个对外有机的整体。

怎么解决性能问题？

性能这个就尴尬了，除非是支持线性扩容，否则这元数据中心必定是有性能极限的。所以一般通过固化集群规模，搭建多个集群来解决。

更极端一点？

是的，还有更极端的方式：取消元数据中心，设计一个无元数据的集群**。**

有项目实践的例子吗？

有，比如 Glusterfs ，就是一个典型的实现，最大的特点就是无元数据中心。

服务注册发现

一般元数据中心还可以加上一个服务注册发现的功能，这样就能在集群组件扩容，缩容的时候从容面对。

集群拓扑管理

集群拓扑的管理是元数据中心必须承担的责任。比如副本镜像的绑定关系，纠删码的绑定关系，存储节点的状态维护等等。

举个例子，A，B，C 这三台主机组成一个主机镜像。

192.168.56.1
192.168.56.2
192.168.56.3

这样写数据的时候如果选到了这组主机镜像，那么就只需要把请求发往这三台主机。

3 服务端

Server 一般有哪些功能？

存储服务端最核心的就是存储用户数据，管理磁盘空间，这是最核心的需求。

在这个模块什么是最重要的考虑？

稳定和安全。怎么把数据快速的存入，安全的持久化，快速的读出是这个模块最核心的诉求。

存储引擎

所谓存储引擎就是最底层存储数据的模块，比如和文件，或者块设备打交道的模块。目的是掏空硬盘硬件的性能，跑出最高 iops，最高吞吐，最低时延是这里的毕生追求。

这里的主角是 IO ，引擎模块就是要极限的压榨出 IO 的极限性能。

举个例子？

有，很多，比如 rocksdb 其实就可以作为一个很好的存储引擎模块，这个是一个 kv 存储引擎库，以前常用于 mongodb 的底层。当然了，现在 mongodb 已经改用 WiredTiger 这个存储引擎。

空间回收策略

业务上增、删、改是常有的事。数据新增了要扩容，删除了自然要回收，这样才能达到重复利用空间的目的。怎么回收？很简单的，就是把删除的空间腾出来即可。如下，Compact 就是一个非常简单的方式。

磁盘坏盘策略

磁盘坏盘是经常的，所以换盘的流程是必须要设计的。这个是做到服务端（当然要客户端配合）。这个原则是什么呢？当然是数据安全。只有确认数据能够修复回来，那么就可以安全换盘。

这里只提到了一些最关键的模块，其实还有很多模块没提到，比如缓存策略，Qos 模块，任务调度策略等等。

自制系列对哪些人适用？

做存储的，对象存储，块存储，文件存储等从业人员；
Linux 后端开发人员；
大学生，正在理解“文件”的概念；
Go 开发人员，对存储感兴趣的开发人员；

总结

自制文件系统系列通过介绍文件系统，框架原理介绍，动手实践形成一个完整的系列文章，让人从 0 开始感受了一个文件系统的诞生；
文件系统内部也是分布式的，客户端和核心功能是协议解析，请求均衡转发，冗余策略（副本策略、纠删码策略），修复策略，等等。服务端的核心模块是存储引擎（单机存储），磁盘管理；
希望能让大家理解到一个观点：“文件”就是这样朴实无华。