Uber 如何通过批处理实现单账户每秒30+次更新

Uber 近日介绍了一套高吞吐量账本处理系统用于解决其分布式账务基础设施中单个账户持续遭遇高并发写入的问题。这类问题通常出现在大量更新请求集中落到同一个账户上的场景中。当更新频率持续升高时传统“一次请求对应一次事务”的处理模式很快会触及性能瓶颈。根据 Uber 工程团队介绍这套新系统在满足严格一致性和审计要求的前提下能够实现单个账户每秒 30 次以上的更新处理能力。该能力是构建在 Uber 财务账本平台之上。整个账本系统采用复式记账模型负责记录平台内所有资金流转行为。复式记账能够提供很强的数据正确性保证和端到端可追溯能力但代价是同一账户上的更新操作必须严格串行执行。在大规模调账、财务对账或运营修正等场景下某些账户会在短时间内收到大量更新请求。此时传统事务执行流程中的瓶颈便会逐渐显现出来。在旧架构中每一次账本更新都会触发一次完整且独立的处理流程。这个流程包括读取账户状态、执行校验、计算余额变化以及持久化账本记录和审计日志等步骤。由于每个请求都需要重复执行这一整套流程当某个账户成为热点账户时系统会产生大量额外开销。这些开销主要来自频繁的存储访问、事务协调成本以及写放大问题。为了解决这一问题Uber 在新架构中引入了基于批处理的执行模型。其核心思路并不复杂不再逐条处理更新请求而是将同一账户上的多个操作聚合到一个很短的时间窗口内然后统一执行。这样一来多个更新操作便能够共享一次账本读取和写入过程从而显著降低系统开销。整个处理流程可以分为三个阶段。首先系统会按照账户维度对更新请求进行聚合在固定时间窗口内形成批次。随后批次中的所有操作会作为一个原子单元统一执行。系统只需读取一次账本状态并在同一次执行过程中完成校验和余额更新。最后处理结果被持久化并同步到下游系统包括审计日志和财务对账流水线等。目前系统采用约 250 毫秒的批处理窗口。更新请求的聚合由 Redis 负责协调而底层则利用乐观式原子更新机制来保证并发场景下的数据正确性。这种设计既保留了财务系统所要求的一致性保证www.ntjrcw.com又能够通过横向扩展提升整体处理能力。在架构设计过程中一个重要的权衡点是批处理窗口的大小。窗口越短请求等待时间越少但系统需要承担更多调度和执行开销。窗口越长则能够提高吞吐效率但代价是请求需要等待更久才能被处理。最终Uber 选择了一个经过严格控制的批处理窗口在接近实时处理能力与系统效率之间取得平衡。系统还专门设计了故障隔离机制以应对批处理中部分操作失败的情况。例如当出现短暂的存储异常或网络故障时系统会尽可能将影响限制在单个操作层面而不是让整个批次失败。这样不仅减少了重试放大效应也提升了系统在高峰负载下的稳定性。首席信息官 Mark Peters 表示对于 Uber 这样规模的平台而言在保证严格一致性的同时实现亚秒级批处理能力是构建运营韧性的关键。Uber 表示这套架构已经显著缩短了高负载场景下的账务处理时间。对于平台内部的大规模资金流转业务而言它不仅加快了财务对账速度也提升了整个市场平台运营流程的处理效率。