主流分布式文件系统选型，写得太好了！，Java并发编程之JMM&volatile详解

三、对分布式文件系统的要求

---

对一个分布式文件系统而言，有一些特性是必须要满足的，否则就无法有竞争力。主要如下：

• 应该符合 POSIX 的文件接口标准，使该系统易于使用，同时对于用户的遗留系统也无需改造；

• 对用户透明，能够像使用本地文件系统那样直接使用；

• 持久化，保证数据不会丢失；

• 具有伸缩性，当数据压力逐渐增长时能顺利扩容；

• 具有可靠的安全机制，保证数据安全；

• 数据一致性，只要文件内容不发生变化，什么时候去读，得到的内容应该都是一样的。

除此之外，还有些特性是分布式加分项，具体如下：

• 支持的空间越大越好；

• 支持的并发访问请求越多越好；

• 性能越快越好；

• 硬件资源的利用率越高越合理，就越好。

四、架构模型

---

从业务模型和逻辑架构上，分布式文件系统需要这几类组件：

• 存储组件：负责存储文件数据，它要保证文件的持久化、副本间数据一致、数据块的分配 / 合并等等；

• 管理组件：负责 meta 信息，即文件数据的元信息，包括文件存放在哪台服务器上、文件大小、权限等，除此之外，还要负责对存储组件的管理，包括存储组件所在的服务器是否正常存活、是否需要数据迁移等；

• 接口组件：提供接口服务给应用使用，形态包括 SDK(Java/C/C++ 等)、CLI 命令行终端、以及支持 FUSE 挂载机制。

而在部署架构上，有着“中心化”和“无中心化”两种路线分歧，即是否把“管理组件”作为分布式文件系统的中心管理节点。两种路线都有很优秀的产品，下面分别介绍它们的区别。

1、有中心节点

以 GFS 为代表，中心节点负责文件定位、维护文件 meta 信息、故障检测、数据迁移等管理控制的职能，下图是 GFS 的架构图：

GFS架构

该图中GFS master 即为 GFS 的中心节点，GF chunkserver 为 GFS 的存储节点。其操作路径如下：

• Client 向中心节点请求“查询某个文件的某部分数据”；

• 中心节点返回文件所在的位置 (哪台 chunkserver 上的哪个文件) 以及字节区间信息；

• Client 根据中心节点返回的信息，向对应的 chunk server 直接发送数据读取的请求；

• chunk server 返回数据。

在这种方案里，一般中心节点并不参与真正的数据读写，而是将文件 meta 信息返回给 Client 之后，即由 Client 与数据节点直接通信。其主要目的是降低中心节点的负载，防止其成为瓶颈。这种有中心节点的方案，在各种存储类系统中得到了广泛应用，因为中心节点易控制、功能强大。

2、无中心节点

以ceph为代表，每个节点都是自治的、自管理的，整个 ceph 集群只包含一类节点，如下图 (最下层红色的 RADOS 就是 ceph 定义的“同时包含 meta 数据和文件数据”的节点)。

Ceph架构

无中心化的最大优点是解决了中心节点自身的瓶颈，这也就是 ceph 号称可以无限向上扩容的原因。但由 Client 直接和 Server 通信，那么 Client 必须要知道，当对某个文件进行操作时，它该访问集群中的哪个节点。ceph 提供了一个很强大的原创算法来解决这个问题——CRUSH 算法。

五、持久化

---

对于文件系统来说，持久化是根本，只要 Client 收到了 Server 保存成功的回应之后，数据就不应该丢失。这主要是通过多副本的方式来解决，但在分布式环境下，多副本有这几个问题要面对。

• 如何保证每个副本的数据是一致的?

• 如何分散副本，以使灾难发生时，不至于所有副本都被损坏?

• 怎么检测被损坏或数据过期的副本，以及如何处理?

• 该返回哪个副本给 Client?

1、如何保证每个副本的数据是一致的？

同步写入是保证副本数据一致的最直接的办法。当 Client 写入一个文件的时候，Server 会等待所有副本都被成功写入，再返回给 Client。

