首页 技术设计 分布式

# 前言



从 2003 年 Google 公布自家分布式文件系统相关技术（论文 The Google File System）后，便涌现出众多的开源实现，包括 HDFS、Quantcast File System（QFS）、MooseFS 等，都采用了类似 GFS 分块的架构，但确有各自的不同特性，如 HDFS 发展最快，但只支持 append-only 写，不支持随机写，而 QFS 以支持 erasure coding 为主要特性，从而性价比最高，MooseFS 其支持随机写特性最好，则在今年进入了快速发展时期，一年内十几个版本发布，企业版的多 Master 方案更使得其可用性大大提高。

2006 年 Sage A. Weil 设计的 CEPH 提出了无中心化的架构，其通过 CRUSH 算法而不是 Master 来找到数据，其可用性更高。此外，Glusterfs 采用弹性哈希解除了对元数据服务器的需求，消除了单点故障和性能瓶颈。

2014 年提出的 RAMCloud 更是激进的提出了全内存的存储架构。

此外，FaceBook 提出了 Haystack 架构来应对大量的小文件存储，提出 f4 来解决温数据的问题。Microsoft 提出了 Pelican 来解决大量冷数据存储问题。

下面我举几个架构师设计的时候遇到的问题，他们是如何解决的呢？

  1. 异构存储（磁盘、SSD、内存）以及冷温热数据存储架构如何设计？比如数据热度由热到温最后到冷，对应的存储如何自适应的将数据转换和保存？
    冷数据存入机械 SATA 盘，热数据存入 SSD + 内存，如果是非重要的热数据，直接存入内存，比如 Cache，如果是重要的热数据，可存入 SSD，如果对性能要求并不是很高，可以考虑存入 SATA，新写入的数据可以存入 SSD 或者内存，如果热度很低，可以切换至存储到 SATA，不重要的基本上可以直接删掉，根据业务场景设计，不同的业务的需求也不同。

  2. 有的应用读写并发并不大，而对元数据的操作确异常频繁，如何设计一个以读为主的元数据服务架构或者设计一个以写为主的元数据服务架构？
    读写并发不大，对元数据操作频繁这种一般很有可能是小文件，开销主要用在对元数据操作部分了，根据场景不同设计的也不同，一般都是元数据集群，元数据存储在 SSD + 内存做元数据 Cache，跟设计的算法也有关系。

  3. 当前无论是 CEPH 还是 GFS，都存在 IO 路径过长的问题，有什么方法能缓解这种情况？
    Ceph 的性能还不错， GFS 没有用过，不过 Ceph 使用 API 方式性能还不错，但是稳定性确实不太好说，目前我没遇到问题，但是也没商用过，因为我不太喜欢 API 方式，一般还是 Posix 接口操作，方便，直接 mount 就当本地盘使用了。

  4. 使用分布式文件系统后，如何快速的检索数据？
    最快的方式当然还是 Hash 表，O (1), 也有其他的方式应该，只不过我没有用过，因为我还是比较喜欢 Gluster 这种 Hash 计算文件存储位置的方式，加上一直以来都是做大文件，所以这个并不是太大的问题。

  5. 云存储的数据分享、隔离和安全性怎么做？
    这个主要还是在应用层去做，直接从业务部分去划分好些，如果必须在文件系统层做，可以增加 ACL ，或者根据 UID 进行权限控制，因为 GNU/Linux 本身就有相关的控制设计了