FAST'26 论文速递 | ACOS: 苹果 EB 级地理分布式对象存储

2026年3月3日 178点热度 1人点赞 1条评论

ACOS: Apple’s Geo-Distributed Object Store at Exabyte Scale

本文为 FAST'26 顶会论文，原文链接为 ACOS: Apple’s Geo-Distributed Object Store at Exabyte Scale - FAST 26

@article{baronacos,
  title={ACOS: Apple’s Geo-Distributed Object Store at Exabyte Scale},
  author={Baron, Benjamin and Bousquet, Aline and Metens, Eric and Pimpale, Swapnil and Puz, Nick and de Saint Sauveur, Marc and Muzumdar, Varsha and Ari, Vinay}
}

团子观点：ACOS 的关键设计与亮点

作为分布式存储方向（尤其是对象存储）的从业者，读这篇 ACOS 的动机很直接：苹果在单一大规模对象存储里把地理复制、纠删码和多年生产运维的一些经验，很多设计点和我们日常在做的冗余、扩展、成本权衡是同一类问题。下面从 “值得留意的设计” 和 “实际代价” 两方面做个简要梳理，方便读者带着问题读正文。

双层编码与复制因子。 ACOS 的冗余是 “本地 + 区域” 两层：stamp 内用 (20,2,2) LRC 应对盘/节点/机架故障，区域间用按位 XOR 把对象切成 4 数据段 + 1 校验段分布在多区域（XOR-5）。这样整体复制因子从 1.0 的 2.40 压到 2.0 的 1.50，省了跨区域的全量复制。亮点可能不在于 XOR 本身多新颖，而在于和 LRC 组合后，在持久性模型（MTTDL）和可用性（降级/不可用时长）上有清晰的建模和参数表（见表 3），方便做编解码与布局的选型。区域层用 XOR 而不是更重的 RS，也符合 “跨域带宽贵、简单运算更可控” 的工程直觉。

另外，如果读者的方案需要计算持久性这个数据，可以参考本文中的 “马尔科夫模型” 方法。

统一端点与弹性扩展。 1.0 的 store 是固定容量、独立生命周期，客户要自己管多端点、多凭证和跨 store 的迁移与均衡，扩容和下线都很重。2.0 改成统一 DNS 端点 + 多区域多 stamp，通过 stamp 权重和 rebalancer 做容量与负载均衡，新老 stamp 的上下线对客户透明。这对 “一个系统吃下多业务、持续加容量” 这种动态容量变化的互联网业务诉求是刚需；限流也拆成部署级和 stamp 级两层，和分段后的流量形态匹配。

生产运维里的经验。 论文里对「从 1.0 到 2.0」的迁移写得很真实：客户端与凭证迁移 → 对象异步迁移 → 校验 → 请求代理 → DNS 切换，艾字节级、无停机、对客户透明。但可惜的是，这部分没有详细展开。延迟方面，2.0 因对象被拆到多区域，GET 和 TTFB 会变差；用 DNS 地理路由、元数据非一致读 + 预取（一致读兜底）、以及段区域偏向（优先从 RTT 小的区域取段，宁可用 XOR 重建换掉跨大陆传输）以服务端和客户端延迟。负载均衡器成为瓶颈后，stamp 间流量绕过负载均衡器，由请求处理器自己做健康探测与连接管理，换来 p50/p90 延迟的明显下降。这部分都是非常易懂、实在的经验。

需要接受的代价。 2.0 的 GET 延迟和 TTFB 相对 1.0 仍会升高，约 50 ms 量级与跨区域 RTT 一致；元数据用非一致读做预取，要容忍极少量请求的元数据纠错与重试。单区域故障时依赖 XOR 重建，对延迟也有一定影响。整体上，这是一套在成本、持久性、可用性和延迟之间做了明确取舍的 geo 对象存储，论文把两代架构、生产数据和建模展开讲述了下。

这篇论文不算难懂，总体上还是符合分布式存储的典型模式的。对于刚刚接触分布式存储的朋友，尤其是琢磨架构的读者，适合按「设计目标 → 机制 → 评估」顺着读下去。