对象存储当真相源 — 把共识外包给 S3 的「零盘」架构Object Storage as the Source of Truth: The Zero-Disk Architecture

问题场景 + 需求约束

给一个 agent 时代的 Git 托管服务做存储层。流量形状变了：几十万个 coding agent 在同一批仓库上并发 fetch、小步 push，读写比约 100:1，但写频率远高于人类。

• 规模：10 万仓库，单仓最大 50 GB；峰值 300 push/s，读 QPS 三万级。
• 持久性：push 返回成功即不可丢（RPO = 0）。
• 一致性：push 成功后任何节点的后续 fetch 必须看到它（单仓线性一致）。
• 弹性：节点跑在 spot 上随时被回收；新节点要能立刻接流量。

传统答案是「有状态副本组 + 共识」：每仓三副本、Raft 选主、push 走 leader 多数派确认。能用，但副本组是有状态的：扩容要搬数据、节点死了要重建副本、读扩展受副本数限制、写吞吐被 leader 往返锁死，而仓库大小不均让 rebalance 成为常态。

高层架构

graph LR
    C["Git 客户端
push / fetch"] --> LB["L7 路由
rendezvous hashing"]
    LB --> N1["节点 A
NVMe 热缓存"]
    LB --> N2["节点 B
NVMe 热缓存"]
    LB --> N3["新扩容节点 C
缓存为空"]
    N1 -- "①数据 PUT ②index CAS" --> S3[("对象存储
WAL = 真相源
不可变数据 + 可变 index")]
    N2 -- "条件 GET
ETag 命中则 304" --> S3
    N3 -- "从 WAL 重建整个仓库" --> S3
    N1 -. "UDP gossip: WAL 已推进到 seq=N" .-> N2
    N1 -. gossip .-> N3

三件事值得指出。真相源只有一份：对象存储里的 WAL——数据对象不可变、内容寻址，加一个可变 index 记录顺序。节点同质无状态：任何节点都能接任何仓库的 push，本地 NVMe 上那份真实 git 仓库只是热缓存。gossip 不承担正确性——它只让副本早一点知道该拉新数据；正确性全压在 index 的条件写上，落后的副本在服务读之前必然先做一次条件 GET 对账。

关键点 1：把串行化点从副本组搬到对象存储的条件写

一句话 trade-off：用一次 PUT 的延迟，换掉整套 leader 选举、成员变更和多数派协调。

原理

共识的本质是给并发写定一个全序。Raft 用「多数派承认的 leader + 单调 term」产生它，代价是维护一个有状态副本组。而 2024 年起 S3 支持条件写：PutObject 带 If-Match: <etag>，ETag 不匹配即返回 412——一个跨 AZ 持久化的单 key 原子 compare-and-swap。

架构于是反转：数据对象无条件并发写（不可变、重传安全），顺序由一次 index 的 CAS 决定。CAS 成功的那一刻既是「push 进入历史」的时刻，也是能 ack 客户端的最早时刻。谁赢 CAS 谁排前面，输的人重读、重算、重试——没有 leader，也不需要有。

sequenceDiagram
    participant A as 节点 A
    participant B as 节点 B
    participant S as 对象存储
    A->>S: PUT wal/0042.pack 不可变数据
    B->>S: PUT wal/0043.pack 不可变数据
    A->>S: PUT index If-Match etag_v7
    S-->>A: 200 OK 新 etag_v8
    A->>A: ack 客户端：push 成功
    B->>S: PUT index If-Match etag_v7
    S-->>B: 412 Precondition Failed
    B->>S: GET index 读到 v8 含 A 的记录
    B->>S: PUT index If-Match etag_v8
    S-->>B: 200 OK 新 etag_v9
    Note over A,B: 只有 index 的 CAS 是串行点
数据对象的 PUT 全程并发

选型 Trade-off

伪代码

# 追加 WAL 记录；index 的 CAS 是唯一串行化点（pseudo-code）
def append(repo, record):
    for _ in range(MAX_RETRY):
        idx, etag = s3.get_json(f"{repo}/index.json")     # 读当前 WAL 头
        key = f"{repo}/wal/{idx.next_seq:08d}.pack"
        s3.put(key, record)                              # ① 不可变，可并发、重传安全
        idx.entries.append({"seq": idx.next_seq, "key": key,
                            "sha": sha256(record)})
        idx.next_seq += 1
        try:
            s3.put_json(f"{repo}/index.json", idx, if_match=etag)   # ② CAS
            return idx.next_seq - 1                      # 到此才 ack 客户端
        except PreconditionFailed:                       # 412：有人抢先推进
            continue                                     # 重读 → 重算 → 重试
    raise Contention(repo)
# CAS 失败留下的 ① 是孤儿对象：无人引用，交给 GC，不影响正确性

关键点 2：本地盘降级为可丢的热缓存

一句话 trade-off：放弃「本地盘就是数据」的假设，换来节点无状态、读副本线性扩展、spot 回收无痛。

原理

真相一旦在对象存储，本地 NVMe 上那份 git 仓库的身份就变了：它不是副本，是缓存。收益有三：扩容不再搬数据（空载上线、按需 materialize）；节点故障不必重建副本；读扩展不受副本数限制——Cursor 报告合成测试中读吞吐可随副本数线性扩展到 100 节点。

读路径的代价是缓存可能落后，所以服务读之前先对账——拿本地 ETag 发条件 GET，If-None-Match 命中就返回 304、下载 0 字节（常态热路径）；真落后了才按 seq 差值补拉。gossip 只是把「该对账了」提前通知到。

选型 Trade-off

代价是冷读放大：新节点的第一个 fetch 要从 WAL 重建仓库，延迟可能是热路径几十倍。三条缓解各有代价：rendezvous hashing 把同仓流量粘到少数偏好节点（命中率↑，牺牲负载均匀度、引入热点仓库）；周期 snapshot 让重建从 replay 全史变成「snapshot + 尾部增量」（省冷读，花存储与后台 CPU）。

伪代码

def serve_fetch(repo, want):
    local = cache.get(repo)                                  # NVMe 上的真实 git 仓库
    head = s3.get_json(f"{repo}/index.json",
                       if_none_match=local.etag)             # 条件 GET
    if head is NOT_MODIFIED:
        return git_upload_pack(local, want)                  # 热路径：零 S3 流量
    for e in head.entries[local.seq + 1:]:                   # 落后多少补多少
        local.apply(s3.get(e.key))
    local.etag, local.seq = head.etag, head.last_seq
    return git_upload_pack(local, want)

def materialize(repo):                                       # 缓存丢失时
    repo_dir = restore(s3.get(f"{repo}/snapshot/latest"))
    for e in wal_entries_after(snap.seq):                     # 补尾部增量
        repo_dir.apply(s3.get(e.key))
    return repo_dir

关键点 3：延迟与成本曲线从「磁盘」换成「请求数」

一句话 trade-off：攒批窗口是一个旋钮——往右拧省钱提吞吐，往左拧降延迟涨成本。

原理

零盘架构的写延迟有硬下限：对象存储 PUT 的 p99，因为「未落对象存储不确认」是持久性承诺的全部依据。WarpStream 的公开数字很有代表性：默认 S3 Standard 下 Produce 的 p99 约 400 ms（4 MiB 对象写入 S3 的 p99 量级），换 S3 Express One Zone（低延迟、单 AZ）可降到 169 ms。Cursor 的对应数字是 S3 Standard 约 120 push/s、Express One Zone 300+ push/s，而后者瓶颈已不在 S3 而在 git 压缩本地数据的速度。

成本也换了维度：不再为 IOPS 和容量付费，而是为请求数付费。小对象风暴因此是头号成本杀手，解药只有攒批：把多个写（甚至多分区、多仓库的）合并进一个对象，N 次 PUT 变 1 次。

选型 Trade-off

攒批窗口同理：窗口越长，摊薄的请求成本越低、吞吐越高，但 p99 直接加上窗口长度。旋钮必须由 workload 决定：日志摄取拧到 250 ms 以上毫无痛感；agent 等 push 返回才能走下一步时，每 100 ms 都在吃等待时间。

伪代码

// 多分区攒批成一个共享对象：按请求数计费，非 IOPS（pseudo-code）
for {
    batch := buf.Drain(maxWait: 250*time.Millisecond, maxBytes: 8<<20)
    key, err := objectStore.Put(encode(batch))     // 一对象混装多 partition
    if err != nil { batch.NackAll(); continue }    // 未落盘绝不 ack
    offsets := coordinator.Commit(key, batch.Index())  // 定序、分配 offset
    batch.AckAll(offsets)                          // 对象 + 元数据都提交后才 ack
}

关键点 4：正确性押在厂商的条件写语义上

一句话 trade-off：省掉一整套共识实现，代价是把线性一致的根基交给一个外部 API 的语义细节。

原理

①「强一致」不等于「有 CAS」。S3 在 2020 年就给了读写强一致，但那只保证读到最新版本，不提供原子性原语；CAS 是 2024 年条件写上线后的事（AWS 文档）。这解释了为什么早期 Iceberg / Delta 在 S3 上要靠外部锁表补洞。

② CAS 只覆盖单 key。两个对象的两次条件写不构成一个事务，所以所有可变状态必须收口到一个 key，其余对象全部不可变、内容寻址。

③ 实现差异是真实风险。条件写语义在 S3、MinIO、R2、Ozone 之间并不天然一致（Apache Ozone 到 2026 年才专门实现 S3 条件请求以支持这类乐观并发）。声称多云，押的是最弱那家的语义。

选型 Trade-off

直押对象存储 CAS：组件最少，但正确性绑定单一厂商。外部共识兜底（指针放 etcd/DynamoDB）：换回跨 key 事务与可移植性，代价是请回一个有状态组件。专用协调器（KIP-1150 路线）：定序逻辑自己掌握、可做复杂 offset 语义，但协调器自己又是个需要高可用的有状态服务——共识被推走了，没有消失。

伪代码

# 反例：两个 key 的条件写不是一个事务
s3.put_json(f"{repo}/refs.json",  refs, if_match=e1)    # 成功
s3.put_json(f"{repo}/index.json", idx,  if_match=e2)    # 此处崩 → 两 key 永久不一致

# 正确形状：单 key 收口（Iceberg / Continuity 同一骨架）
mid = content_hash(full_state)
s3.put(f"{repo}/manifest/{mid}", full_state)            # 不可变，重传安全、无需条件
s3.put_json(f"{repo}/HEAD", {"manifest": mid},
            if_match=head_etag)                         # 唯一可变指针 = 唯一 CAS 点
# 旧节点醒来重试？手里的 head_etag 必然过期 → 412 → CAS 本身就是 fencing token

扩展与优化

Compaction 是第一等公民：WAL 无限增长会让冷读变成 replay 全史，必须周期把尾部压成 snapshot；它还与写路径争同一个 CAS 点——Cursor 的 120 push/s 正是「边压缩边复制」下的数字。CAS 热点要按仓库分片：全局一个 index 等于把全站写吞吐锁在一个 key 的争用上；按仓库（或表、分区组）各一个可变 key，争用才与业务粒度对齐。多区域是下一道坎：条件写是区域内语义，跨区域复制异步且非原子，要么回到单写区域 + 只读副本，要么重新引入跨区域共识。尾延迟靠 hedged request：p99 既由外部 PUT 决定，能做的就是对慢请求发第二份——而请求数就是账单。

常见陷阱 + 面试问题

• 「本地盘先 ack、后台异步传 S3」——延迟确实好看，但 RPO 不再是 0，持久性承诺已破。面试高频送命题：ack 的时机就是持久性契约本身。
• 把 gossip 当正确性机制。它是 UDP、会丢，只能加速发现，不能替代条件 GET 对账。被问「gossip 丢了会怎样」，答案是「副本多落后一会儿，但读前必然对账，不影响正确性」。
• 算错成本维度。从 $/GB-月 迁到 $/请求后，每秒几千次小 PUT 可能比磁盘方案更贵。攒批不是优化，是这套架构的前提。
• CAS 争用没有退避。裸重试在高并发下放大成活锁；必须配指数退避 + 抖动，并把「争用导致的 412 率」做成一等指标——它是分片粒度不对的早期信号。
• 追问清单：① 对象存储没有条件写时你怎么补洞、代价几何？② 两个节点同时 CAS 成功是否可能，为什么？③ 300 push/s 的瓶颈在哪一层，怎么证明？④ 换成要求 p99 写延迟 < 10 ms 的金融账本，你还选这套吗？⑤ 孤儿对象怎么 GC，会不会误删仍被引用的对象？

深入资源

• Git at any scale · Cursor — Continuity 架构原文：S3 WAL 作真相源、CAS 定序、rendezvous hashing、gossip、吞吐数字。
• KIP-1150 Accepted, and the Road Ahead · Aiven — Kafka Diskless Topics 被接受后的落地路线与未决问题。
• Kafka Is Dead, Long Live Kafka · WarpStream — 无盘 Agent + 直写对象存储的完整论证与延迟/成本账。
• AWS: S3 conditional writes — If-Match / If-None-Match 的准确语义，设计前必读。
• Understanding Apache Iceberg's Consistency Model · Jack Vanlightly — 同一骨架在数据湖侧的一致性分析。
• Designing Data-Intensive Applications（Martin Kleppmann）— 复制与共识两章，判断「这套省掉了什么」的底座。

深入思考