📚 课程目录第1章课程导入

1. 课程导入

在金融系统中，Ledger（总账）不是一张简单的数据表，而是整个业务体系的“事实来源”。无论是支付、清结算、借贷、理财还是账务对账，最终都要落到一个问题上：每一笔资金变动是否被准确、完整、可追溯地记录下来，并且能够随时派生出可信的余额。本课程围绕“不可变流水”与“余额派生”两条主线展开，帮助你把账务系统从“能记账”提升到“可审计、可回溯、可扩展”。

核心命题：流水是事实，余额是视图。事实只能追加，不能篡改；视图可以重算，但必须可验证。

一、金融Ledger的核心价值

传统业务系统常把“余额”当作主数据直接更新，例如用户充值100元，就把账户余额从500改成600。这种做法在简单场景下可行，但在金融级场景中会带来三个致命问题：无法追溯、无法审计、无法重算。一旦出现争议或数据异常，你无法回答“这600元是由哪些事件构成的”。

金融Ledger的核心价值在于把“资金变动”抽象为不可变流水（Immutable Journal Entry），每一笔流水都是一次已发生事实的永久记录。余额不再被直接修改，而是由流水按规则派生出来的结果。这样做的收益非常直接：

可审计：任何余额都能追溯到构成它的每一笔流水，满足内审与监管要求。
可重算：当派生规则变更或发现历史错误时，可以从流水重新计算余额，而不是手工修数。
可扩展：新增业务线、币种、账户类型时，只需扩展流水模型与派生规则，不必推翻底层账务。
可对账：流水与外部渠道、银行、清算机构形成一一对应的核对基础。

因此，Ledger不是“记录结果”的系统，而是“记录过程”的系统。过程可信，结果才可信。

二、不可变流水与余额派生的整体知识框架

本课程的知识框架可以概括为“一条主线、两个视角、三层结构”。一条主线是从交易到流水再到余额的数据链路；两个视角是会计视角（借贷平衡、科目、分录）与工程视角（存储、并发、幂等、重算）；三层结构是接入层、流水层、派生层。

从工程实现看，接入层负责把业务动作翻译成标准分录；流水层负责持久化不可变事实；派生层负责把事实投影成余额、账单、报表等视图。三层之间通过明确的契约解耦，任何一层的变化都不应破坏其他层的正确性。

三、方法流程：从一笔交易到可信余额

下面用一笔“用户充值100元”的典型场景，串起完整流程。假设用户账户为A，平台收款账户为B，币种为CNY。

接收请求：支付网关回调携带业务单号 PAY20250101-001，金额100元。
幂等校验：以业务单号作为幂等键，若已存在则直接返回成功，避免重复入账。
生成分录：按借贷平衡规则生成两条分录：借：平台收款账户B 100；贷：用户账户A 100。
追加流水：将分录写入不可变流水表，写入后不允许更新或删除。
派生余额：根据流水增量更新余额视图，或异步重算余额快照。
对账校验：定时将流水与渠道账单核对，发现差异进入差错处理。

-- 不可变流水表（简化）
CREATE TABLE journal_entry (
  entry_id      BIGINT PRIMARY KEY,
  biz_no        VARCHAR(64) NOT NULL UNIQUE,  -- 幂等键
  account_id    VARCHAR(64) NOT NULL,
  direction     VARCHAR(8)  NOT NULL,         -- DEBIT / CREDIT
  amount        DECIMAL(18,2) NOT NULL,
  currency      VARCHAR(8)  NOT NULL,
  created_at    TIMESTAMP   NOT NULL,
  status        VARCHAR(16) NOT NULL          -- POSTED / REVERSED
);

-- 余额派生视图（简化）
SELECT account_id, currency,
       SUM(CASE WHEN direction='CREDIT' THEN amount ELSE -amount END) AS balance
FROM journal_entry
WHERE status='POSTED'
GROUP BY account_id, currency;

注意：余额视图是“派生结果”，不是“事实本身”。当派生逻辑变化时，可以基于同一份流水重新计算，这正是不可变流水带来的最大自由度。

四、案例与场景：为什么不能直接改余额

假设某系统直接更新余额，运营人员误操作把用户余额从500改成5000。三天后用户提现，系统无法解释这4500元的来源。若采用流水模型，任何余额变动都必须对应一笔分录，误操作只能通过“冲正分录”修正，而不是直接改数。冲正分录本身也是一条不可变流水，审计时能清晰看到“错误发生—冲正—恢复”的完整链路。

对比维度	直接改余额	不可变流水+余额派生
可追溯性	差，无法还原构成	强，每笔余额可追溯
审计支持	依赖日志，易缺失	流水即审计底稿
错误修复	直接改数，风险高	冲正分录，留痕可查
重算能力	几乎不可能	可从流水全量重算
并发安全	行锁竞争严重	追加写+异步派生，扩展性好

五、常见误区与复盘

误区一：把余额表当主数据，流水只是“日志”。正确做法是流水为主、余额为派生视图。

误区二：认为不可变就是“永不删除”。不可变指业务事实不可篡改，但可通过冲正、红冲等反向分录修正，修正过程同样留痕。

误区三：忽略幂等。渠道回调可能重复，必须用业务单号做唯一约束，否则会重复入账。
误区四：派生与流水强耦合。派生层应可独立重算，避免把复杂业务逻辑塞进流水写入路径。
误区五：只做单边记账。金融Ledger必须借贷平衡，单边流水无法自证正确。

复盘来看，Ledger设计的本质是用不可变事实换取长期可信。短期看，追加写和派生计算比直接改余额更复杂；长期看，它让系统在面对审计、对账、故障恢复和业务扩展时拥有真正的底气。接下来的章节将围绕流水模型设计、借贷平衡、幂等与并发、余额派生策略、重算与对账等主题逐一展开，帮助你把这套体系真正落地到生产系统。