这种方式简单、有保障，唯一的缺陷就是性能会受到影响。假设有 3 个副本，如果每个副本需要N秒，则可能会阻塞 Client 3N 秒的时间，有几种方式，可以对其进行优化：

• 并行写：由一个副本作为主副本，并行发送数据给其他副本；

• 链式写：几个副本组成一个链 (chain)，并不是等内容都接受到了再往后传播，而是像流一样，边接收上游传递过来的数据，一边传递给下游。

还有一种方式是采用 CAP 中所说的 W+R>N 的方式，比如 3 副本 (N=3) 的情况，W＝2，R＝2，即成功写入 2 个就认为成功，读的时候也要从 2 个副本中读。这种方式通过牺牲一定的读成本，来降低写成本，同时增加写入的可用性。这种方式在分布式文件系统中用地比较少。

2、如何分散副本，以使灾难发生时，不至于所有副本都被损坏？

这主要避免的是某机房或某城市发生自然环境故障的情况，所以有一个副本应该分配地比较远。它的副作用是会带来这个副本的写入性能可能会有一定的下降，因为它离 Client 最远。所以如果在物理条件上无法保证够用的网络带宽的话，则读写副本的策略上需要做一定考虑。

可以参考同步写入只写 2 副本、较远副本异步写入的方式，同时为了保证一致性，读取的时候又要注意一些，避免读取到异步写入副本的过时数据。

3、怎么检测被损坏或数据过期的副本，以及如何处理？

如果有中心节点，则数据节点定期和中心节点进行通信，汇报自己的数据块的相关信息，中心节点将其与自己维护的信息进行对比。如果某个数据块的 checksum 不对，则表明该数据块被损坏了；如果某个数据块的 version 不对，则表明该数据块过期了。

如果没有中心节点，以 ceph 为例，它在自己的节点集群中维护了一个比较小的 monitor 集群，数据节点向这个 monitor 集群汇报自己的情况，由其来判定是否被损坏或过期。

当发现被损坏或过期副本，将它从 meta 信息中移除，再重新创建一份新的副本就好了，移除的副本在随后的回收机制中会被收回。

4、该返回哪个副本给 Client？

这里的策略就比较多了，比如 round-robin、速度最快的节点、成功率最高的节点、CPU 资源最空闲的节点、甚至就固定选第一个作为主节点，也可以选择离自己最近的一个，这样对整体的操作完成时间会有一定节约。

点击关注公众号，Java干货及时送达

六、伸缩性

---

1、存储节点的伸缩

当在集群中加入一台新的存储节点，则它主动向中心节点注册，提供自己的信息，当后续有创建文件或者给已有文件增加数据块的时候，中心节点就可以分配到这台新节点了，比较简单。但有一些问题需要考虑。

• 如何尽量使各存储节点的负载相对均衡?

• 怎样保证新加入的节点，不会因短期负载压力过大而崩塌?

• 如果需要数据迁移，那如何使其对业务层透明?

1）如何尽量使各存储节点的负载相对均衡？

首先要有评价存储节点负载的指标。有多种方式，可以从磁盘空间使用率考虑，也可以从磁盘使用率 +CPU 使用情况 + 网络流量情况等做综合判断。一般来说，磁盘使用率是核心指标。

其次在分配新空间的时候，优先选择资源使用率小的存储节点；而对已存在的存储节点，如果负载已经过载、或者资源使用情况不均衡，则需要做数据迁移。

2）怎样保证新加入的节点，不会因短期负载压力过大而崩塌？

当系统发现当前新加入了一台存储节点，显然它的资源使用率是最低的，那么所有的写流量都路由到这台存储节点来，那就可能造成这台新节点短期负载过大。因此，在资源分配的时候，需要有预热时间，在一个时间段内，缓慢地将写压力路由过来，直到达成新的均衡。

3）如果需要数据迁移，那如何使其对业务层透明?

