Jetpack：让共识普遍变快（OSDI 2026）

原题：Jetpack: Consensus Made Generally Fast

一句话总结：经典共识通常需要 2 RTT 提交命令；Jetpack 将一个并行的 1-RTT 快路径作为 shim 加到既有协议上，并用同视图确认与稳定性标记解决视图切换风险，在六个共识系统和十个 AWS 数据中心的实验中将平均提交延迟最多降低约 60%，但以额外 CPU、恢复停顿和多领导者场景下的吞吐为代价。

问题与动机

Raft、MultiPaxos 和 Viewstamped Replication 的客户端提交通常需要 2 RTT。跨地域部署中，客户端到领导者以及领导者复制到副本的往返延迟会直接进入提交路径。已有 1-RTT 协议通常把快路径深度嵌入自身协议，无法直接加到已经部署的 Raft 变体、数据库或具有特殊故障性质的协议上。

Jetpack 的目标是保留原协议作为独立后备路径。客户端可选择快路径或原路径；即使所有请求都走原路径，也不应增加性能开销；原协议已有的能力，例如 Copilot 对慢领导者的容忍，也应保留。论文明确不覆盖 BFT 共识和交互式事务。

关键观察 / 隐含假设

观察 1：冲突命令之外，命令顺序可以由快路径提前确定。 Jetpack 利用可交换命令，只要求冲突命令在原路径日志中的相对顺序与快路径推测执行一致。论文将其抽象为 Conflict(c1,c2) 接口，并要求原协议满足 PR 1：同一 proposer 先提出的冲突命令先进入日志并先执行。
- 依赖假设：应用能够以足够精度判断冲突，且原协议按日志顺序执行。
- 可能失效场景：范围查询、隐式别名依赖、跨对象事务或会重排依赖图的协议可能无法满足该条件；论文指出 EPaxos 不满足 PR 1。
观察 2：快路径的安全承诺在视图切换后并不会自动持久化。 旧视图的 proposer 曾承诺不把冲突命令放在快提交命令之前，但新 proposer 可能不知道这一承诺。论文称之为 view change hazard，并拆成 R1（找回所有已快提交命令）和 R2（把它们放在新视图中冲突未提交命令之前）。
- 依赖假设：快路径副本能保留足够的同视图确认，且新视图可以在处理普通命令前完成恢复。
观察 3：shim 的消息到达顺序必须等价于 proposer 的提出顺序。 Jetpack 的轻量集成依赖 PR 2：proposer 先收到 A 再收到 B，就必须先提出 A。带有额外缓冲层的协议可能破坏该关系，导致快路径确认早于原日志中的真实顺序。

核心方法

Jetpack 将客户端命令同时发送到快路径和原路径。快路径使用类似 Fast Paxos 的 superquorum；原路径 proposer 收到命令后，如果尚未看到冲突命令，就返回一个 promise，承诺不在该命令之前提出并提交冲突命令。只有快路径 superquorum 和所有原路径 proposer 都确认，客户端才把命令视为 1 RTT 提交。若出现冲突或确认不足，命令仍由原路径完成。

在多日志系统中，Jetpack 不要求两个路径使用相同的日志位置，而是依赖冲突关系。所有 proposer 都看到快路径命令后，PR 2 使其在后续冲突命令之前提出；PR 1 再把提出顺序传递到提交和执行顺序。重复插入同一命令的 Copilot、Mencius 等多序列协议需要在执行时跳过重复项。

Jetpack 用两个设计原则处理视图切换。原则 1要求快路径拥有独立于原路径的 view，只有两条路径处于同一 view 时才允许快提交，因此同一快提交命令的确认不会跨 view。原则 2要求新 view 先恢复上一个正常 view 中的快提交命令，再处理普通命令；恢复集合（为空时为 no-op）在原路径提交后作为稳定性标记，阻止旧 view 的未提交冲突命令抢在恢复命令之前。

实现上，Jetpack 是与原副本并置的 shim。它通过 Submit(cmd)、view 和 proposer 等少量接口接入原系统。恢复过程包括冻结旧 view 的快路径、用类似 Paxos 的过程确定恢复集合，以及将集合重新提交到原路径。客户端根据最近延迟和 CPU 使用率自适应选择快路径，负载升高时回退到原路径。

设计取舍

低侵入性换取吞吐上限：原路径基本不知道快路径，因此可以保留原协议行为，但每个快路径命令要发送给所有 proposer，无法像原生快路径那样重构复制和负载分布。
低延迟换取 CPU 与恢复成本：冲突检测、promise、命令池和重复执行过滤增加资源消耗；视图切换还要额外运行恢复协议。Raft 恢复比 vanilla Raft 多约 1 秒，MongoDB 多约 1.5 秒。
适用性依赖应用冲突接口：键值读写可用 key 级判断；范围查询、SQL 谓词和隐式依赖需要更复杂索引，误报会损失快路径机会，漏报则影响正确性。
多领导者是脆弱边界：Mencius 中每条命令都要触达所有领导者，CPU 开销随领导者数量线性增长；任一领导者故障还会使要求全部 leader 的快提交不可用。

