S3 的 11 个 9 (99.999999999%) 是如何实现的 - 对象存储耐久性的幕后机制
从数据分散、一致性校验、自动修复三大机制解析支撑 S3 公称 99.999999999% 耐久性的内部架构，并用具体数字说明 11 个 9 究竟意味着什么。
11 个 9 具体是什么概念
99.999999999% 这个数字的位数多到难以直观理解。具体来说，如果在 S3 中存储 1000 万个对象，那么每 1 万年才会丢失 1 个对象。或者说，如果全人类 80 亿人各自在 S3 中存储 1 个对象，100 年内丢失的对象在统计上不到 1 个。需要注意的是，这个数字是「耐久性」(Durability) 而非「可用性」。可用性是服务可访问时间的比例，S3 Standard 的可用性为 99.99% (年停机时间约 52 分钟)。耐久性是数据不丢失的概率，保证一旦保存的对象不会物理消失。也就是说，S3 可能出现暂时无法访问的瞬间，但数据本身事实上不会消失。不理解这一区别的话，在 S3 发生故障时可能会误以为「数据丢失了」。
数据分散 - 至少冗余到 3 个 AZ 的机制
S3 耐久性的第一根支柱是数据的物理分散。将对象上传到 S3 Standard 时，AWS 会将数据冗余到同一区域内至少 3 个 Availability Zone (AZ)。当 PUT 请求返回 200 OK 时，至少已完成向 2 个 AZ 的数据写入。第 3 个 AZ 的复制异步进行，但通常在数秒内完成。每个 AZ 由物理上相距数十公里以上的独立数据中心群组成，电力系统、冷却系统、网络连接全部独立。也就是说，即使 1 个 AZ 因自然灾害或大规模故障完全损毁，数据仍存在于其余 2 个 AZ 中，对象不会丢失。2 个 AZ 同时完全损毁的概率极低，这就是 11 个 9 耐久性的物理基础。S3 One Zone-IA 是例外，仅将数据存储在单个 AZ 中，虽然耐久性仍为 99.999999999%，但对整个 AZ 的物理损毁较为脆弱。
一致性校验 - 持续监控每一个比特
仅将数据分散到多个 AZ 还不足以达到 11 个 9。必须应对磁盘老化、宇宙射线导致的比特翻转、固件 Bug 等「静默数据损坏」问题。S3 在存储对象时计算 MD5 校验和并作为元数据保存。此外，自 2021 年起用户可以指定额外的校验算法 (CRC32、CRC32C、SHA-1、SHA-256)。S3 在后台定期重新计算所有对象的校验和，并与存储时的值进行比对。这个被称为「Scrubbing」的过程可以及早检测比特级别的损坏。AWS 在 2023 年 re:Invent 上公布，S3 每天执行数十亿次校验和验证。检测到的损坏会从其他 AZ 中存储的正常副本自动修复。这种检测与修复的循环机制可以防患于未然。
自动修复 - 检测到故障后无需人工干预即可恢复
S3 的自动修复机制针对磁盘故障、服务器故障、AZ 级别故障分阶段运作。当单个磁盘发生故障时，S3 立即检测并将该磁盘上存储的数据分片重新复制到其他正常磁盘。AWS 数据中心每天都有大量磁盘故障，这种自动修复 24 小时 365 天无需人工干预地持续执行。服务器级别的故障也有同样的处理流程。关键在于修复速度。从故障发生到重新复制完成期间，冗余性暂时降低。为了最小化这个「脆弱窗口」，S3 将修复处理作为最高优先级的后台任务执行。AWS 未公布具体修复时间，但在设计上确保冗余性降低不会持续太长时间。此外，S3 使用纠删码 (Erasure Coding)，将数据分割为多个分片存储。即使部分分片丢失，也能从剩余分片完整恢复原始数据。这种机制以比简单三副本更少的存储容量实现了更高的耐久性。
即使是 11 个 9 也可能丢失数据的场景
S3 的耐久性极高，但数据丢失风险并非为零。11 个 9 保证的是针对 AWS 侧物理故障导致的数据丢失。用户侧的操作失误不在保证范围内。最常见的数据丢失原因是误执行 DELETE 操作。在未启用版本控制的状态下删除对象，会立即被完全删除。即使启用了版本控制，指定版本 ID 的 DELETE 也是永久删除。针对这个问题，设置 S3 Object Lock (WORM: Write Once Read Many) 可以在指定期间内物理上禁止对象的删除和覆盖。启用 MFA Delete 则可以要求删除操作进行 MFA 认证。另一个容易忽视的风险是加密密钥丢失。使用 SSE-C (客户提供密钥) 加密的对象，一旦密钥丢失就无法解密。数据虽然存在于 S3 中，但处于不可读状态。使用 SSE-KMS 并为 KMS 密钥的删除设置等待期 (7~30 天) 可以降低这一风险。要系统学习数据保护设计，可参考相关专业书籍 (Amazon)。