分布式对象存储是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这种管理着超级大数据业务的企业或机构当然一定要考虑这个事情。