分布式对象存储和分布式文件系统具备很强烈的对比性

分布式对象存储是 key/value 的存储模式，以 restful 拜访形式为主，简直处于扁平化的存储模式，通过地址作为主键，拜访、更新的文件对象作为值。文件自身能够分布式分片，然而 key/value 的拜访都是原子性，文件不能追加数据，亦不能随机拜访文件的片段，必须整存整取。简直大多数的互联网 web 资源拜访都适宜这种模式，例如：大厂们都云存储 OSS。

分布式文件系统不同于对象存储，构造上是目录资源管理的树形档次，次要是以模仿或连贯 Unix/Linux 文件系统为主，分布式文件系统就特地适宜在文件块追加数据，或者在文件块中随机找到偏移量，读取一小段数据。

分布式对象存储 PK 分布式文件系统的优劣也很显明，前者特地适宜海量小文件的疾速存与读，因而大多数互联网不太大的照片、文件资源存储都适宜分布式对象存储系统；但对于大数据计算过程治理、大文件随机读取和追加，就特地适宜分布式文件系统了，像 Hadoop 的批处理计算底层应用分布式文件系统（HDFS）也是这个起因！

好了，先赘述了一些概念！那么直入主题：

分布式文件系统的倒退，master/slave 架构占了很大一部分，例如 hdfs,zookeeper 这些 hadoop 生态圈的工具，基本上是主从架构的. 而以 glusterfs 为代表的无核心架构也在逐步倒退，然而想理解的是，将来会呈现多主架构，还是会应用 glusterfs 这种无核心架构呢？因为单节点的利用当初越来越成为一个瓶颈了，又或者说，还是有其余的代替计划呢？

对于 Master/Slave 的集中式架构细究起来也分为不同的模式

（一）协调治理方面：

主备式： 例如 HDFS 的 namenode 就是管理者一主一备，主坏，备上；

选举式： 管理者是被多个备选推举的，例如 Elasticsearch，zookeeper 的主节点选举。

分布式数据库有治理节点负责调度和治理数据节点，也有数据节点负责数据读写。

（二）数据方面：

数据集中式治理： 例如：HDFS 的 namenode 治理着具备残缺语义的元数据树形构造，那么就能对数据块读写的节点进行集中调配，指哪打哪！

数据非集中式治理： 例如：Elasticsearch 等很多分布式存储的数据分片机制应用 Hash 分片存储拜访，不必主节点来集中调配，这样主节点就不简单，只有依照约定协调好不同节点的工作工作就能够了，然而若一个节点挂了，整个集群的数据都要再调配一次！

再看看对等式架构：

不同于 master/slave 集中式架构，有一个主节点协调所有从节点，对等式架构集群中每个节点都是平等的，例如：glusterfs 就是典型的对等式架构，通过 Hash 算法来确定谁在当下的一次申请中作为喽罗，主导其余多个节点的数据处理。

其实无论是一个核心的主从式，还是无核心的对等式，都存在显著的硬伤：

资源管理方面比照： 例如：HDFS 的 namenode 元数据是用树形治理，具备残缺语义的文件资源管理零碎，想晓得哪个节点的状态，解决那个节点的数据，就非常容易；

恰好是无核心架构是万万都做不到的事件，对数据进行一次治理，就要整个集群的各个节点从头走一遍，很耗费资源，因而很难见到大多数的无核心存储架构对外随便反对数据迁徙，要命呢！

可靠性方面比照： 一个核心的主从式架构要是主挂了，尽管有备的能够顶上来，然而这个过程不是设想中那么牢靠，首先主备切换有中断工夫，其次有时候会呈现所谓的脑裂，而且备的再挂掉，整个集群就 game over 了；

无核心的问题在于每个节点都很独立很自治，这就存在信息通畅问题，一个节点的状态或配置信息变动了，整个集群获取变动的过程会很慢，这就无奈做到分布式一致性了。

扩展性方面比照： 主从式的另外一个瓶颈来自主节点的资源耗费问题，内存是无限的，元数据管理的文件数量是有限度的，HDFS 又是这一问题的带头大哥，它适宜反对较大文件，若太多的小文件会导致内存中的元数据树太大而内存溢出，当然了存储文件特地宏大也会呈现内存瓶颈；另外反对的元数据文件也是有 Linux 的最大文件数限度的，对于像 Google 这种治理着超级大数据业务的企业或机构当然肯定要思考这个事件。

恰好无核心的架构就不存在主的瓶颈问题，能够实现线性的扩张。但无主也好，单主也好，只有应用 hash 进行约定式的节点数据调配，都存在 hash 可能导致的数据歪斜问题，歪斜问题就会带来某一个数据节点的若大压力，因而数据管理员须要时时关注这一问题。

从将来分布式存储的倒退看，多主架构的呈现是肯定的

多主架构的实现不仅齐全解决了单主的瓶颈问题之外，还避免了无核心架构的所有毛病，当然这种架构从分布式存储的将来说必定是最好的一种抉择了！要害是到底有没有这种架构呢？

目前只能说又是 Google 了！Colossus File System 理解一下，GFS 的下一代的继任者，能够说是 GFS 2.0 版本吧！

我对 Golossus 的理解也是所知无限，Google 对这方面的细节也尚未公诸于众，我也只能把晓得的一点点进行脑补再讲进去：

Colossus File System 是通过 key/value 代替树形构造实现元数据存储和治理，那么 Colossus 就能够实现多个主节点了！所谓的分布式元数据管理。关键点在于——将原来元数据残缺语义的树形构造转换成为残缺语义的键值存储构造，同时还保障操作的原子性。

最牛逼的是它的架构：Colossus 的 key/value 是基于 BigTable，而 BigTable 必须基于 GFS，然而 Colossus 又是 GFS 的降级革新！

咱们再翻译成开源的 Hadoop 来了解：HDFS2 的 namenode 对元数据的治理基于 HBase，HBase 基于 HDFS，然而 HDFS2 又是 HDFS 的降级革新！

是不是曾经绕进去了！咱们用一张图来体现其逻辑，当然这张图也只是脑补图！

Colossus File System 的 Master Server 须要治理所有的数据节点 D Server（相似 GFS 的 ChunkServer），治理的元数据都存储在 BigTable 上，而 BigTable 的基础设施是一个微型的 GFS，它才是元数据（Metadata）的真正存储地点（Metadata ChunkServer）。就如同氢弹得通过原子弹来驱动一个情理！

那么 GFS 中 Master Server 的元数据树，就只是治理打包好的元数据文件块了，这个文件量就真不大了！而真正的元数据都是由它的下层 BigTable 应用 key/value 来治理，这就简直能够实现有限扩充的元数据存储量！

对于将来的多主架构我也是理解这么多，让咱们对分布式存储将来倒退能有所理解！

[返回读字节的知乎——理解更多对于大数据的常识 (https://www.zhihu.com/people/…])

公众号“读字节”分布式，大数据，软件架构的深度，业余解读