3、分布式存储基础：分布式系统概念、数据分布、一致性模型

在深入 GPU 集群存储架构之前，必须先厘清分布式存储的三大基石：分布式系统的基本运行规则、数据如何在多节点间布局、以及系统如何向外部承诺数据的一致性。这三者决定了存储系统的扩展上限、故障恢复能力以及上层应用（如模型训练、检查点保存）的语义正确性。

3.1 分布式系统的核心概念与失效模型

分布式存储系统是由多个自治节点通过网络互联、协同对外提供存储服务的系统。与单机存储不同，它必须面对三个基本现实：部分失效、不可靠网络和时钟漂移。

节点失效：任何节点都可能随时崩溃（宕机、断电、进程被杀）。系统必须假设“节点故障是常态”，而非异常。
网络分区：网络可能丢包、延迟抖动，甚至发生脑裂（节点间完全无法通信但各自存活）。
时钟不一致：不同节点的本地时钟无法做到绝对同步，依赖时间戳排序的操作可能产生歧义。

工程上，我们通常用 失效模型 来界定系统能容忍的故障类型。对于 GPU 集群存储，最常见的假设是 崩溃-停止（Crash-stop）模型：节点要么正常工作，要么停止响应，不会发送错误信息。但实际中，网络分区（Partition）是必须考虑的，因此系统设计往往遵循 CAP 定理 的约束，在一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）之间做出权衡。

工程提示：在 GPU 集群中，存储节点通常采用 InfiniBand 或 RoCE 高速网络。虽然网络质量高，但分区仍可能由交换机故障、链路抖动引发。设计存储系统时，必须显式处理“分区恢复后的数据合并”问题，而不是假设网络永远可靠。

3.2 数据分布策略：从哈希到一致性哈希

数据分布解决的是“数据放在哪个节点上”的问题。GPU 集群存储的数据量通常在 PB 级，单节点无法承载，必须将数据切分成固定大小的 数据块（Chunk/Extent） 并分散到多个存储节点。

最朴素的方法是 取模哈希：node_id = hash(object_name) % N。这种方法实现简单，但一旦节点数 N 变化（扩缩容），几乎所有数据的映射关系都会改变，导致大规模数据迁移。

业界标准方案是 一致性哈希（Consistent Hashing）。它将哈希值空间组织成一个环（Ring），每个节点根据其 IP 或 ID 哈希后放置在环上；每个数据对象哈希后沿环顺时针找到的第一个节点即为存储位置。当节点增减时，仅影响该节点在环上逆时针方向相邻的一小段数据，迁移量大幅降低。

然而，一致性哈希存在数据倾斜问题（节点在环上分布不均）。为此，引入 虚拟节点（Virtual Node） 概念：每个物理节点在环上拥有多个虚拟位置，使数据分布更均匀。下表对比了两种策略在 GPU 集群场景下的表现：

策略	扩缩容迁移量	数据均匀性	GPU 集群适用性
取模哈希	几乎全部数据	均匀（依赖哈希函数）	不适用，节点变更频繁
一致性哈希（无虚拟节点）	约 1/N 的数据	可能倾斜	可用，但需配合负载均衡
一致性哈希（带虚拟节点）	约 1/N 的数据	良好	推荐，兼顾迁移与均衡

此外，还需考虑 数据局部性。GPU 训练任务常需要连续读取大文件（如检查点），因此存储系统通常将大文件切分为顺序编号的 Chunk，并尽量将连续 Chunk 分布在不同的节点上，以支持并行读取。

3.3 一致性模型：从强一致到最终一致

一致性模型定义了多副本之间数据更新的可见性规则。GPU 集群存储中，副本是保证数据不丢失和提供高并发读的关键，但副本间的同步策略直接决定了系统性能与语义。

3.3.1 强一致性（Linearizability）

写操作完成后，任何后续读操作（无论访问哪个副本）都能读到最新值。实现通常依赖 同步复制（写所有副本成功后才返回）或 Raft/Paxos 等共识算法。代价是写延迟高（需等待最慢副本确认），在跨机柜场景下尤为明显。

3.3.2 最终一致性（Eventual Consistency）

写操作只需写入主副本或少数副本即可返回，后台异步同步至其他副本。系统保证“如果停止写入，最终所有副本会收敛到一致状态”。这种模型写性能高，但读操作可能读到旧数据（Stale Read）。

3.3.3 因果一致性（Causal Consistency）

介于强一致与最终一致之间。它保证有因果关系的操作（如“先写 A 再写 B”）对所有副本按相同顺序可见，但无因果关系的并发操作可以乱序。对于分布式文件系统的元数据操作（如“创建目录”和“写入文件”），因果一致性是常用折中。

在 GPU 集群存储中，元数据服务（管理文件目录、权限、Chunk 位置）通常采用强一致性（Raft 组），而 数据面（实际文件内容）则根据应用需求选择。例如，训练框架保存检查点时，必须保证“写入完成”标志可见后，才能安全地认为检查点有效，此时需要强一致；而日志类数据则可采用最终一致。

3.4 案例：基于 Raft 的元数据集群与数据分片

以一个典型的 GPU 集群存储系统（类似 Ceph 或 JuiceFS 的架构）为例，其数据分布与一致性设计如下：

元数据集群：由 3 或 5 个节点组成 Raft 组，负责维护文件系统树、文件到 Chunk 的映射表。所有元数据更新（创建、删除、重命名）必须经过 Raft 日志复制，保证强一致。
数据分片：文件被切分为 64MB 的 Chunk，每个 Chunk 根据其 ID 通过一致性哈希映射到一组数据节点（如 3 个副本）。
写入流程：客户端向主副本（Primary）发起写请求，主副本并行写入自身和从副本（Secondary），等待所有副本确认后返回成功。若主副本故障，Raft 组会选举新的主副本。
故障恢复：当某个数据节点掉线，其上的 Chunk 副本数低于目标值，后台线程会从其他副本复制数据到新节点，恢复副本数。

以下是一个简化的写入时序描述（非代码，仅示意）：

客户端 → 元数据节点: 查询 Chunk 位置 (强一致读)
元数据节点 → 客户端: 返回主副本地址 (10.0.0.1:9000)
客户端 → 主副本: 写入数据块 (带版本号)
主副本 → 从副本1: 同步写入
主副本 → 从副本2: 同步写入
从副本1/2 → 主副本: ACK
主副本 → 客户端: 写入成功 (所有副本已持久化)

3.5 常见误区与设计复盘

误区一：盲目追求强一致性。 在 GPU 集群中，若所有数据面操作都采用同步复制，写延迟会因网络往返而显著增加，拖慢训练迭代。正确做法是区分元数据与数据：元数据用强一致，数据块写入可配置为“写主副本+异步复制”，并依赖上层应用（如检查点协议）保证最终正确性。

误区二：忽略哈希倾斜。 即使使用一致性哈希，若节点性能异构（如不同代际的 SSD 节点），虚拟节点数量应与其容量成正比。否则，高性能节点负载不足，低性能节点成为瓶颈。

复盘：在某次实际部署中，我们发现训练任务频繁报“文件不存在”错误。排查后发现，元数据集群采用最终一致模型，导致客户端在创建文件后立即读取 Chunk 映射时，访问到了尚未同步的旧元数据副本。修复方案是将元数据读取路径改为 线性一致读（通过 Raft 的 ReadIndex 或 Lease 机制），确保读到最新状态。这一案例说明：一致性模型的选择必须与访问路径的语义严格匹配，不能仅凭性能偏好随意设定。