一、一笔差了三十几块的账去年秋天一个县里的乡村电商平台上架了两个月四十多个村的合作社在上面开了店卖米、卖油、卖土鸡蛋。运营对账时发现一个商户的可提现金额对不上系统显示能提八百二十七块六商户自己算出来少了三十几块来回核了三天没找出原因。这是我们接手时拿到的第一份东西说是需求其实只是一个现象。把流水拉出来看才发现这个商户中间有过一次部分退款一笔订单退了三成退款之后系统把整笔订单的分账金额都撤掉了商户少拿的那部分正好是剩下七成应该拿的钱。问题不在算错而在于退款时动了不该动的那笔账。二、订单状态和资金状态是两套东西早期我们把订单当成一个字段付款改成已付款发货改成已发货退款就把状态改回已退款。这套写法在只看订单的时候没问题一旦要算钱就崩因为订单状态的推进是单向的、整条的而资金的流动是可逆的还能按比例拆开。一笔订单可能只退了其中一部分退完还剩一部分继续履约这种状态下订单本身仍然是已发货可资金已经来回动了两次一次付出一次退回。把这两件事塞进同一个字段等于逼着一个字段同时表达两个维度怎么改都会丢信息。所以第一步是把它们分开。订单有一套状态机待付款到已付款、待发货、已发货、已完成退款作为一个能从中途插入的分支不改变主状态的语义只在旁边挂一条退款单。资金另有一套账每一笔钱的进出都记一条流水余额由流水推出来而不是由订单状态猜出来。三、余额到底怎么算三条路第一条路是每次要用余额时把订单表里已完成的加总减去退款再减去已经提现的部分。这条路不用新建表代价是所有业务都要重复写一遍这个加总一处改口径就得全改而且订单量上去之后每次查余额都是一次大范围扫描。第二条路是加一张流水表每笔钱的进出都追一条记录余额按商户实时求和。这条路口径统一代价是求和本身也要扫很多行商户中心首页一进去就要算一次余额慢得像卡住。第三条是我们最后用的流水表加一层结算与冻结。流水只负责记事实不负责算余额另外维护三个可加总的数字已结算、已提现、冻结中。可提现等于已结算减去已提现再减去冻结中三个数各自有变动时增量维护首页读的是这三个数不再做全表加总。四、把状态变更写成一张表命令和事件分开是我们做这一块时定下的第一条规矩。外部只发命令比如发起退款、申请提现命令进来先校验校验过了才产生事件状态由事件推进。这样做的直接好处是每一次状态变化都能对应一条可追溯的记录出了问题不用猜是哪一步走歪的。万村乐数字乡村的商家中心把这条路径写成了一张状态表从下单到结算一共七种事件退款和提现各占两种剩下的三种是发货、收货和自动确认。七种事件的组合被写进了一张状态表代码只做查表和落库判断逻辑全部前置到校验阶段主流程里几乎没有分支。退款这一支单独拆出来做成退款单一张订单可以挂多张退款单每张退款单有自己的一次性状态从申请到成功或者失败不可逆。支持部分退的关键就在这里退款单上带金额订单主表上的已退金额是成功退款单的累加主表只做加法从不做减法账就不会因为一笔区间退款而整体错位。五、金额、并发与几段关键语句金额一律以分为单位存整数浮点数在这条链路上一次都不出现。早期有一处用了小数计算分账按比例乘完之后做四舍五入几十笔累加下来差了几十厘最后落到某一笔上就变成差一分对账的时候怎么都对不平。改成整数之后分账余数固定补给平台那一侧规则简单商户自己拿计算器也能复算。防超卖和防负余额用的是同一种手段带条件的更新。库存扣减的语句里带上库存足够这个条件影响行数为零就说明被别人抢先了直接回滚整笔下单。冻结余额的语句里带上可提现金额足够这个条件同样靠影响行数判断结果不靠先查一次再改一次。分账比例要存快照。商户的分成比例是可以调的运营每年会改一次如果不存快照今天算去年那批订单的分账就会套用今天的新比例历史账全部错位。我们的做法是下单时把当时生效的比例写进订单行结算时读订单行上的那个值比例配置表后来改了也不影响已经产生的订单。六、对账时暴露的三个坑第一个坑是并发下单超卖。两个用户同时点最后一箱鸡蛋先查库存再扣减的写法一定出问题因为两次查询都会读到还剩一箱。改法前面提过把判断塞进更新语句的条件里靠数据库的行锁只有一个能改成功另一个影响行数为零前端提示已售完后台不产生半笔脏订单。第二个坑是退款和提现撞在一起。某个商户上午申请提现审核还没过下午发生了一笔退款退款要把已结算的钱减掉如果此时按已结算来算可提现余额就可能变成负数。改法是提现申请通过时就把金额从可提现里冻结走退款只扣已结算冻结中的那部分不动真出现不够扣的情况按顺序处理先冲减冻结再转成欠款记录挂账。第三个坑是重复提交。网络抖动时用户会连点两次提现两条请求都落到服务端如果只靠前端把按钮置灰重复单一定会产生。改法是给每笔资金操作带一个由客户端生成的操作号服务端对操作号做去重同一个操作号第二次进来直接返回第一次的结果不再产生新的流水。七、系统边界在哪里这套账只能让系统内部的数字自洽管不了外部资金真的到账。支付渠道的回调延迟、渠道侧的退款到账时间都不在我们控制范围里所以我们把渠道对账文件单独跑一遍和本地流水做比对差异行挂起来人工处理而不是让余额跟着渠道状态来回跳。它也不处理商户之间的分账纠纷。比例怎么定、退款该由谁承担、发货延迟算谁的责任这些是合同层面的事情系统只能在规则明确之后把结果算对规则本身含糊的时候算得再准也解决不了问题。八、小结回头看这一块真正的转折点是把订单和资金彻底分开订单管履约流水管钱余额由三个可加总的数字增量维护。分开之后最明显的收益是对账从三天缩到十几分钟绝大多数差异都能靠流水和退款单对上剩下的才是真正需要人工判断的疑难账。新的村合作社开店时不用再单独讨论一遍规则金额用分、条件更新防超卖、下单存分账快照在万村乐数字乡村的商家中心里都成了默认继承的行为。