一、盘古存储系统的战略定位与技术演进

盘古（Pangu）是阿里云飞天操作系统中的核心存储底座，也是整个阿里云体系里最关键的基础设施之一。很多人理解阿里云时，往往会先想到 ECS、OSS、数据库、CDN、AI 平台这些上层产品，但实际上这些云服务背后真正负责“数据落地”的核心，就是盘古存储系统。它承担的不仅仅是“存文件”这么简单，而是整个阿里云数百万服务器、海量数据中心、万亿级对象规模背后的统一数据基础设施。

如果把神龙看作阿里云的计算内核，把洛神看作云网络核心，那么盘古就是整个阿里云的数据生命线。

盘古最初诞生于阿里集团“去 IOE”时期。当年淘宝、支付宝业务高速增长，传统高端存储设备已经无法满足阿里对于规模、成本、扩展性以及可靠性的要求。阿里云最终选择完全自研分布式存储体系，希望在普通 X86 服务器之上，实现类似 EMC、NetApp、IBM 小型机级别的高可靠存储能力。

盘古最早采用的是典型的 Client-Master-ChunkServer 架构，核心思想与 Google GFS 有相似之处，但随着阿里业务规模爆炸式增长，传统中心化元数据管理已经无法支撑数十万节点规模，因此盘古开始进入全面分布式演进阶段。

从盘古 1.0 到盘古 2.0，整个架构发生了非常大的变化。

早期盘古主要依赖三副本机制保证可靠性，虽然性能高，但存储成本极大。随着阿里云规模进入 EB 时代，仅靠副本已经无法控制成本，因此盘古开始大量引入纠删码（EC）机制，并且针对不同数据冷热程度动态切换编码策略。

传统云厂商很多只做 Reed-Solomon EC，但盘古进一步做了：

LRC 局部恢复、智能调度、热冷数据分层、动态 EC 切换、跨机架容错域优化、恢复流量削峰、在线无感迁移、冷热混合编码等大量深度优化，使其不仅降低了存储冗余成本，还大幅提升了故障恢复速度。尤其是在单节点故障场景下，LRC 可以只恢复局部数据块，而不是像传统 RS 那样全量重建，大幅减少网络带宽消耗与恢复时间。

随着阿里云全面进入云原生时代，盘古也不再只是“存储系统”，而是逐渐演化为统一数据平台。现在的盘古已经同时支撑：

• 块存储 EBS
• 对象存储 OSS
• 文件存储 NAS
• 表格存储 TableStore
• MaxCompute 大数据平台
• PolarDB
• 云原生 Kubernetes 持久卷
• AI 训练数据集
• 湖仓一体架构

这意味着盘古并不是一个单纯的分布式文件系统，而是整个阿里云数据基础设施的统一底层。

目前盘古单集群已经可以支持十万台服务器级别扩展，整体部署规模达到 EB 级，文件数量达到万亿级别，数据可靠性达到 12 个 9（99.9999999999%），远高于传统企业级存储系统。

更重要的是，盘古不是单纯的软件系统，而是深度软硬一体化架构。

它与阿里云自研的：

• 神龙虚拟化
• CIPU
• 洛神网络
• RDMA
• SmartNIC
• NVMe ZNS SSD
• SPDK 用户态 IO
• 自研 SSD 控制器

进行了深度融合。

尤其是在 RDMA 与 NVMe over Fabrics 引入后，盘古存储延迟已经从毫秒级进入微秒级时代。

目前盘古 4KB 随机读 P99 延迟已经能够做到 80 微秒左右，而传统企业级分布式存储很多仍然停留在 300~800 微秒区间。

IOPS 更是达到 300 万级别。

这意味着现在的盘古已经不仅仅是“大容量存储”，而是真正进入高性能云原生存储时代。

---

二、盘古 2.0 架构深度解析

盘古 2.0 最大的变化，其实是“去中心化”。

早期分布式存储很多都存在中心节点瓶颈，例如：

• NameNode
• Metadata Master
• Controller
• Central Scheduler

一旦元数据规模达到一定程度，就会出现：

• 热点
• 锁竞争
• 扩展困难
• 跨地域同步问题
• 主节点故障风险

因此盘古 2.0 最大升级之一，就是全面分布式元数据管理。

盘古将 Volume 作为逻辑管理单元，每个 Volume 对应不同元数据分区，再通过一致性哈希、Raft、多副本日志同步实现水平扩展。

整个 MetaServer 不再是单点，而是一个完全分布式元数据集群。

每个 Volume 会动态映射到不同 MetaServer 节点：

• 自动负载均衡
• 自动故障切换
• 自动迁移
• 自动扩缩容

从而避免传统中心化元数据瓶颈。

在数据层，盘古采用 ChunkServer 管理实际数据块。

每个 Chunk 默认 64MB 左右。

数据写入时并不是简单“落盘”，而是经过：

• WAL 日志
• 校验和验证
• 多副本同步
• Quorum 提交
• Lease 主副本确认
• 异步刷盘
• 后台压缩
• EC 编码

等完整链路。

尤其是主副本 Lease 机制，是盘古高性能写入的重要关键。

只有拥有 Lease 的 Primary Replica 才允许执行写入操作，其余副本负责同步，从而避免传统强一致分布式存储里的大量锁竞争。

与此同时，盘古还做了大量数据路径优化。

例如：

• 零拷贝 IO
• 用户态存储栈
• RDMA 直通
• SPDK 加速
• Batch Commit
• Pipeline Replication
• 多队列 NVMe 并行

这些优化本质上都是为了减少：

• CPU 上下文切换
• Kernel Trap
• Buffer Copy
• 网络中断
• IO Wait

