分布式存储系统：GFS、HDFS、Ceph的架构设计，数据分片与复制策略
聊到分布式系统，存储永远是绕不开的硬骨头。我这些年跟各种存储系统打交道，从早期的GFS到后来的HDFS，再到Ceph，踩过的坑能写一本小册子。今天咱们就掰开揉碎了聊聊这三个系统的架构设计，以及它们的数据分片与复制策略。
GFS：Google的奠基之作
GFS（Google File System）是2003年发表的论文，说实话，它奠定了现代分布式文件系统的基础。我当时读这篇论文时，最大的感受是：原来大规模存储可以这么玩。
架构设计
GFS采用主从架构。一个Master节点，多个ChunkServer节点。Master负责元数据管理，ChunkServer负责实际数据存储。
这里有个关键点：文件被切分成固定大小的Chunk（默认64MB）。为什么是64MB？不是4KB？我刚开始也觉得奇怪，后来在项目中才明白——大块减少元数据量，降低Master压力。
核心设计理念：
- 组件失效是常态，不是异常
- 文件以大块方式存储
- 追加写入为主，随机写入较少
- 系统与应用协同设计
数据分片策略
GFS的分片其实很简单：文件按固定大小切块，每个Chunk有唯一的64位标识。Master维护文件名到Chunk的映射关系。
我印象很深的是，GFS的Master不存储Chunk位置信息，而是通过心跳从ChunkServer获取。这样做的好处是——避免了元数据不一致。你想想看，如果Master自己维护位置信息，一旦ChunkServer挂了，Master还得去更新，多麻烦。
复制策略
GFS的复制策略是：每个Chunk默认3个副本，分布在不同的机架上。
| 策略项 | 具体实现 |
|---|---|
| 副本数 | 默认3，可配置 |
| 放置策略 | 跨机架分布 |
| 写入流程 | 链式复制（Pipeline） |
| 一致性 | 强一致性（通过租约机制） |
写入时采用链式复制：客户端把数据发给最近的ChunkServer，然后依次传给下一个。我在项目中遇到过一个问题：链式复制虽然简单，但延迟会随着副本数增加而线性增长。所以实际部署时，副本数一般不超过5个。
避坑指南：我曾经在部署GFS时，把副本数设成了5，结果写入延迟直接翻倍。后来改成3，性能就正常了。记住：副本数不是越多越好。
HDFS：GFS的开源实现
HDFS（Hadoop Distributed File System）基本上是GFS的Java实现。但它在细节上做了不少优化。
架构差异
HDFS的架构和GFS类似：NameNode对应Master，DataNode对应ChunkServer。但有几个关键区别：
- 块大小：HDFS默认128MB（早期是64MB）
- 高可用：HDFS有Active/Standby NameNode
- 数据均衡：HDFS内置了Balancer工具
说实话，HDFS的Active/Standby机制是我最喜欢的改进。GFS的Master是单点，挂了就全完了。HDFS通过ZooKeeper实现自动切换，可靠性高了不少。
数据分片策略
HDFS的分片和GFS基本一致。但有个细节值得注意：HDFS支持可插拔的块放置策略。默认是机架感知策略，但你可以自定义。
// 自定义块放置策略示例
public class CustomBlockPlacementPolicy extends BlockPlacementPolicy {
@Override
public DatanodeStorageInfo[] chooseTarget(...) {
// 自定义逻辑
// 比如优先选择CPU利用率低的节点
}
}我在项目中就写过这样的自定义策略。当时是为了把热点数据放在SSD节点上，冷数据放在HDD节点上。效果还不错，读写性能提升了30%。
复制策略
HDFS的复制策略和GFS类似，但多了几个优化：
- 管道写入：和GFS的链式复制一样
- 短路读取：客户端可以直接从本地读取副本
- 纠删码：HDFS 3.0开始支持，替代部分副本
注意：纠删码虽然节省存储空间，但会消耗更多CPU。我建议只在冷数据上使用，热数据还是用副本更靠谱。
Ceph：统一存储的野心
Ceph是我个人最喜欢的分布式存储系统。它不像GFS/HDFS那样只做文件存储，而是同时提供对象、块、文件三种接口。
架构设计
Ceph的架构和GFS完全不同。它没有中心节点，而是采用CRUSH算法实现完全去中心化。
核心组件：
- OSD：负责实际数据存储
- Monitor：维护集群状态
- MDS：管理文件系统元数据（仅文件存储需要）
你想想看，没有Master节点，数据怎么定位？这就是CRUSH算法的厉害之处。客户端根据文件名和CRUSH算法，直接计算出数据在哪个OSD上。
数据分片策略
Ceph的分片单位是PG（Placement Group）。文件先被切成Object，Object再映射到PG，PG最后分布到OSD上。
| 层级 | 说明 |
|---|---|
| File | 用户看到的文件 |
| Object | 固定大小（默认4MB） |
| PG | 逻辑容器，默认100个/OSD |
| OSD | 物理存储节点 |
PG的数量很关键。我记得有一次，我把PG数设得太少，导致数据分布不均匀。后来按照官方建议，每个OSD分配50-100个PG，问题就解决了。
复制策略
Ceph的复制策略比GFS/HDFS灵活得多：
- 副本模式：和GFS类似，默认3副本
- 纠删码模式：类似RAID 5/6，节省空间
- 缓存分层：SSD做缓存，HDD做存储
Ceph的写入流程很有意思。客户端直接和主OSD通信，主OSD负责协调副本写入。这和GFS的链式复制不同，延迟更低。
个人经验：我在生产环境部署Ceph时，发现纠删码模式虽然节省了40%的存储空间，但写入性能下降了50%。所以我的建议是：热数据用副本，冷数据用纠删码。
三种系统的对比
| 特性 | GFS | HDFS | Ceph |
|---|---|---|---|
| 架构 | 主从 | 主从（HA） | 去中心化 |
| 分片单位 | Chunk（64MB） | Block（128MB） | Object（4MB） |
| 复制方式 | 链式 | 管道 | 主从协调 |
| 一致性 | 强 | 强 | 强（最终） |
| 适用场景 | 大文件 | 大数据分析 | 统一存储 |
说实话，没有完美的系统。GFS/HDFS适合大文件、顺序读写场景。Ceph则更灵活，但复杂度也更高。
选型建议：如果你做大数据分析，选HDFS准没错。如果你需要同时支持块、文件、对象存储，Ceph是更好的选择。至于GFS，嗯，你基本用不到，除非你在Google工作。
最后说一句：分布式存储的设计，本质上是在一致性、可用性、分区容错性之间做权衡。GFS选择了强一致性和高可用，Ceph选择了高可用和分区容错。没有标准答案，只有最适合你场景的方案。