在有中心节点的情况下，这个工作比较好做，中心节点就包办了——判断哪台存储节点压力较大，判断把哪些文件迁移到何处，更新自己的 meta 信息，迁移过程中的写入怎么办，发生重命名怎么办。无需上层应用来处理。

如果没有中心节点，那代价比较大，在系统的整体设计上，也是要考虑到这种情况，比如ceph，它要采取逻辑位置和物理位置两层结构，对Client暴露的是逻辑层 (pool 和 place group)，这个在迁移过程中是不变的，而下层物理层数据块的移动，只是逻辑层所引用的物理块的地址发生了变化，在Client看来，逻辑块的位置并不会发生改变。

2、中心节点的伸缩

如果有中心节点，还要考虑它的伸缩性。由于中心节点作为控制中心，是主从模式，那么在伸缩性上就受到比较大的限制，是有上限的，不能超过单台物理机的规模。我们可以考虑各种手段，尽量地抬高这个上限。有几种方式可以考虑：

• 以大数据块的形式来存储文件——比如 HDFS 的数据块的大小是 64M，ceph 的的数据块的大小是 4M，都远远超过单机文件系统的 4k。它的意义在于大幅减少 meta data 的数量，使中心节点的单机内存就能够支持足够多的磁盘空间 meta 信息。

• 中心节点采取多级的方式——顶级中心节点只存储目录的 meta data，其指定某目录的文件去哪台次级总控节点去找，然后再通过该次级总控节点找到文件真正的存储节点；

• 中心节点共享存储设备——部署多台中心节点，但它们共享同一个存储外设 / 数据库，meta 信息都放在这里，中心节点自身是无状态的。这种模式下，中心节点的请求处理能力大为增强，但性能会受一定影响。iRODS 就是采用这种方式。

自我介绍一下，小编13年上海交大毕业，曾经在小公司待过，也去过华为、OPPO等大厂，18年进入阿里一直到现在。

深知大多数Java工程师，想要提升技能，往往是自己摸索成长或者是报班学习，但对于培训机构动则几千的学费，着实压力不小。自己不成体系的自学效果低效又漫长，而且极易碰到天花板技术停滞不前！

因此收集整理了一份《2024年Java开发全套学习资料》，初衷也很简单，就是希望能够帮助到想自学提升又不知道该从何学起的朋友，同时减轻大家的负担。

既有适合小白学习的零基础资料，也有适合3年以上经验的小伙伴深入学习提升的进阶课程，基本涵盖了95%以上Java开发知识点，真正体系化！

由于文件比较大，这里只是将部分目录大纲截图出来，每个节点里面都包含大厂面经、学习笔记、源码讲义、实战项目、讲解视频，并且后续会持续更新

如果你觉得这些内容对你有帮助，可以添加V获取：vip1024b （备注Java）

最后

面试前一定少不了刷题，为了方便大家复习，我分享一波个人整理的面试大全宝典

• Java核心知识整理

Java核心知识

• Spring全家桶（实战系列）

• 其他电子书资料

Step3：刷题

既然是要面试，那么就少不了刷题，实际上春节回家后，哪儿也去不了，我自己是刷了不少面试题的，所以在面试过程中才能够做到心中有数，基本上会清楚面试过程中会问到哪些知识点，高频题又有哪些，所以刷题是面试前期准备过程中非常重要的一点。

以下是我私藏的面试题库：

外链图片转存中…(img-5noY962Q-1711815883525)]

Java核心知识

• Spring全家桶（实战系列）

[外链图片转存中…(img-xlbDhzCB-1711815883525)]

• 其他电子书资料

[外链图片转存中…(img-9kmDHkMa-1711815883525)]

Step3：刷题

既然是要面试，那么就少不了刷题，实际上春节回家后，哪儿也去不了，我自己是刷了不少面试题的，所以在面试过程中才能够做到心中有数，基本上会清楚面试过程中会问到哪些知识点，高频题又有哪些，所以刷题是面试前期准备过程中非常重要的一点。

以下是我私藏的面试题库：

[外链图片转存中…(img-0XZ1nNNV-1711815883526)]