1. 先想清楚financial-services 到底要解决什么问题先说一句实在话financial-services 这个标题乍一听像大厂年度战略PPT里的词但落到真实项目里拆开看无非就是账务、支付、风控、对账、报表这几件事。我上手过一个小型金融科技服务平台的后端全流程改造当时团队业务是聚合支付加钱包余额一开始没有独立服务所有跟钱相关的逻辑都散落在各个业务代码里订单模块里直接改余额、活动模块里直接发优惠券、用户模块里自己记账。结果就是线上出了好几起余额对不上的事故排查起来要把十几个服务翻个底朝天。后来我把这些功能从业务系统里抽出来沉淀成一个独立的金融服务模块——对外提供账户开通、余额查询、充值、提现、消费、退款、冻结、解冻、对账文件生成这几类标准能力。你可以把它理解成一套“通用资金中台”任何一个需要跟资金打交道的业务方都通过统一接口来调用不再自己碰数据库里的金额字段。这篇博文我会把整个项目的设计思路、核心实现、参数计算和踩坑过程完整写出来。适合两类人看一类是正在做类似钱包、支付、清结算系统的后端开发另一类是准备把“账务能力”从业务代码里抽出来做独立服务的架构师。内容不涉及具体监管政策纯粹从工程落地和技术实现角度聊。2. 整体架构与核心模块的设计思路2.1 模块拆解先划清楚边界再谈代码我的做法是先抽象出六个核心模块每个模块只负责一件大事模块职责关键点账户服务开户、销户、账户信息查询、账户状态管理一个用户可能多个账户必须区分账户类型交易服务充值、消费、退款、转账、冻结/解冻所有资金变动必须走统一流水禁止直接改余额支付路由对接第三方支付渠道、选择最优渠道、发起支付渠道配置要支持热更新路由规则要可配置风控服务交易额度校验、频次校验、黑白名单、异常交易拦截风控规则要可扩展最好做成规则引擎清结算与对账日终对账、差错处理、结算单生成对账是金融服务里最容易出事也是最容易被忽视的环节报表与查询交易流水查询、账户余额查询、财务报表导出查询性能必须单独优化不能直接查业务库模块拆完之后有一个很明确的规矩业务系统不能直接读写账户余额表只能通过交易服务发起请求。所有涉及资金的操作必须在金融服务内部完成“流水记录 余额变更 账务日志”三个动作保证每一分钱都有据可查。这样做的好处是出问题的时候只需要查金融服务自己的日志和流水不用再跨系统翻证据。2.2 技术选型实用主义优先不追求花哨技术栈我选了比较稳妥的一套Java 17 Spring Boot 3.x MyBatis-Plus MySQL 8.0 Redis RabbitMQ。项目不大不需要微服务那一套复杂治理单服务部署、按功能拆包就够了。数据库用 MySQLInnoDB 引擎事务隔离级别默认的 REPEATABLE READ 在绝大多数账务场景下够用。Redis 主要用来做分布式锁和幂等控制比如“用户点击充值按钮重复提交”这种问题用 Redis setnx 就能挡住。MQ 用来做异步对账和通知比如支付结果回调之后先落库再发消息让对账服务去拉取渠道账单避免同步等待第三方接口拖垮主流程。这里有个设计决策要说清楚我没有用 Seata 这类分布式事务框架。原因是这个服务内部的所有资金操作都控制在同一个 MySQL 事务里完成不需要跨服务分布式事务而外部渠道的调用比如第三方支付本质上是一个“最终一致”的过程需要通过状态机加定时任务来补偿而不是靠强事务锁住。这个领域里不做分布式事务反而少了很多坑。2.3 交易状态机先定义清楚再写逻辑资金类系统最怕的就是状态混乱。我的做法是给每笔交易定义一套完整的状态流转不允许代码里随意乱跳。支付交易的状态枚举CREATED已创建→ PROCESSING处理中→ SUCCESS成功 → FAILED失败 → CLOSED关闭/超时退款交易的状态枚举REFUND_CREATED退款已申请→ REFUND_PROCESSING退款处理中→ REFUND_SUCCESS退款成功 → REFUND_FAILED退款失败冻结/解冻操作同样有独立状态FROZEN已冻结→ UNFROZEN已解冻或 DEDUCTED冻结资金被扣走。为什么要花这么大力气定义状态机因为资金操作是奔着“最终一致”去的。用户发起一笔提现请求先落库标记 CREATED然后调用渠道接口渠道可能异步返回结果也可能一直不返回。这个时候如果没有状态机指导代码里就会出现各种 if-else 判断到底能不能重试、能不能退款、能不能关单。有了状态机之后所有判定都变成查状态逻辑清晰而且不容易漏分支。状态机要写在服务层统一维护禁止在业务方自行修改状态。3. 核心数据模型从表结构到字段级别的设计3.1 账户表与流水表每一分钱都要能追溯资金系统的数据模型核心是三张表账户表、交易流水表、账务日志表。账户表设计简化版CREATE TABLE account ( id BIGINT PRIMARY KEY AUTO_INCREMENT, account_no VARCHAR(32) NOT NULL COMMENT 账户号, user_id VARCHAR(32) NOT NULL COMMENT 用户ID, account_type TINYINT NOT NULL COMMENT 账户类型1-余额账户2-冻结账户3-积分账户, balance DECIMAL(18,2) NOT NULL DEFAULT 0.00 COMMENT 可用余额, frozen_amount DECIMAL(18,2) NOT NULL DEFAULT 0.00 COMMENT 冻结金额, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态1-正常2-冻结3-销户, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_account_no (account_no), KEY idx_user_type (user_id, account_type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意几个细节balance用 DECIMAL(18,2)金额字段绝对不能用 FLOAT/DOUBLE精度问题会让你对账对到怀疑人生。version字段必须预留这是乐观锁的关键后面讲并发的时候会细说。account_no作为账户对外标识与内部自增主键id解耦避免外部业务方猜测真实数据量。交易流水表是资金系统的“账本”每笔资金变动都要往里写一条记录CREATE TABLE trade_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, flow_no VARCHAR(64) NOT NULL COMMENT 流水号全局唯一, account_no VARCHAR(32) NOT NULL COMMENT 账户号, trade_type VARCHAR(32) NOT NULL COMMENT 交易类型RECHARGE/CONSUME/REFUND/WITHDRAW/FREEZE/UNFREEZE, amount DECIMAL(18,2) NOT NULL COMMENT 变动金额正数入账负数扣款, before_balance DECIMAL(18,2) NOT NULL COMMENT 变动前余额, after_balance DECIMAL(18,2) NOT NULL COMMENT 变动后余额, status VARCHAR(16) NOT NULL COMMENT 流水状态SUCCESS/FAILED/PROCESSING, out_trade_no VARCHAR(64) DEFAULT NULL COMMENT 外部订单号用于幂等, remark VARCHAR(255) DEFAULT NULL COMMENT 备注, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_flow_no (flow_no), UNIQUE KEY uk_out_trade_no (out_trade_no), KEY idx_account_created (account_no, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;流水表里记录了变动前余额和变动后余额这是为了对账的时候能方便地还原任意时间点的账户状态。流水号用雪花算法生成确保全局唯一。业务方调用时如果传了out_trade_no这个字段用来做幂等控制同一笔外部订单号不允许重复入账。3.2 账务日志表审计用查询慢一点没关系账务日志表和交易流水表看着像其实职责不同。流水表是“业务视角”描述发生了什么交易账务日志表是“核算视角”记录会计意义上的借贷明细。我设计了一张简化版的账务日志表包含journal_no、account_no、direction借/贷、amount、biz_flow_no、journal_type充值入账/消费扣款/退款冲正等。这张表的数据只增不改不提供业务查询入口仅供审计和日终核算使用。它的写入频率高但这个表不需要跟业务表一起做复杂关联查询所以独立存储、独立分表都没有问题。3.3 限额与费率参数用一套规则表驱动资金系统做久了就会发现很多逻辑本质上是参数规则而不是硬编码。我维护了一张限额规则表和一张费率规则表。限额规则表的结构如下字段说明示例值rule_type规则类型单笔限额/单日累计限额/单月累计限额SINGLE_LIMITuser_level用户等级不同等级限额不同普通用户/高级用户channel_code渠道编码不同渠道限额不同ALIPAY/WECHAT/BANK_CARDmax_amount最大允许金额50000.00min_amount最小允许金额1.00effective_time生效时间2024-01-01 00:00:00expire_time失效时间2024-12-31 23:59:59用一个费率的实际计算例子来说明。假设平台按交易金额向商户收取手续费阶梯费率如下单笔金额 0~1000 元收 0.6%1000~5000 元收 0.5%5000 元以上收 0.4%最低收费 0.1 元。有一笔 3200 元的消费计算过程是3200 元落在 1000~5000 区间费率 3200 × 0.5% 16 元。如果是一笔 50 元的消费费率 50 × 0.6% 0.3 元高于最低收费按 0.3 元收取。如果一笔交易金额为 5 元费率 5 × 0.6% 0.03 元低于最低收费 0.1 元则按 0.1 元收取。这里的核心逻辑是阶梯费率必须按“落入区间”的整笔金额计算不能分段累乘——很多人误解成“1000 元以内按 0.6%超出部分按 0.5%”做出来的计费跟商户对不上账这个问题我在第 5 章还会再提。规则表的好处是运营改费率、改限额不用发版直接改数据库记录就能生效。规则引擎层加一层缓存Redis 存规则版本号版本号变更自动刷新本地缓存既保证实时性又减少数据库压力。4. 关键实现从余额变更到对账补偿4.1 余额变更一个事务里完成“流水 余额 日志”资金操作里最容易写错的就是余额更新逻辑。很多新手会这样做先查账户余额算出新余额再 update。这在低并发下看着没问题一旦两个请求同时进来就会读到同一个余额导致最终结果错误余额莫名少了或者变成负数。正确做法是在一个数据库事务里完成“插入流水记录 乐观锁更新余额”并且必须在查询余额时带条件校验Transactional(rollbackFor Exception.class) public void deductBalance(String accountNo, BigDecimal amount, String bizNo) { // 1. 幂等检查外部订单号是否已处理 Integer count tradeFlowMapper.countByOutTradeNo(bizNo); if (count ! null count 0) { throw new DuplicateTradeException(重复交易); } // 2. 插入流水记录状态为 SUCCESS Account account accountMapper.selectByAccountNo(accountNo); BigDecimal beforeBalance account.getBalance(); BigDecimal afterBalance beforeBalance.subtract(amount); if (afterBalance.compareTo(BigDecimal.ZERO) 0) { throw new InsufficientBalanceException(余额不足); } tradeFlowMapper.insert(buildFlow(bizNo, accountNo, amount.negate(), beforeBalance, afterBalance)); // 3. 乐观锁更新余额version 作为条件 int rows accountMapper.optimisticDeduct(accountNo, amount, account.getVersion()); if (rows 0) { throw new ConcurrentUpdateException(并发更新失败请重试); } // 4. 插入账务日志 journalMapper.insert(buildJournal(accountNo, DEBIT, amount, bizNo)); }optimisticDeduct的 SQL 长这样UPDATE account SET balance balance - #{amount}, version version 1 WHERE account_no #{accountNo} AND version #{version} AND balance #{amount}注意这里加了balance amount的条件数据库层面做一次余额校验。乐观锁失败说明有并发修改直接抛异常让上层重试而不是自己再查一次覆盖写。这套逻辑我在生产环境实测QPS 在 2000 左右的情况下没有出现过一次余额错乱。4.2 支付路由与回调处理主动查单比被动等回调可靠支付路由模块做了一个渠道配置表维护每个渠道的优先级、手续费率、单笔限额、维护状态。发起支付时系统根据“金额在限额内 渠道可用 费率最优”三个条件选出一个渠道然后调用该渠道的接口。回调处理是资金系统最考验细节的地方。第三方渠道回调可能重复、可能乱序、可能延迟还可能一直不来。我的做法是回调接口先验签验签失败直接返回失败。验签通过后根据回调里的商户订单号查本地订单。本地订单已经是 SUCCESS 状态的直接返回成功不做重复处理——这是幂等关键。本地订单是 PROCESSING 状态的才真正更新订单状态、入账、写流水。回调处理结束后发一条 MQ 消息触发后续的账户通知、短信通知等异步动作。光靠被动回调不保险我加了一个定时补偿任务每 5 分钟扫描一次超过 3 分钟还处于 PROCESSING 状态的订单调用渠道查单接口获取真实状态。如果渠道反馈支付成功但本地一直没收到回调就把这笔订单补成成功并完成入账。这个“主动查单”机制救过我很多次第三方回调丢失、网络分区这类问题靠补偿任务都能兜住。4.3 对账任务T1 日终自动核对每一笔交易对账是资金系统里最繁琐又最不能省的一环。我的对账流程是每天凌晨 2 点定时任务从第三方渠道下载前一天的交易账单解析成统一格式然后与本地交易流水执行逐笔匹配。对账的核心匹配规则有四个维度维度说明金额一致渠道账单金额与本地流水金额必须一致方向一致渠道记为收款本地也要记为收款订单号一致渠道商户订单号与本地订单号能对上状态一致渠道“成功”则本地必须“成功”对账结果分成几类匹配成功、本地有渠道无本地多账、渠道有本地无渠道多账、金额不一致。对出现的差异系统自动生成差错记录推送到人工处理队列。短款渠道扣了钱但本地没有记录优先自动排查是否回调延迟如果查单发现支付成功就自动补单。长款本地有记录但渠道没这笔交易通常是测试数据或渠道异常需要人工介入。对账做完一定要生成一份汇总报表昨日交易总笔数、成功笔数、失败笔数、总金额、手续费总额、差异笔数。我见过太多系统上线半年都没做过一次完整对账等到月底财务要数据的时候才发现差异几十万那种排查过程极其痛苦。5. 常见问题与排查技巧实录5.1 余额对不上账第一反应别改数据有一次线上反馈用户余额不对客服那边说用户充了 100 元但余额只增加了 80 元。我第一反应不是直接改数据库而是让运维拉出这个用户的全部流水记录对准每个时间点逐笔核对。最后发现是接了一个营销活动充值 100 元赠送 20 元优惠券优惠券不算余额但用户端文案表述有歧义造成误解。这暴露了两个问题产品文案和账务模型没对齐以及营销赠送逻辑没有统一走账务服务。后来我把所有赠送类操作也纳入交易服务统一记录流水优惠券和余额在展示层做区分问题就再没出现过。这个案例想说明的是资金系统排查问题的第一步永远是看流水不是看余额。余额只是最终状态流水才是证据链。5.2 重复回调导致重复入账线上出现过一次严重的资金事故第三方渠道对一笔支付订单连续回调了两次第一次回调成功入账第二次回调本地订单状态已经变成 SUCCESS但因为代码里没有做好幂等校验又执行了一次入账操作用户余额凭空多了一笔钱。排查过程先靠对账发现总金额与本地流水笔数不一致然后再翻日志定位到重复回调的时间点。修复方案就是我在前面写的——回调处理里必须先判断本地订单状态已经 SUCCESS 的直接返回成功不再执行入账逻辑。这个 bug 也让我养成了一个习惯所有涉及到钱的操作入口处第一行就是幂等校验。5.3 并发扣款导致的余额变负数用户同时下单两笔共 80 元和 30 元余额只有 100 元。第一笔扣款成功余额变 20第二笔扣款在并发情况下读到旧余额 100判断余额充足直接执行扣款余额变成 -10。这个 bug 的原因就是没有用乐观锁扣款 SQL 没有带版本条件。修复方案前面已经写过update 语句里加version条件并加上balance amount的数据库判断。这里有个经验之谈并发控制不能只靠应用层的 if 判断数据库层面的条件更新才是最后一道防线。5.4 定时任务重复执行导致重复对账对账任务如果部署在多实例环境下多个实例同时启动定时任务会重复下载对账文件、重复匹配、重复生成差错单。解决方式是用 Redis 分布式锁给对账任务加一个锁标记只有拿到锁的实例才能执行。锁的过期时间要设置成大于任务最长执行时间避免任务还在跑但锁已经过期被其他实例抢走。6. 还在打磨的一些想法做这个金融服务项目我个人最大的体会有两点。第一资金系统的设计要“先严后松”。先严格定义好账户模型、状态机、幂等规则、对账机制再动手写业务代码顺序反了后面就是无穷无尽的补丁。哪怕业务方催得再急这些基础底子也不能省否则上线后的每一次故障都在为前期草率买单。第二一定要给运营和财务留一个可视化对账界面。很多开发觉得对账跑批脚本输出一个 Excel 就完事了但实际上运营和财务需要的是能按时间范围、按渠道、按交易类型筛选的查询页面能直接看到差异原因和当前处理状态。我后来补了这个管理后台财务同学的使用体验和问题反馈效率提升了好几个级别。顺带分享一个小技巧账户表的流水建议按月做分区或分表因为月累计数据量大了之后流水表查询性能会明显下降。我一开始没做分表线上跑了半年数据量到几千万查询开始卡顿后来按月份分了区问题解决。项目做到这里financial-services 的基本能力已经覆盖了大多数中小型业务对资金服务的需求。后续如果要扩展可以做多币种支持、分账系统、跨境结算等方向但底层的数据模型和工程纪律是通用的。最后说一句掏心窝的话做资金系统宁可慢一点、稳一点也不要为了赶进度跳过对账设计和幂等设计。这两个点没做好后面的每一个安稳觉都可能是暂时的。
金融服务模块设计：资金中台、交易流水与对账机制实战
1. 先想清楚financial-services 到底要解决什么问题先说一句实在话financial-services 这个标题乍一听像大厂年度战略PPT里的词但落到真实项目里拆开看无非就是账务、支付、风控、对账、报表这几件事。我上手过一个小型金融科技服务平台的后端全流程改造当时团队业务是聚合支付加钱包余额一开始没有独立服务所有跟钱相关的逻辑都散落在各个业务代码里订单模块里直接改余额、活动模块里直接发优惠券、用户模块里自己记账。结果就是线上出了好几起余额对不上的事故排查起来要把十几个服务翻个底朝天。后来我把这些功能从业务系统里抽出来沉淀成一个独立的金融服务模块——对外提供账户开通、余额查询、充值、提现、消费、退款、冻结、解冻、对账文件生成这几类标准能力。你可以把它理解成一套“通用资金中台”任何一个需要跟资金打交道的业务方都通过统一接口来调用不再自己碰数据库里的金额字段。这篇博文我会把整个项目的设计思路、核心实现、参数计算和踩坑过程完整写出来。适合两类人看一类是正在做类似钱包、支付、清结算系统的后端开发另一类是准备把“账务能力”从业务代码里抽出来做独立服务的架构师。内容不涉及具体监管政策纯粹从工程落地和技术实现角度聊。2. 整体架构与核心模块的设计思路2.1 模块拆解先划清楚边界再谈代码我的做法是先抽象出六个核心模块每个模块只负责一件大事模块职责关键点账户服务开户、销户、账户信息查询、账户状态管理一个用户可能多个账户必须区分账户类型交易服务充值、消费、退款、转账、冻结/解冻所有资金变动必须走统一流水禁止直接改余额支付路由对接第三方支付渠道、选择最优渠道、发起支付渠道配置要支持热更新路由规则要可配置风控服务交易额度校验、频次校验、黑白名单、异常交易拦截风控规则要可扩展最好做成规则引擎清结算与对账日终对账、差错处理、结算单生成对账是金融服务里最容易出事也是最容易被忽视的环节报表与查询交易流水查询、账户余额查询、财务报表导出查询性能必须单独优化不能直接查业务库模块拆完之后有一个很明确的规矩业务系统不能直接读写账户余额表只能通过交易服务发起请求。所有涉及资金的操作必须在金融服务内部完成“流水记录 余额变更 账务日志”三个动作保证每一分钱都有据可查。这样做的好处是出问题的时候只需要查金融服务自己的日志和流水不用再跨系统翻证据。2.2 技术选型实用主义优先不追求花哨技术栈我选了比较稳妥的一套Java 17 Spring Boot 3.x MyBatis-Plus MySQL 8.0 Redis RabbitMQ。项目不大不需要微服务那一套复杂治理单服务部署、按功能拆包就够了。数据库用 MySQLInnoDB 引擎事务隔离级别默认的 REPEATABLE READ 在绝大多数账务场景下够用。Redis 主要用来做分布式锁和幂等控制比如“用户点击充值按钮重复提交”这种问题用 Redis setnx 就能挡住。MQ 用来做异步对账和通知比如支付结果回调之后先落库再发消息让对账服务去拉取渠道账单避免同步等待第三方接口拖垮主流程。这里有个设计决策要说清楚我没有用 Seata 这类分布式事务框架。原因是这个服务内部的所有资金操作都控制在同一个 MySQL 事务里完成不需要跨服务分布式事务而外部渠道的调用比如第三方支付本质上是一个“最终一致”的过程需要通过状态机加定时任务来补偿而不是靠强事务锁住。这个领域里不做分布式事务反而少了很多坑。2.3 交易状态机先定义清楚再写逻辑资金类系统最怕的就是状态混乱。我的做法是给每笔交易定义一套完整的状态流转不允许代码里随意乱跳。支付交易的状态枚举CREATED已创建→ PROCESSING处理中→ SUCCESS成功 → FAILED失败 → CLOSED关闭/超时退款交易的状态枚举REFUND_CREATED退款已申请→ REFUND_PROCESSING退款处理中→ REFUND_SUCCESS退款成功 → REFUND_FAILED退款失败冻结/解冻操作同样有独立状态FROZEN已冻结→ UNFROZEN已解冻或 DEDUCTED冻结资金被扣走。为什么要花这么大力气定义状态机因为资金操作是奔着“最终一致”去的。用户发起一笔提现请求先落库标记 CREATED然后调用渠道接口渠道可能异步返回结果也可能一直不返回。这个时候如果没有状态机指导代码里就会出现各种 if-else 判断到底能不能重试、能不能退款、能不能关单。有了状态机之后所有判定都变成查状态逻辑清晰而且不容易漏分支。状态机要写在服务层统一维护禁止在业务方自行修改状态。3. 核心数据模型从表结构到字段级别的设计3.1 账户表与流水表每一分钱都要能追溯资金系统的数据模型核心是三张表账户表、交易流水表、账务日志表。账户表设计简化版CREATE TABLE account ( id BIGINT PRIMARY KEY AUTO_INCREMENT, account_no VARCHAR(32) NOT NULL COMMENT 账户号, user_id VARCHAR(32) NOT NULL COMMENT 用户ID, account_type TINYINT NOT NULL COMMENT 账户类型1-余额账户2-冻结账户3-积分账户, balance DECIMAL(18,2) NOT NULL DEFAULT 0.00 COMMENT 可用余额, frozen_amount DECIMAL(18,2) NOT NULL DEFAULT 0.00 COMMENT 冻结金额, version INT NOT NULL DEFAULT 0 COMMENT 乐观锁版本号, status TINYINT NOT NULL DEFAULT 1 COMMENT 状态1-正常2-冻结3-销户, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, updated_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, UNIQUE KEY uk_account_no (account_no), KEY idx_user_type (user_id, account_type) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;注意几个细节balance用 DECIMAL(18,2)金额字段绝对不能用 FLOAT/DOUBLE精度问题会让你对账对到怀疑人生。version字段必须预留这是乐观锁的关键后面讲并发的时候会细说。account_no作为账户对外标识与内部自增主键id解耦避免外部业务方猜测真实数据量。交易流水表是资金系统的“账本”每笔资金变动都要往里写一条记录CREATE TABLE trade_flow ( id BIGINT PRIMARY KEY AUTO_INCREMENT, flow_no VARCHAR(64) NOT NULL COMMENT 流水号全局唯一, account_no VARCHAR(32) NOT NULL COMMENT 账户号, trade_type VARCHAR(32) NOT NULL COMMENT 交易类型RECHARGE/CONSUME/REFUND/WITHDRAW/FREEZE/UNFREEZE, amount DECIMAL(18,2) NOT NULL COMMENT 变动金额正数入账负数扣款, before_balance DECIMAL(18,2) NOT NULL COMMENT 变动前余额, after_balance DECIMAL(18,2) NOT NULL COMMENT 变动后余额, status VARCHAR(16) NOT NULL COMMENT 流水状态SUCCESS/FAILED/PROCESSING, out_trade_no VARCHAR(64) DEFAULT NULL COMMENT 外部订单号用于幂等, remark VARCHAR(255) DEFAULT NULL COMMENT 备注, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_flow_no (flow_no), UNIQUE KEY uk_out_trade_no (out_trade_no), KEY idx_account_created (account_no, created_at) ) ENGINEInnoDB DEFAULT CHARSETutf8mb4;流水表里记录了变动前余额和变动后余额这是为了对账的时候能方便地还原任意时间点的账户状态。流水号用雪花算法生成确保全局唯一。业务方调用时如果传了out_trade_no这个字段用来做幂等控制同一笔外部订单号不允许重复入账。3.2 账务日志表审计用查询慢一点没关系账务日志表和交易流水表看着像其实职责不同。流水表是“业务视角”描述发生了什么交易账务日志表是“核算视角”记录会计意义上的借贷明细。我设计了一张简化版的账务日志表包含journal_no、account_no、direction借/贷、amount、biz_flow_no、journal_type充值入账/消费扣款/退款冲正等。这张表的数据只增不改不提供业务查询入口仅供审计和日终核算使用。它的写入频率高但这个表不需要跟业务表一起做复杂关联查询所以独立存储、独立分表都没有问题。3.3 限额与费率参数用一套规则表驱动资金系统做久了就会发现很多逻辑本质上是参数规则而不是硬编码。我维护了一张限额规则表和一张费率规则表。限额规则表的结构如下字段说明示例值rule_type规则类型单笔限额/单日累计限额/单月累计限额SINGLE_LIMITuser_level用户等级不同等级限额不同普通用户/高级用户channel_code渠道编码不同渠道限额不同ALIPAY/WECHAT/BANK_CARDmax_amount最大允许金额50000.00min_amount最小允许金额1.00effective_time生效时间2024-01-01 00:00:00expire_time失效时间2024-12-31 23:59:59用一个费率的实际计算例子来说明。假设平台按交易金额向商户收取手续费阶梯费率如下单笔金额 0~1000 元收 0.6%1000~5000 元收 0.5%5000 元以上收 0.4%最低收费 0.1 元。有一笔 3200 元的消费计算过程是3200 元落在 1000~5000 区间费率 3200 × 0.5% 16 元。如果是一笔 50 元的消费费率 50 × 0.6% 0.3 元高于最低收费按 0.3 元收取。如果一笔交易金额为 5 元费率 5 × 0.6% 0.03 元低于最低收费 0.1 元则按 0.1 元收取。这里的核心逻辑是阶梯费率必须按“落入区间”的整笔金额计算不能分段累乘——很多人误解成“1000 元以内按 0.6%超出部分按 0.5%”做出来的计费跟商户对不上账这个问题我在第 5 章还会再提。规则表的好处是运营改费率、改限额不用发版直接改数据库记录就能生效。规则引擎层加一层缓存Redis 存规则版本号版本号变更自动刷新本地缓存既保证实时性又减少数据库压力。4. 关键实现从余额变更到对账补偿4.1 余额变更一个事务里完成“流水 余额 日志”资金操作里最容易写错的就是余额更新逻辑。很多新手会这样做先查账户余额算出新余额再 update。这在低并发下看着没问题一旦两个请求同时进来就会读到同一个余额导致最终结果错误余额莫名少了或者变成负数。正确做法是在一个数据库事务里完成“插入流水记录 乐观锁更新余额”并且必须在查询余额时带条件校验Transactional(rollbackFor Exception.class) public void deductBalance(String accountNo, BigDecimal amount, String bizNo) { // 1. 幂等检查外部订单号是否已处理 Integer count tradeFlowMapper.countByOutTradeNo(bizNo); if (count ! null count 0) { throw new DuplicateTradeException(重复交易); } // 2. 插入流水记录状态为 SUCCESS Account account accountMapper.selectByAccountNo(accountNo); BigDecimal beforeBalance account.getBalance(); BigDecimal afterBalance beforeBalance.subtract(amount); if (afterBalance.compareTo(BigDecimal.ZERO) 0) { throw new InsufficientBalanceException(余额不足); } tradeFlowMapper.insert(buildFlow(bizNo, accountNo, amount.negate(), beforeBalance, afterBalance)); // 3. 乐观锁更新余额version 作为条件 int rows accountMapper.optimisticDeduct(accountNo, amount, account.getVersion()); if (rows 0) { throw new ConcurrentUpdateException(并发更新失败请重试); } // 4. 插入账务日志 journalMapper.insert(buildJournal(accountNo, DEBIT, amount, bizNo)); }optimisticDeduct的 SQL 长这样UPDATE account SET balance balance - #{amount}, version version 1 WHERE account_no #{accountNo} AND version #{version} AND balance #{amount}注意这里加了balance amount的条件数据库层面做一次余额校验。乐观锁失败说明有并发修改直接抛异常让上层重试而不是自己再查一次覆盖写。这套逻辑我在生产环境实测QPS 在 2000 左右的情况下没有出现过一次余额错乱。4.2 支付路由与回调处理主动查单比被动等回调可靠支付路由模块做了一个渠道配置表维护每个渠道的优先级、手续费率、单笔限额、维护状态。发起支付时系统根据“金额在限额内 渠道可用 费率最优”三个条件选出一个渠道然后调用该渠道的接口。回调处理是资金系统最考验细节的地方。第三方渠道回调可能重复、可能乱序、可能延迟还可能一直不来。我的做法是回调接口先验签验签失败直接返回失败。验签通过后根据回调里的商户订单号查本地订单。本地订单已经是 SUCCESS 状态的直接返回成功不做重复处理——这是幂等关键。本地订单是 PROCESSING 状态的才真正更新订单状态、入账、写流水。回调处理结束后发一条 MQ 消息触发后续的账户通知、短信通知等异步动作。光靠被动回调不保险我加了一个定时补偿任务每 5 分钟扫描一次超过 3 分钟还处于 PROCESSING 状态的订单调用渠道查单接口获取真实状态。如果渠道反馈支付成功但本地一直没收到回调就把这笔订单补成成功并完成入账。这个“主动查单”机制救过我很多次第三方回调丢失、网络分区这类问题靠补偿任务都能兜住。4.3 对账任务T1 日终自动核对每一笔交易对账是资金系统里最繁琐又最不能省的一环。我的对账流程是每天凌晨 2 点定时任务从第三方渠道下载前一天的交易账单解析成统一格式然后与本地交易流水执行逐笔匹配。对账的核心匹配规则有四个维度维度说明金额一致渠道账单金额与本地流水金额必须一致方向一致渠道记为收款本地也要记为收款订单号一致渠道商户订单号与本地订单号能对上状态一致渠道“成功”则本地必须“成功”对账结果分成几类匹配成功、本地有渠道无本地多账、渠道有本地无渠道多账、金额不一致。对出现的差异系统自动生成差错记录推送到人工处理队列。短款渠道扣了钱但本地没有记录优先自动排查是否回调延迟如果查单发现支付成功就自动补单。长款本地有记录但渠道没这笔交易通常是测试数据或渠道异常需要人工介入。对账做完一定要生成一份汇总报表昨日交易总笔数、成功笔数、失败笔数、总金额、手续费总额、差异笔数。我见过太多系统上线半年都没做过一次完整对账等到月底财务要数据的时候才发现差异几十万那种排查过程极其痛苦。5. 常见问题与排查技巧实录5.1 余额对不上账第一反应别改数据有一次线上反馈用户余额不对客服那边说用户充了 100 元但余额只增加了 80 元。我第一反应不是直接改数据库而是让运维拉出这个用户的全部流水记录对准每个时间点逐笔核对。最后发现是接了一个营销活动充值 100 元赠送 20 元优惠券优惠券不算余额但用户端文案表述有歧义造成误解。这暴露了两个问题产品文案和账务模型没对齐以及营销赠送逻辑没有统一走账务服务。后来我把所有赠送类操作也纳入交易服务统一记录流水优惠券和余额在展示层做区分问题就再没出现过。这个案例想说明的是资金系统排查问题的第一步永远是看流水不是看余额。余额只是最终状态流水才是证据链。5.2 重复回调导致重复入账线上出现过一次严重的资金事故第三方渠道对一笔支付订单连续回调了两次第一次回调成功入账第二次回调本地订单状态已经变成 SUCCESS但因为代码里没有做好幂等校验又执行了一次入账操作用户余额凭空多了一笔钱。排查过程先靠对账发现总金额与本地流水笔数不一致然后再翻日志定位到重复回调的时间点。修复方案就是我在前面写的——回调处理里必须先判断本地订单状态已经 SUCCESS 的直接返回成功不再执行入账逻辑。这个 bug 也让我养成了一个习惯所有涉及到钱的操作入口处第一行就是幂等校验。5.3 并发扣款导致的余额变负数用户同时下单两笔共 80 元和 30 元余额只有 100 元。第一笔扣款成功余额变 20第二笔扣款在并发情况下读到旧余额 100判断余额充足直接执行扣款余额变成 -10。这个 bug 的原因就是没有用乐观锁扣款 SQL 没有带版本条件。修复方案前面已经写过update 语句里加version条件并加上balance amount的数据库判断。这里有个经验之谈并发控制不能只靠应用层的 if 判断数据库层面的条件更新才是最后一道防线。5.4 定时任务重复执行导致重复对账对账任务如果部署在多实例环境下多个实例同时启动定时任务会重复下载对账文件、重复匹配、重复生成差错单。解决方式是用 Redis 分布式锁给对账任务加一个锁标记只有拿到锁的实例才能执行。锁的过期时间要设置成大于任务最长执行时间避免任务还在跑但锁已经过期被其他实例抢走。6. 还在打磨的一些想法做这个金融服务项目我个人最大的体会有两点。第一资金系统的设计要“先严后松”。先严格定义好账户模型、状态机、幂等规则、对账机制再动手写业务代码顺序反了后面就是无穷无尽的补丁。哪怕业务方催得再急这些基础底子也不能省否则上线后的每一次故障都在为前期草率买单。第二一定要给运营和财务留一个可视化对账界面。很多开发觉得对账跑批脚本输出一个 Excel 就完事了但实际上运营和财务需要的是能按时间范围、按渠道、按交易类型筛选的查询页面能直接看到差异原因和当前处理状态。我后来补了这个管理后台财务同学的使用体验和问题反馈效率提升了好几个级别。顺带分享一个小技巧账户表的流水建议按月做分区或分表因为月累计数据量大了之后流水表查询性能会明显下降。我一开始没做分表线上跑了半年数据量到几千万查询开始卡顿后来按月份分了区问题解决。项目做到这里financial-services 的基本能力已经覆盖了大多数中小型业务对资金服务的需求。后续如果要扩展可以做多币种支持、分账系统、跨境结算等方向但底层的数据模型和工程纪律是通用的。最后说一句掏心窝的话做资金系统宁可慢一点、稳一点也不要为了赶进度跳过对账设计和幂等设计。这两个点没做好后面的每一个安稳觉都可能是暂时的。