因为在超大规模分布式存储里，真正的瓶颈很多时候不是磁盘，而是 CPU 与网络。

尤其是在 AI 训练场景下，GPU 集群对数据吞吐要求极高。

如果存储无法提供稳定高带宽，GPU 很容易空转。

因此盘古后来进一步引入：

• RDMA 网络
• RoCE
• NVMe-oF
• GPU Direct Storage

来降低训练数据读取延迟。

目前很多阿里云 AI 集群，其实已经实现：

GPU → RDMA → NVMe

的近直通数据链路。

这也是为什么现在 AI 对存储系统要求越来越高。

因为 AI 时代真正的问题已经不是“算力够不够”，而是：

“数据喂不喂得进去”。

---

三、盘古的核心技术突破

盘古真正厉害的地方，其实不只是“规模大”，而是它在超大规模下还能保持：

• 高一致性
• 高可靠性
• 高性能
• 高扩展性

这背后其实涉及大量底层算法优化。

例如在一致性协议层面，盘古没有直接照搬传统 Paxos，而是做了大量 Multi-Paxos 深度优化。

包括：

• Batch Propose
• Pipeline Replication
• Lease Fast Path
• Fast Quorum
• Parallel Accept
• Latency-aware Replica Selection

这些优化本质上都是为了降低网络 RTT。

因为传统 Paxos 最大问题就是：

“消息太多”。

而盘古通过租约机制，在 Lease 有效期间可以跳过 Prepare 阶段，直接进入 Accept 阶段，大幅减少网络往返。

与此同时，盘古还会根据节点 RTT 动态选择最快副本组成 Fast Quorum。

这意味着：

不同副本并不是“地位平等”的。

系统会优先选择低延迟节点参与快速提交。

这也是盘古微秒级延迟的重要原因之一。

另外一个非常关键的技术，就是动态纠删码。

很多传统存储系统的 EC 策略是固定的。

写进去是什么编码，后面一直都不变。

但盘古会根据：

• 访问频率
• 生命周期
• 数据大小
• 热度变化
• 业务类型

动态切换 EC 策略。

例如：

热点数据可能采用：

• 三副本
• LRC

因为恢复速度快。

温数据可能采用：

• RS(10,4)

平衡成本与可靠性。

冷数据则可能采用：

• ZK-16-3
• 高密度 EC

最大化存储效率。

并且整个切换过程是：

在线
动态
无感知

的。

这其实是非常难的。

因为 EC 切换意味着数据重编码。

而重编码本身会带来：

• 网络压力
• CPU 压力
• IO 压力

因此盘古内部还有专门的数据迁移调度系统。

会动态分析：

• 网络利用率
• 机器负载
• 数据冷热
• 故障概率
• 磁盘健康度

再决定什么时候迁移。

这已经不只是传统存储，而更像一个大型“智能数据操作系统”。

---

四、12 个 9 的可靠性体系

很多人会疑惑：

为什么盘古能做到 12 个 9？

其实这背后并不是靠单一技术，而是多层保护机制叠加。

盘古的数据保护体系包括：

• 数据校验
• 多副本
• 纠删码
• 跨机架容灾
• 跨数据中心复制
• 静默错误检测
• 后台 Scrub
• 自动修复
• 实时快照
• 异地备份
• 主动故障预测

例如磁盘坏道并不一定会立刻报错。

有些属于 Silent Data Corruption。

也就是：

“数据坏了，但系统不知道”。

因此盘古会定期后台扫描所有 Chunk：

• 校验 CRC
• 对比 Checksum
• 检查 Metadata
• 验证 EC Block

发现异常后自动修复。

同时，盘古还有 AI 驱动的故障预测系统。

它会分析：

• SMART 信息
• IO 延迟
• ECC 错误
• 温度
• 电源波动
• 网络异常

提前预测硬盘故障概率。

很多时候磁盘还没真正坏掉，系统已经提前完成数据迁移。

这也是大规模云存储和普通企业 NAS 最大区别之一。

传统企业存储很多是：

“坏了再修”。

而盘古属于：

“预测后提前修”。

另外，在跨地域容灾层面，盘古支持：

• 同城双活
• 两地三中心
• 异地多活

即使整个机房故障，也不会影响数据可用性。

对于金融、支付、电商核心业务来说，这是必须的。

因为淘宝、支付宝这种业务，本质上不允许真正意义上的“停机”。

---

五、盘古背后的真正意义

很多人会觉得：

“存储系统不就是硬盘堆起来吗？”

但实际上，现代超大规模分布式存储，已经是全球最复杂的软件工程之一。

因为它需要同时解决：

• 网络问题
• 一致性问题
• IO 问题
• 调度问题
• 硬件故障问题
• 多租户隔离问题
• 成本控制问题
• 扩展性问题
• 数据安全问题

而盘古最厉害的地方在于：

它不是实验室系统。

而是真正长期支撑：

• 双11
• 支付宝
• 淘宝
• 阿里国际站
• AI 大模型训练
• 云数据库
• 全球 OSS

这种超高并发场景。

并且经历了十几年生产环境验证。

从某种意义上说，盘古其实已经不是“阿里云的存储系统”。

而是一套中国超大规模云计算基础设施能力的体现。

它代表的是：

中国已经具备从底层存储、芯片、网络、虚拟化到云操作系统的全栈自研能力。

而随着 AI、大模型、云原生、湖仓一体进一步发展，未来盘古还会继续向：

• 存算分离
• AI 原生存储
• GPU 高吞吐数据链路
• 智能数据调度
• 全闪存数据中心
• 一云多芯异构支持

方向继续演进。

下一代云竞争，拼的已经不只是“服务器数量”。

而是谁能真正掌控：

数据。