分布式存储单主架构多主架构和无中心架构的特征与趋势

Posted 2021-04-02 读字节

分布式存储中主要是分布式对象存储和分布式文件系统两个大类具有很强烈的对比性

分布式对象存储以Restful访问方式，几乎处于扁平化存储形式，通过地址作为主键，访问、更新文件对象。文件本身可以分布式化分片，但是key/value的访问都是原子性，文件不能追加数据，亦不能随机访问文件的片段，必须整存整取。几乎互联网大多数的web联机访问资源都适合这种模式，例如：大厂们都云存储OSS。

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

分布式对象存储 PK 分布式文件系统的优劣也很鲜明，前者特别适合海量小文件的快速存和读，因此大多数互联网不太大的照片、文件的云存储都适合分布式对象存储；但对于计算过程管理、大文件随机性读取和追加，就特别适合分布式文件系统了，像Hadoop的大数据批处理计算使用分布式文件系统也是这个原因！

---

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

分布式文件系统的发展，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的了解也是所知有限，只能把知道的一点点讲出来！

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来管理，这就几乎可以实现无限扩大的元数据存储量！

对于未来的多主架构我也是了解这么多，让我们对分布式存储未来发展能有所了解！