📚 课程目录第4章余额派生基础

4. 余额派生基础

在金融 Ledger 中，流水是不可变的“事实记录”，而余额是从这些事实中派生出来的“视图”。理解余额派生，核心不是记住某个公式，而是建立一种分层思维：流水是唯一真相，余额是可重建的投影。本节围绕余额类型、实时余额与快照余额、派生计算逻辑、缓存策略以及一致性与性能的权衡展开。

一、余额类型：先分清“谁在什么口径下看钱”

同一个账户，在不同业务口径下会呈现不同余额。若类型定义不清，后续对账、风控和提现都会出现歧义。常见余额类型如下：

余额类型	含义	典型用途	是否可直接提现
账面余额	所有已入账流水累计结果	总账核对、报表	否
可用余额	账面余额减去冻结、在途、预扣	下单、提现校验	是
冻结余额	已锁定但未最终扣减的金额	风控、争议处理	否
在途余额	已发起但未清算完成的金额	清算、结算	否
快照余额	某时点固化下来的余额	对账、审计、性能优化	视口径而定

这些类型之间不是并列关系，而是口径叠加关系。例如可用余额 = 账面余额 − 冻结余额 − 在途余额。定义清楚后，余额派生才有稳定的语义基础。

二、实时余额与快照余额：两种时间观

实时余额强调“此刻准确”，通常由流水实时累加或增量更新得到；快照余额强调“某时点确定”，是在特定时间点对余额进行固化。两者并非替代关系，而是配合关系。

实时余额：适合交易校验、风控拦截、用户展示，要求低延迟。
快照余额：适合对账、审计、报表、冷启动，要求可复现、可追溯。
组合策略：以快照为基线，叠加快照之后的增量流水，得到当前余额。

  核心公式：当前余额 = 最近快照余额 + 快照后所有已入账流水增量。这个公式是余额派生系统的“心脏”。

下面这张图展示了流水、快照与实时余额之间的派生关系：

三、派生计算逻辑：从流水到余额的三种路径

余额派生并非只有一种实现方式，常见有三条路径，各有适用场景：

全量重算：从账户创建开始累加所有流水。结果最准确，但性能最差，通常只用于对账或修复。
快照 + 增量：以最近快照为基线，叠加之后的流水。兼顾准确性与性能，是生产系统主流方案。
实时增量更新：每笔流水入账时同步更新余额表。延迟最低，但需处理并发与幂等。

以“快照 + 增量”为例，伪代码逻辑如下：

function deriveBalance(accountId, asOfTime):
    snapshot = loadLatestSnapshot(accountId, asOfTime)
    if snapshot is null:
        return fullRecompute(accountId, asOfTime)

    delta = sumLedgerEntries(
        accountId,
        from = snapshot.createdAt,
        to = asOfTime,
        status = 'POSTED'
    )
    return snapshot.balance + delta

注意：增量流水必须只统计“已入账”状态，未入账、已撤销、待审核的流水不能计入，否则余额会虚增。

四、缓存策略与一致性要求

余额是高频读取对象，缓存几乎不可避免。但缓存引入后，一致性成为核心挑战。常见策略包括：

读缓存 + 写失效：流水入账后使对应账户缓存失效，下次读取时重建。
版本号控制：余额缓存带版本号，流水写入时递增版本，读取时校验版本。
短 TTL 兜底：即使失效逻辑遗漏，短过期时间也能限制脏数据窗口。
快照定期固化：按小时或按日生成快照，降低重算成本。

一致性要求取决于业务场景。提现校验通常要求强一致或近实时一致；报表展示可以接受最终一致。关键是要明确每个场景的一致性等级，而不是一刀切。

常见误区：把缓存余额当作唯一真相。一旦缓存与流水不一致，必须以流水为准重建，缓存永远只是加速层。

五、性能权衡与复盘

余额派生的本质是在准确性、延迟和成本之间做权衡。全量重算最准但最慢；实时增量最快但并发复杂；快照 + 增量是折中方案。实际系统中，往往组合使用：热账户走实时增量，冷账户走快照 + 增量，对账时走全量重算。

一个典型复盘场景：某系统提现时读取缓存余额，但流水入账后缓存失效消息丢失，导致用户看到旧余额并成功提现，最终账面透支。修复方案是引入版本号校验，并在提现前强制走一次“快照 + 增量”校验。这说明：缓存可以加速读取，但不能替代一致性校验。

掌握余额派生，关键记住三句话：流水是唯一真相；余额是可重建的投影；缓存和快照都是为性能服务的辅助手段，不能颠倒主次。