预付费业务的本质，是先收钱、后消费。这看似简单的顺序变化，却把一个"查询型"系统变成了"资金型"系统——每一次扣费都必须绝对准确，任何一笔重复扣款或余额错乱，都会直接演变为用户投诉与资金损失。因此，构建预付费平台的难点从来不是功能实现，而是如何在高并发下同时保障性能与资金安全。
一、架构演进：从单体到分层解耦
第一阶段：单体起步。业务初期，账户余额与业务逻辑往往共库共表，一次扣费就是一条UPDATE balance SET amount=amount-?加一条流水记录，靠数据库事务兜底。这套方案开发成本极低，在日交易量万级以内全部够用，但所有压力最终都会汇聚到余额这一行热点数据上。
第二阶段：读写分离与异步化。交易量上升后，首要瓶颈是热点账户的行锁竞争。此时应将同步扣费拆解为"额度预占+异步落账"：先扣减缓存中的可用额度保证实时性，再通过消息队列异步生成账务流水与账单。同时引入读写分离，余额查询走只读副本，充值、扣费等写操作走主库。这一阶段的核心认知是——预付费平台的性能瓶颈几乎总是"写"，而非"读"。
第三阶段：领域拆分。当业务形态丰富到支持套餐、折扣、信用额度、多币种时，必须按领域边界拆分为账户中心、交易网关、计费引擎、清算对账四大模块，各自独立部署、独立扩容。账户中心只负责余额的增减与冻结，计费引擎只负责算"该扣多少"，二者通过明确接口协作，任何一方的变更都不会波及另一方。
二、核心模块拆解
账户中心是整个预付费平台的心脏。它需要维护三类余额：总余额、可用余额、冻结余额。三者关系为"可用=总-冻结"，预授权场景先冻结、实际消费时再从冻结转为实扣。所有余额变更必须基于流水表，而非直接改写余额字段——流水是事实来源，余额只是流水聚合后的物化结果，这样才具备对账与回溯能力。
交易网关负责承接上游请求，核心职责是幂等。每个请求必须携带全局的业务流水号，网关在处理前先查幂等表：已成功则直接返回原结果，处理中则拒绝重试，只有明确失败才允许重放。这是防重复扣费的第一道闸门。
计费引擎应对的是定价复杂性。建议将计费规则抽象为"定价计划+优惠规则+计费策略"三层，通过规则配置而非硬编码实现灵活调整。引擎输出的是一份"计费明细"，而非直接扣款，便于用户溯源与争议处理。
清算对账是最后的兜底。日终以流水为基准，与账户余额、上游业务方数据三方核对，差异进入差错池人工介入。一个成熟的预付费平台，对账系统往往比交易链路本身还要复杂。
三、几点实践共识
高并发扣费优先用"汇总扣费+缓冲入账"消解热点；余额防击穿依赖缓存层与数据库层的双重校验；资金安全绝不能只靠事务，必须有熔断、限流与日终对账三道防线。
预付费平台的建设没有终点，它是一条从"能用"到"准确"再到"可靠"的持续演进之路。
上海嘉定区育绿路253号
guoyangfan980325@163.com
在线客服