资金系统设计实战：从余额模型、幂等到每日对账的完整落地

凌晨两点零七分手机上的报警把我从睡梦里拽起来清结算对账任务显示本地流水比渠道账单多了一笔金额是 0.03 元。0.03 元看起来像个笑话但干过资金系统的人都明白这个数字背后要么是哪个调用链路的边界没处理干净要么是流水表里多了一条不该有的记录。那是我维护financial-services这套资金中台以来为数不多半夜爬起来处理事故的场景之一。这个项目的名字很朴素就叫financial-services但它实际承载的东西一点都不朴素支付网关、账务核心、清结算引擎、每日对账任务基本把一笔钱从用户点击支付到平台完成结算的完整链路都包了。今天不打算按产品文档的套路去堆架构图我想把设计时的判断逻辑、上线后踩过的坑、以及沉淀下来的工程习惯讲清楚。如果你正在做支付、交易、钱包这类系统或者正打算把普通业务系统升级成资金系统这篇内容应该能帮你少走不少弯路。1. 先想清楚资金系统的本质要求是什么1.1 资金系统和普通业务系统的三个本质区别很多人接手资金系统时第一反应是这不就是订单系统加个余额字段吗。这种想法害死人。普通业务系统里数据丢失了可以重建缓存穿透了可以再查一次库大不了用户重新操作一遍。但资金系统里余额多一分少一分都是事故用户的钱不是可以随便重试的数据。第一个本质区别是数据不能丢更不能错。普通业务丢了一条日志没人找你麻烦资金系统少记一笔流水月底对账对不平你就得从凌晨两点开始查。第二个区别是每一步都要经得起审计。资金系统里你没法说我 update 一下把这条记录改对就行了所有核心账务操作都是只增不改的要能回答这笔钱从哪来、到哪去、什么时候变的。第三个区别是故障必然发生但资金最终必须正确。服务器会宕机、网络会超时、支付渠道会回调重复这些都不是如果发生而是什么时候发生。资金系统真正考验的是故障之后系统能不能自己发现问题、修复差异而不是靠人工去改数据库。1.2 我定下的四条设计原则基于上面这些认识我在设计financial-services时给自己定了四条硬性原则后续所有模块都围绕它们展开。第一条核心账务只增不改。所有余额变化都必须落到流水表不允许直接修改历史流水不允许删流水。哪怕打错了一笔账也只能通过一笔冲正流水去抵掉不能物理删除。第二条金额一律用整数最小单位存储。不要用 float、double 存钱这是写过账务系统的人都懂的铁律后面我会专门说为什么。第三条状态变化必须由状态机驱动。订单状态、支付状态、结算状态全部走预先定义好的状态迁移不允许在业务代码里随意 if-else 乱跳状态。第四条所有外部依赖都必须支持重放。渠道回调可能丢、消息队列可能积压、下游系统可能超时所以任何一次资金操作都必须能通过本地记录重新补推、重新核对而不是依赖某一次的实时调用成功。这四条原则听起来简单但每一条都用教训换过。后面几章我会结合具体设计和事故复盘来展开。2. 账务核心余额模型和流水表怎么设计2.1 钱在系统里怎么存最小货币单位整数先解决最基础也最重要的问题金额用什么类型存。我刚入行那会儿见过一个老项目数据库里金额字段是float生产跑了三年账面上总有那么几分钱对不上。原因很简单二进制浮点数根本没法精确表示 0.1。你写0.1 0.2结果不是 0.3而是0.30000000000000004。一次两次看不出问题几千几万笔交易累加下来差异就出来了。在financial-services里我统一用BIGINT存分如果涉及其他币种就存该币种的最小货币单位交互层负责把元转成分底层一分一厘都是整数运算。这样既避开了浮点精度问题也避开了DECIMAL在不同数据库驱动下可能出现的隐式转换坑。存储方案精度运算风险建议FLOAT/DOUBLE不精确累加会产生微小差异禁止用于金额DECIMAL(18,2)精确事务内可用但索引和对比时需小心可选BIGINT分完全精确无需做好单元换算强烈推荐另外数据库表字段要加注释说明单位是分。这个看似废话但跨团队协作时真的有人会把你存的整数当成元来读导致报表数据凭空大一百倍。2.2 账户和流水两张表怎么设计账户表的核心结构我贴一下这是当时第一版上线就直接用了很久的表结构CREATE TABLE account ( account_id BIGINT NOT NULL COMMENT 账户ID, user_id BIGINT NOT NULL COMMENT 用户ID, currency VARCHAR(8) NOT NULL DEFAULT CNY COMMENT 币种, available_balance BIGINT NOT NULL DEFAULT 0 COMMENT 可用余额单位分, frozen_balance BIGINT NOT NULL DEFAULT 0 COMMENT 冻结余额单位分, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, created_at DATETIME NOT NULL COMMENT 创建时间, updated_at DATETIME NOT NULL COMMENT 更新时间, PRIMARY KEY (account_id), UNIQUE KEY uk_user_currency (user_id, currency) ) ENGINEInnoDB COMMENT 账户余额表;流水表更重要所有余额变化都记录在这里CREATE TABLE account_ledger ( id BIGINT NOT NULL AUTO_INCREMENT, account_id BIGINT NOT NULL COMMENT 账户ID, biz_type VARCHAR(32) NOT NULL COMMENT 业务类型如 PAY_ORDER, ref_id VARCHAR(64) NOT NULL COMMENT 业务单据ID如订单号, change_amount BIGINT NOT NULL COMMENT 变更金额单位分正负表示方向, balance_before BIGINT NOT NULL COMMENT 变动前余额, balance_after BIGINT NOT NULL COMMENT 变动后余额, occurred_at DATETIME NOT NULL COMMENT 发生时间, PRIMARY KEY (id), UNIQUE KEY uk_biz (account_id, biz_type, ref_id), KEY idx_account_time (account_id, occurred_at) ) ENGINEInnoDB COMMENT 账户流水表只增不删;为什么不直接存一个最终余额就完事因为余额是可推导的流水才是事实。假设哪天程序出 bug 把余额算错了只要流水还在我们就能重放流水把它修回来。反过来如果只有余额没有流水那对不起谁也说不清这笔钱怎么变成这个数的。流水表里我特意加了balance_before和balance_after虽然理论上可以通过累加算出来但显式存一份能极大方便对账排查。2.3 并发扣款怎么保证不超扣这是资金系统最容易翻车的场景也是我把这条单独拎出来说的原因。很多新手写扣款逻辑是三步走先查余额判断够不够再 update 余额。这种写法在并发场景下一定会出问题。想象两个请求同时查到余额 100 元同时判断够扣 80 元然后都执行扣款最后余额变成 -60 元。正确做法是把判断余额和扣款合成一条原子 SQLUPDATE account SET available_balance available_balance - #{amount}, version version 1, updated_at NOW() WHERE account_id #{accountId} AND available_balance #{amount};这条语句执行的返回值是关键affected rows 1说明扣款成功且余额足够affected rows 0说明余额不足或者账户不存在。在同一个事务里紧接着写入一条对应的流水记录。这里有两个细节要注意事务内先 update 账户表再 insert 流水表避免多个事务互相持有对方需要的锁导致死锁同时account_id上的行锁会串行化对同一个账户的并发扣款这是数据库层面保证的资金安全底线。3. 支付链路的幂等与状态机设计3.1 订单状态机怎么定钱的事儿不能想一出是一出订单状态尤其要严格。在financial-services里我把支付订单的状态收敛成下面这几个所有状态迁移都走统一的状态机服务不允许业务代码里直接改状态字段。当前状态含义允许迁移到的状态CREATED订单已创建未发起支付PAYING, CLOSEDPAYING支付中已请求渠道SUCCESS, FAILED, CLOSEDSUCCESS支付成功REFUNDING, CLOSEDREFUNDING退款处理中REFUNDEDREFUNDED退款成功CLOSED终态FAILED支付失败CLOSEDCLOSED已关闭终态设计这个状态机的核心原则是状态只能向前走不能回退。比如一个订单已经到 SUCCESS那么渠道再乱发一个用户取消的回调来就不应该把订单状态改回 CREATED。乱序、重复的回调是支付系统里最常见的外部干扰状态机就是用来挡住这些干扰的第一道闸门。3.2 回调乱序和重复幂等是唯一出路之前有人问过我支付渠道的回调能不能保证有序、不重复答案是别指望。HTTP 回调天然可能延迟、乱序、重复渠道也不保证 exactly-once。你在回调处理里做幂等不是给渠道面子是在保护自己的数据和下游系统。处理回调的伪代码大致是这样def handle_callback(order_id, channel_txn_id, amount): with db_transaction(): order lock_order_by_id(order_id) # 状态机校验只有 PAYING 才允许走到 SUCCESS if order.status ! PAYING: return # 金额校验渠道回调金额必须等于订单金额 if amount ! order.amount: return # 更新订单状态 update_order_status(order_id, SUCCESS) # 写入账户流水account_ledger 表的唯一键保证同一笔回调用例只写一次 write_ledger_record(order) send_paid_event(order_id)这里面每个环节都有讲究。lock_order_by_id是开启事务后先对主键行加锁防止两个回调同时进入后续逻辑状态机校验保证乱序回调被拒绝金额校验防止渠道拿一笔错误金额来洗状态。最后写流水的唯一约束(account_id, biz_type, ref_id)是整个链路兜底哪怕上游逻辑被并发钻了空子数据库的唯一键也能挡住重复流水。还有个大坑不要在事务里直接调用外部系统。我见过有的同学在回调处理方法里事务还没提交就调下游通知接口结果下游处理慢数据库连接被长时间占用事务超时回滚回调又被渠道重试恶性循环。正确做法是事务内只更新本地状态、写本地流水事务提交后再发事件或消息。3.3 本地消息表做最终一致性支付成功之后下游订单系统、积分系统、通知系统都想知道这个结果。如果直接同步调用任何一个下游出问题都会让支付回调本身失败如果等事务提交后再发 MQ又存在事务提交了但消息没发出去或者消息发出去了但事务回滚了的一致性问题。我们的方案是本地消息表也叫 outbox 模式。在支付成功那个事务里除了更新订单状态、写资金流水还写一条outbox_event记录这三个操作同生共死CREATE TABLE outbox_event ( id BIGINT AUTO_INCREMENT PRIMARY KEY, event_type VARCHAR(32) NOT NULL, payload TEXT NOT NULL, status TINYINT NOT NULL DEFAULT 0 COMMENT 0待发送 1已发送 2死信, retry_count INT NOT NULL DEFAULT 0, next_retry_time DATETIME NOT NULL, created_at DATETIME NOT NULL ) ENGINEInnoDB COMMENT 本地事件表;后台有一个扫表任务定时把status 0的记录捞出来投递给 MQ。消费端最重要的规矩是消息可以重复但不能不幂等消费方必须根据业务 ID 做去重。比如订单系统收到order.paid事件后先查本地有没有处理过处理过就直接返回成功而不是再执行一遍加积分、发短信之类的动作。这套模式的本质是用本地事务 定时任务 至少一次投递 消费幂等换最终一致。它不优雅但非常可靠我到现在依然觉得它是资金系统里最值得优先采用的一致性方案。4. 清结算与对账任务每天凌晨必须跑平4.1 对账主流程拉账单、标准化、比对、出差错支付系统不是钱扣成功了就完事。渠道侧有渠道侧的系统我们侧有我们侧的系统两边记录完全可能对不上。所以每天必须有对账任务把两边拉平。financial-services的对账任务在 T1 日凌晨一点左右开始跑。之所以选这个时间点是因为深夜交易量低渠道账单基本已经完整不容易出现这边还没记账、那边已经开始对的中间态。主流程按下面几步走第一步拉取渠道账单文件。每个渠道的格式都不一样有 CSV、有 Excel、有加密的专有格式需要做一层标准化的解析统一成内部的原始账单表。第二步把渠道账单和本地account_ledger按业务单据号关联比对。我这里的比对维度是本地有流水但渠道没有、渠道有记录但本地没有、两边金额不一致、两边状态不一致。第三步差异写入差错表按类型自动或人工处理。对账的核心产出不是一个 0 差异的报表而是差异能及时被发现并能走到处理闭环。4.2 对账差异的几种典型类型差异类型可能原因处理方式本地有、渠道无本地支付成功但渠道账单缺失可能是渠道当日账单不完整先挂起向渠道方核实防止资金在途渠道有、本地无渠道扣款成功但回调丢失本地没生成成功流水视为未达账人工补单或自动补记金额不一致渠道返回的成功金额和订单金额不同高风险直接阻断人工介入状态不一致本地是失败渠道显示成功以渠道为准走冲正重记重新入账第四步对账无误的批次生成结算单进入清分汇总。到这里当天的资金流向才算真正闭环。4.3 对账任务的两个工程细节第一个细节是给流水表加业务日期字段。一开始我直接用created_at去查昨天的流水后来发现凌晨对账时在线交易还在跑刚好卡在跨日的边界导致同一个订单可能被对账任务和在线事务同时操作。后来我加了biz_date字段写流水时显式带上业务日期对账任务一律按biz_date过滤彻底隔离了日切问题。第二个细节是任务只能有一个执行者。对账任务按理是个离线任务但如果部署了多台应用实例又没有全局锁凌晨两台机器同时触发对账那差异报表会乱成一锅粥。我用的方案是数据库分布式锁在对账任务启动时往一张task_lock表里插入一条带唯一约束的任务记录插入成功才继续执行失败就退出等待。5. 生产环境的几个典型事故复盘5.1 事件一并发扣款把用户余额扣成了负数这个坑发生在项目上线两周后的一个运营活动日。用户集中参加秒杀一个账户同时收到多笔扣款请求。我们当时的代码还是先查余额再计算再更新的老写法结果瞬间大量请求读到同一个旧余额实际扣款总额远超账户余额。客服电话被打爆后台一查出现了一批余额为负的账户。修复不复杂全部扣款逻辑改成前面说的UPDATE ... WHERE available_balance #{amount}原子操作同时给扣款业务加幂等键同一个业务单据号不能重复扣款。但这次事故的教训很深刻资金系统的每一行代码都要默认自己正运行在并发环境下。哪怕你今天只有一个实例、没有秒杀活动明天可能就有一个运营脑袋一拍上线大促。5.2 事件二支付成功后的回调重试风暴还有一次支付渠道回调一切正常订单状态也更新成功了问题出在我们自己身上。收到支付成功回调后我们直接在回调方法里同步通知下游订单中心订单中心接口超时回调任务重试重试又超时形成循环。最夸张的时候一个订单触发了几十次重复的通知请求把下游服务直接打挂。修复方案是把处理回调和通知下游解耦回调里只做订单状态更新和流水写入然后把支付成功事件写进 outbox 表由消息任务异步推送。同时给所有重试加上指数退避和最大次数超过最大次数就进死信队列人为介入。你看这个问题本质上不是渠道的问题而是我们自己把同步耦合带进了异步场景。5.3 事件三凌晨对账读到不一致的当日流水有一段时间对账差异率莫名其妙升高查了半天发现不是资金错了而是对账任务本身的问题。我们的应用是多实例部署对账任务没有加锁每天凌晨可能有两台机器同时对同一批流水做比对。更要命的是对账任务用created_at过滤当天流水边跑边有新的交易写进来导致同一个订单一会儿有、一会儿没有。解决思路前面已经提到了加biz_date固定业务日期对账任务从头到尾只读这个字段再用分布式锁保证同一时刻只有一个对账任务在执行。这件事让我意识到对账任务本身也是资金系统的一部分它自己也得先保证幂等和隔离。5.4 关于时间戳不要用应用服务器时间当交易时间最后这个坑不是事故但比事故还隐蔽。有两台应用服务器的系统时间漂移了导致同一笔交易的流水时间和订单时间差了三个小时。虽然账没算错但排查问题时非常混乱。后来我立了一条规矩所有涉及资金的关键时间字段一律由数据库生成或由业务请求显式传入禁止直接取应用服务器本地时间。系统时钟可能被运维调整、可能因为 NTP 同步跳变这些在普通系统里无所谓在资金系统里都会变成说不清的悬案。6. 上线后我建议重点盯的指标和值班节奏6.1 核心监控指标资金系统上线后我不太关心日活PV这类业务指标我盯的是下面这些指标报警建议为什么要盯对账差异笔数大于 0 就报警钱对不上是资金系统最直接的故障信号支付成功率环比下跌超过 2% 触发用户侧感受最敏感也能反映渠道健康回调重复率超过 5% 需要排查幂等策略可能失效消息队列积压超过 1000 或延迟超 5 分钟支付成功事件可能无法及时送达下游数据库锁等待平均超过 200ms并发更新同一账户的锁竞争严重清算任务完成耗时超过计划窗口影响月度结算和报表产出对账差异笔数这条我特别强调一下只要它不为 0不管差异金额多大都必须有人去看一眼。0.03 元可能只是一个小 bug但它背后可能是整类边界情况没覆盖这次是 0.03下次可能就是三万。6.2 预警分级和人工操作的纪律报警多了会让人麻木所以我做了分级P0 是资金差错类比如对账有差异、余额出现负数、清结算任务失败P1 是核心链路不可用比如支付网关超时率飙升、订单状态无法更新P2 是性能劣化类比如慢查询增多、MQ 积压但还在承受范围内。P0 必须 7x24 实时通知到人P1 也要尽快处理P2 在值班日报里跟踪。还有一条纪律任何直接修改数据库里资金数据的操作都必须有审批、有操作日志、有影响评估。线上出问题时大家第一反应往往是我直接改一条余额不就行了。这句话我听一次怕一次因为人工改库 99% 都是新的风险引入点。我们的做法是所有修正操作必须走脚本脚本要同时输出反向操作的 SQL确保万一改错了还能回退。6.3 定期演练验证系统能不能自己恢复最后分享一个我保持至今的习惯每个季度做一次故障演练。断掉支付渠道的模拟服务删掉一半 MQ 消息人为让对账任务对一半失败然后观察系统能不能通过重放、补推、重新对账把自己拉回一致状态。演练的本质是回答一个问题如果某台机器在写一半的时候断电重启系统能不能自己发现差异并恢复。这个问题如果答案是不能说明你还在靠运气维护资金安全。我在financial-services项目里受益最大的不是架构多先进、技术多新而是这套流水只增不改、状态机驱动、本地消息表、每日对账、定期演练的组合拳。资金的本质是不确定性而工程的作用就是把这些不确定性一个接一个地变成确定性。