GluserFS笔记

一、基础概述

1. 定义：GFS（Google File System）是Google于2003年发布的分布式文件系统，专为海量数据存储、高吞吐量场景设计，是现代分布式存储的核心原型。

2. 核心定位：面向大数据批处理，放弃部分POSIX标准，优先保证高吞吐、高可靠，而非低延迟随机访问。

3. 地位：Google三驾马车（GFS、MapReduce、Bigtable）之一，直接启发开源HDFS（Hadoop分布式文件系统），奠定大数据存储基础。

4. 适用硬件：基于廉价普通服务器，通过软件容错替代昂贵硬件冗余，降低成本。

二、核心架构（3大角色，控制流与数据流分离）

1. Master（主节点）------ 大脑，仅管元数据

• 核心职责：管理元数据（文件命名空间、文件与Chunk的映射关系、副本位置、访问权限），不存储实际数据。

• 部署模式：默认1个活跃Master + 1个影子Master（热备），避免单点故障。

• 元数据持久化：通过操作日志（Operation Log）+ 检查点（Checkpoint）保存，影子Master实时同步日志，故障时快速切换。

2. ChunkServer（数据节点）------ 仓库，存储实际数据

• 核心职责：存储文件被拆分后的实际数据块（Chunk）。

• Chunk规格：固定64MB（远大于普通文件系统块），目的是减少元数据量、降低Client与Master的交互频率，提升大文件读写效率。

• 副本机制：每个Chunk默认3个副本，分布在不同ChunkServer（跨机架部署），保障数据可靠性，节点故障时可自动恢复。

3. Client（客户端）------ 接口，连接应用与系统

• 访问流程：① 向Master请求元数据（获取Chunk位置）；② 直接与ChunkServer进行数据读写（数据流不经过Master）；③ 缓存元数据，减少重复请求Master。

• 交互特点：仅与Master交互元数据，不涉及实际数据传输，降低Master压力。

三、核心技术机制（重点）

1. 数据分块机制（64MB Chunk）

核心优势：减少元数据体积（Master只需管理少量Chunk信息，无需记录具体文件内容）；提升大文件顺序读写效率，适配大数据批处理场景。

2. 多副本容错机制

默认3副本，跨机架存放（避免单机架故障导致数据丢失）；ChunkServer定期向Master汇报心跳和Chunk状态，Master检测到副本缺失时，自动触发副本复制补充。

3. 租约（Lease）机制------ 保证写入一致性

Master为某个Chunk的一个副本授予"租约"（设定有效期），该副本成为"主副本"；所有写入操作先提交到主副本，主副本统一协调写入顺序，再同步到其他副本，避免并发写入导致的数据不一致。

4. 高效追加写（Append）

GFS优化大量并发追加操作，而非随机修改；文件写入后很少改动，适配日志、爬虫数据、搜索引擎索引等场景；支持"原子追加"，即使多个Client并发追加，也能保证数据完整性。

四、核心特点（优缺点）

优点

• 高可靠：多副本+软件容错，节点故障不影响数据可用性。

• 高吞吐：适配PB级数据、数千节点扩展，大文件顺序读写效率极高。

• 低成本：基于普通硬件，无需昂贵的高可用设备。

• 易扩展：横向扩展ChunkServer即可提升存储容量和吞吐量。

缺点

• Master单点瓶颈：虽有影子Master热备，但仍存在单点故障风险（后续优化可采用Master集群）。

• 延迟较高：不适合低延迟、小文件随机读写场景（小文件会导致元数据占比过高，频繁与Master交互）。

• 非POSIX接口：接口不通用，应用需适配GFS客户端库才能访问。

五、适用场景与不适用场景

适用场景

日志存储、搜索引擎索引、大数据离线分析（MapReduce任务）、大规模文件备份、视频/音频等大文件存储。

不适用场景

低延迟应用（如实时查询）、小文件密集型场景、需要随机修改文件的场景（如数据库）。

六、关键对比与记忆点

• GFS vs HDFS：HDFS是GFS的开源实现，核心架构（Master/NameNode、ChunkServer/DataNode、Client）一致，差异在于HDFS块大小默认128MB，Master容错机制更完善。

• 核心记忆：3角色（Master/ChunkServer/Client）、1块大小（64MB）、1副本数（默认3）、1核心机制（租约）、1核心场景（大文件高吞吐）。