分布式存储单主、多主和无中心架构的特征与趋势
分布式对象存储和分布式文件系统具有很强烈的对比性
分布式对象存储是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来管理，这就几乎可以实现无限扩大的元数据存储量！
对于未来的多主架构我也是了解这么多，让我们对分布式存储未来发展能有所了解！
公众号“读字节” 分布式，大数据，软件架构的深度，专业解读
