Uber 近日介绍了一套高吞吐量账本处理系统，用于解决其分布式账务基础设施中单个账户持续遭遇高并发写入的问题。这类问题通常出现在大量更新请求集中落到同一个账户上的场景中。当更新频率持续升高时，传统“一次请求对应一次事务”的处理模式很快会触及性能瓶颈。根据 Uber 工程团队介绍，这套新系统在满足严格一致性和审计要求的前提下，能够实现单个账户每秒 30 次以上的更新处理能力。

该能力是构建在 Uber 财务账本平台之上。整个账本系统采用复式记账模型，负责记录平台内所有资金流转行为。复式记账能够提供很强的数据正确性保证和端到端可追溯能力，但代价是同一账户上的更新操作必须严格串行执行。在大规模调账、财务对账或运营修正等场景下，某些账户会在短时间内收到大量更新请求。此时，传统事务执行流程中的瓶颈便会逐渐显现出来。

在旧架构中，每一次账本更新都会触发一次完整且独立的处理流程。这个流程包括读取账户状态、执行校验、计算余额变化，以及持久化账本记录和审计日志等步骤。由于每个请求都需要重复执行这一整套流程，当某个账户成为热点账户时，系统会产生大量额外开销。这些开销主要来自频繁的存储访问、事务协调成本以及写放大问题。

用户账户事件的传统串行处理方式（来源：Uber 博文）

为了解决这一问题，Uber 在新架构中引入了基于批处理的执行模型。其核心思路并不复杂：不再逐条处理更新请求，而是将同一账户上的多个操作聚合到一个很短的时间窗口内，然后统一执行。这样一来，多个更新操作便能够共享一次账本读取和写入过程，从而显著降低系统开销。

Uber 主任软件工程师 Raghav Kumar Gautam 表示：

我们构建了一套能够应对极端流量，同时不牺牲一致性的事务处理系统。通过 250 毫秒批处理窗口、Redis 协调机制以及乐观式原子更新（optimistic atomic updates），该系统在支持水平扩展的架构上实现了单账户每秒 30 多笔交易处理能力，将原本需要数小时的处理流水线缩短到了几分钟。

用户账户批处理系统架构（来源：Uber 博文）

整个处理流程可以分为三个阶段。首先，系统会按照账户维度对更新请求进行聚合，在固定时间窗口内形成批次。随后，批次中的所有操作会作为一个原子单元统一执行。系统只需读取一次账本状态，并在同一次执行过程中完成校验和余额更新。最后，处理结果被持久化，并同步到下游系统，包括审计日志和财务对账流水线等。

目前系统采用约 250 毫秒的批处理窗口。更新请求的聚合由 Redis 负责协调，而底层则利用乐观式原子更新机制来保证并发场景下的数据正确性。这种设计既保留了财务系统所要求的一致性保证，又能够通过横向扩展提升整体处理能力。

在架构设计过程中，一个重要的权衡点是批处理窗口的大小。窗口越短，请求等待时间越少，但系统需要承担更多调度和执行开销。窗口越长，则能够提高吞吐效率，但代价是请求需要等待更久才能被处理。最终，Uber 选择了一个经过严格控制的批处理窗口，在接近实时处理能力与系统效率之间取得平衡。

系统还专门设计了故障隔离机制，以应对批处理中部分操作失败的情况。例如，当出现短暂的存储异常或网络故障时，系统会尽可能将影响限制在单个操作层面，而不是让整个批次失败。这样不仅减少了重试放大效应，也提升了系统在高峰负载下的稳定性。

首席信息官 Mark Peters 表示：

对于 Uber 这样规模的平台而言，在保证严格一致性的同时实现亚秒级批处理能力，是构建运营韧性的关键。

Uber 表示，这套架构已经显著缩短了高负载场景下的账务处理时间。对于平台内部的大规模资金流转业务而言，它不仅加快了财务对账速度，也提升了整个市场平台运营流程的处理效率。

查看英文原文：30+ Updates per Second per Account: Uber Scales Ledger Processing with Batching - InfoQ