AWS S3 如何用"过时"的机械硬盘跑出每秒 1PB
S3 存着 400 万亿对象、每秒处理 1.5 亿请求、峰值吞吐超 1PB——而它的主力存储介质是机械硬盘。本文拆解 S3 的多层架构：为何选 HDD、日志式顺序写、纠删码并行读、Power of Two Choices 负载均衡与工作负载去相关。
S3 堪称现代互联网的地基。以它的性能表现，多数人以为底层全是顶级 SSD——真相恰恰相反：S3 至今主要建在"又慢又老"的机械硬盘（HDD）上。支撑这个反差的是一套多层软件架构，把 HDD 的短板硬生生转化成了规模优势。
先看规模
- 400 万亿+对象：从小日志到视频归档，个个要持久可访问；
- 每秒 1.5 亿请求：GET/PUT/LIST/DELETE 不间断地打向全球；
- 峰值吞吐 1PB+/秒：约等于每秒读出一百万 GB；
- 数千万块硬盘：构成这一切的物理底座。
这不再是"存储服务"，而是行星尺度的分布式系统。
反直觉的选择：为什么是 HDD
**一个字：钱。**2023 年 HDD 每 TB 约 11 美元，SSD 约 26 美元——同容量贵一倍不止。买几千万块盘的体量下，这个差价是天文数字，也是 S3 价格竞争力的地基。
代价是物理性能：HDD 读写靠机械臂寻道 + 盘片旋转，一次随机访问 = 寻道（最高 25ms）+ 旋转等待（最高 8.3ms）+ 传输（0.5MB 约 2.5ms），单盘 IOPS 只有约 120。怎么破？
第一招：日志式顺序写，扬长避短
HDD 的死穴是随机访问，强项是顺序访问——磁头就位后盘片自然旋转，数据连续流出，接近满速传输。
S3 把存储介质当成一个 Log（追加式有序日志）：新数据永远追加到末尾，纯顺序操作，不找空位、不原地覆盖。写入因此能跑满 HDD 的极限速度。这套思路和 Apache Kafka 的基石数据结构如出一辙。写入问题就此解决，真正的难题在读。
第二招：大规模并行 + 纠删码，破解随机读
单盘随机读平均延迟约 16ms，峰值读速约 32MB/s。要到 1PB/s，差距是 3000 万倍——出路不是让单盘更快，而是让海量盘同时干活。
并行分片：大对象被切成许多块，散布到数千块硬盘上。读取时向所有持有分片的盘并发发起读，数据同时流回再拼装——总吞吐 = 所有参与盘的速度之和。
**纠删码（Erasure Coding）**让分片既快又可靠：
- 对象拆成 k 个数据分片，再用数学函数（如 Reed-Solomon）生成 m 个校验分片；
- k+m 个分片存到不同物理盘；
- 任意 k 个分片即可还原完整对象。
S3 典型配置 5-of-9：5 数据 + 4 校验共 9 片存 9 块盘。两个红利：
- 性能：读请求由响应最快的 5 块盘满足，个别慢盘/忙盘不拖后腿；
- 可靠性：容忍 4 块盘同时故障仍完整还原——这就是 S3 "11 个 9"（99.999999999%）持久性的来源。
第三招：驯服热点分区
数据散布到百万级磁盘后，新问题来了：某些盘被打爆（热点分区），级联拖累全系统。S3 用三层策略化解：
1. 二选一随机放置（Power of Two Choices）
写分片时不可能为找"全局最闲盘"去查询数百万盘的状态。S3 的做法：随机抽两块盘，放到较闲的那块。统计学证明，这个极简策略的负载均衡效果指数级优于纯随机，逼近"全知全局状态"的理想效果，开销却微乎其微。
2. 主动再平衡
利用"新数据热、旧数据冷"的规律：后台持续把冷数据迁往归档盘，给热盘腾位置；扩容新机架时，立刻从最忙的盘上迁分片到空盘，负载随容量扩展自动摊平。
3. 工作负载去相关（Workload Decorrelation）
单用户的流量是脉冲式的，但数百万独立客户的峰值彼此错开、互相对冲（大数定律）——聚合后的总负载平滑可预测。这是只有行星尺度系统才配拥有的天然稳定器，让容量规划从容高效。
给普通工程师的启示
- 理解硬件，用软件放大其长处：HDD 的顺序读并不慢，架构把它逼成只干擅长的事；
- 并行化 + 冗余编码是突破单机极限的通用范式；
- 简单的随机算法（二选一）在超大规模下能打败复杂的全局调度；
- 规模本身是特性：去相关效应只有大到一定程度才涌现。
观测云对照
你未必在建行星级系统，但对象存储、磁盘 I/O、热点问题在任何规模都存在。观测云 DataKit 采集主机磁盘 IOPS、util、await 等指标，帮你识别自家系统里的"热点盘"；对云对象存储的访问延迟和错误率，可用可用性监测从外部持续拨测验证，配合监控器在异常时第一时间告警。 1 2
常见问题（FAQ）
Q：既然 HDD 够用，为什么还有 S3 Express One Zone 这类 SSD 产品？
HDD 方案靠并行堆出的是"总吞吐"，单请求延迟仍在毫秒级。对延迟敏感型负载（如 ML 训练高频读取），SSD/闪存产品提供的是另一个维度的价值。
Q：纠删码和多副本哪个好？
多副本（如 3 副本）简单但存储开销是 3 倍；纠删码 5-of-9 只花 1.8 倍空间就能容忍 4 盘故障。超大规模下省的就是真金白银，代价是计算复杂度和恢复时的额外读放大。
Q："11 个 9 持久性"是不是数据绝不会丢？
是概率承诺而非绝对保证。按这个数字，存 1000 万年预期丢一个对象级别的可靠性——但它只覆盖"存储介质失效"，不防你自己误删。
Q：小公司能借鉴"二选一"负载均衡吗？
完全可以。它是无状态随机算法，几十台服务器的集群同样有效，实现只要几行代码。