实验与结果

在十个 AWS 地理数据中心、50% 读/50% 写、100 万 Zipf 分布键、60 个开放环客户端的环境中，Jetpack 集成 Raft 的自适应模式平均延迟降低 53.39%；Copilot 降低 63.90%；MongoDB 降低 39.06%（图 7）。
Jetpack-Raft 在低负载下达到约 165–210 ms 的 1-RTT 延迟，与 CURP、SwiftPaxos 和 EPaxos 同量级；vanilla Raft 约 355 ms。但吞吐峰值约 12k，低于 SwiftPaxos 的约 19k 和 EPaxos 的约 25k（图 10）。
快路径尝试率为 0 时，Jetpack-Raft 曲线几乎与 vanilla Raft 重合（图 7），支持“原路径不受影响”的目标。高负载时自适应策略回退到原路径，吞吐恢复到原系统水平。
冲突率升高时收益下降，但 Raft 和 MongoDB 在不同 Zipf 偏斜与键范围下的平均延迟和 P99 仍优于 vanilla 版本（图 8）。
在 Akkio 风格的五区域访问分布中，Jetpack 与 leader locality、read lease 可组合：lease 主要降低本地读延迟，Jetpack 为远端访问和写请求提供 1 RTT 路径（图 11）。
代价是视图切换恢复停顿，以及 Mencius 的明显 CPU 增长（图 9、图 13）。MongoDB、etcd 和 ZooKeeper 集成分别只需约 60、68 和 52 行原协议侧代码，但仍需调整恢复逻辑。

论断—证据表

论断	证据	评测边界	置信度
Jetpack 能在既有协议上提供 1 RTT 提交	§3、图 7、图 10	C++ 实现；AWS 十数据中心；Raft、Copilot、Mencius、MongoDB 等	强
快路径未使用时不拖慢原路径	§6.3、图 7；固定尝试率为 0	受测实现和 50/50 YCSB 风格负载	强
同视图确认与稳定性标记覆盖视图切换安全风险	§4、§B；TLA+ model checking	依赖 A1–A4、PR 1/PR 2；不覆盖 BFT	中
通用 shim 的吞吐低于原生快路径	§6.3.1、图 10	共享代码库、单核 consensus thread、均匀负载	强

批判性分析

论证链条

论文的逻辑链条较完整：冲突可交换性给出快路径的条件，proposer promise 将快路径结果绑定到原路径顺序，两个 view-change 原则保证承诺可恢复。实验覆盖了单领导者、慢领导者、多领导者和生产数据库，能说明接口并非只适用于 Raft。

但“通用”仍受 PR 1、PR 2、Conflict 接口和原协议恢复语义限制。16 个 OSDI/SOSP 共识系统的兼容性调查显示，十个没有内建快路径的系统中九个满足 PR 1，但这不是对任意共识协议的证明。EPaxos 和带缓冲层的 Nezha 暴露了抽象边界。

假设压力测试

工作负载默认是独立的键值命令。高冲突时快路径成功率下降，性能更接近原路径；事务、范围谓词和跨对象依赖可能让冲突检测成为新的瓶颈。多领导者场景的线性 CPU 代价不随 shim 优化自然消失。实验使用 AWS 固定规模和 10 秒领导者超时，不能直接外推到更大副本组、不同故障检测策略或持续网络分区。

实验可信度

基线包含 vanilla 实现、原生快路径和生产系统集成，且报告了平均延迟、P99、吞吐、CPU、内存与故障恢复，消融覆盖尝试率和冲突程度。局限在于主要工作负载仍是合成键值负载，生产 trace 只用于 Akkio 风格的局部实验；没有给出长期运维、频繁成员变更、命令大小变化或复杂冲突谓词的成本。

系统性缺陷

恢复阶段会冻结快路径并增加停顿，恢复集合还可能携带大量命令。命令池垃圾回收依赖原路径最终回复；论文未详细讨论 shim 崩溃、状态重建、观测指标和滚动升级。快路径客户端需要维护 view、延迟和 CPU 反馈，客户端库也因此成为部署组成部分。对于误报冲突，系统退化为原路径；对于冲突谓词实现错误，安全性依赖应用层正确性。

局限与后续工作

局限 1：不支持 BFT 和交互式事务；这限制了其对更复杂数据库提交路径的覆盖。
局限 2：Mencius 等共享日志多领导者协议的额外处理量随 leader 数量增长，且单个 leader 故障可能关闭快路径。
后续工作 1：在真实生产 trace 上测量冲突谓词误报率、快路径成功率和 tail latency，并把命令大小、租户隔离和成员变更纳入成本模型。
后续工作 2：设计能容纳缓冲层或依赖重排的接口，明确何时可以延迟 fast-path ack，何时应直接禁用快路径。
后续工作 3：验证 shim 进程故障、恢复集合很大、连续 view change 和网络分区下的恢复停顿与可观测性。

Awesome System Papers Wiki

探索

paper-osdi26-tang