简介一份围绕‘话费充值系统快充慢充话费直充’主题整理的Java开发资源包面向后端工程师、毕业设计学生及企业充值平台开发人员。内容系统覆盖三层架构与微服务拆分、Spring Boot/Spring Cloud技术选型、MySQL与Redis优化、RabbitMQ/Kafka异步处理、JWT安全认证及支付宝/微信支付对接等关键点同时针对快充慢充两种业务场景梳理了实时直充与预存款模式、订单状态机、失败退款与重试策略并附Docker/Kubernetes容器化部署、JMeter压力测试与ELK/Prometheus监控方案能给出一套从设计到上线的完整工程思路。资源采用zip压缩包整体约175.03MB文件明细暂未展示但目录组织与文档结构更适合按设计、开发、测试、运维分阶段研读。目前已有1161人学习下载适合用来做系统参考或二次开发蓝本帮助减少方案设计时间并提升项目落地效率。1. 为什么充值系统比普通电商订单更考验状态设计话费充值系统线上化之后表面上是把话费、流量、语音包做成商品实际上它比普通电商订单多出两个不确定因子上游充值接口的响应随时可能超时或返回假失败而渠道商结算又分快充和慢充两套完全不同的账期。这类系统的核心难点不在“金额计算”而在“状态如何收敛”。如果你是做订单、支付或渠道对接的研发这套基于 Java 的话费快充慢充系统能帮你把主流程、回调、幂等和对账串起来。后面所有章节都以可运行的 Spring Boot 代码粒度去拆不绕理论。2. 充值系统架构与订单模型设计2.1 为什么先用三层架构兜底再考虑微服务话费充值涉及用户请求、支付渠道、运营商接口三个外部依赖最忌讳一上来就按微服务切十几个模块。我见过把「查询话费号码归属地」单独拆成一个服务的项目最后查一次订单要跨五个服务。常见的做法是先按三层架构落地表现层接 App 和 H5 请求业务逻辑层处理订单校验、渠道选择、支付发起数据访问层操作 MySQL。当订单量与渠道数量真正上来后再按「订单」「充值」「渠道网关」「结算」四个边界拆微服务。下面是模块拆分建议按照这个边界拆职责单一且通信链路短服务职责依赖订单服务订单创建、状态流转、查询订单库、Redis充值服务快充/慢充任务编排、回调接收渠道网关、消息队列渠道网关封装移动/联通/电信接口差异上游HTTP接口、配置中心结算服务渠道对账、成本汇总、佣金计算结算库、对账文件存储订单服务只负责业务侧的状态变更充值服务只做通道适配不关心支付结果渠道网关把运营商接口的不稳定因素隔离在系统边界任何下游接口异常都只影响网关自身。这样设计之后快充超时不会拖垮订单创建流程慢充批次任务也不会抢占实时充值资源。注意不要为「话费直充」单独建一个服务它本质是快充的一种渠道策略放在渠道网关里用配置区分。2.2 快充与慢充的通道路由2.2.1 用策略模式封装充值通道话费直充、快充、慢充的业务差异最终体现在「发送充值请求」这一步。与其在 Service 里写一长串 if-else不如定义一个通道接口把不同供货渠道的差异收敛到各自实现类里。下面是一个稳定且好扩展的接口设计public interface RechargeChannel { ChannelType channelType(); boolean support(String mobile, BigDecimal amount); RechargeResult send(RechargeOrder order); }channelType返回当前通道是快充还是慢充路由时用来做类型过滤support判断该通道能否支持本次号码和金额慢充通道通常有最低金额和号段限制send是唯一的发单入口实现类内部处理运营商接口签名、超时、异常转换。快充实现类一般直接调用运营商实时接口设置 3 到 5 秒超时超时后立即标记为「充值中」交给回调重试慢充实现类则不直接发请求而是把订单丢到慢充消息队列由后台任务按批次发货。这样一个充值服务同时连接多家供货商时只需要在启动时把实现了RechargeChannel的 Bean 收集起来统一注入路由器。2.2.2 路由与降级规则路由器的核心逻辑是筛选可用通道、按优先级排序、失败后降级。排序规则可以用「成本最低优先」或「成功率最高优先」业务初期建议用成本优先因为慢充利润本身就薄选错通道可能十分钟亏掉一周利润。给出一段常见的路由伪代码public RechargeChannel route(String mobile, BigDecimal amount, String expectType) { return channelList.stream() .filter(c - c.channelType().name().equals(expectType)) .filter(c - c.support(mobile, amount)) .sorted(Comparator.comparing(c - channelCost.get(c.channelType()).costOf(amount))) .findFirst() .orElse(null); }这段代码里channelCost是系统启动时从配置中心拉取的渠道成本表costOf(amount)返回该渠道充这一单的成本。路由失败时业务侧要有一个明显的降级开关当快充通道全部不可用时可以配置将订单降级为慢充而不是直接失败。但要小心降级必须经过用户确认或在下单页明确提示否则用户付了快充的钱半小时才到账投诉率会立刻飙升。下面是快充和慢充在工程上最重要的差异对照对比项快充慢充到账时间秒级依赖运营商实时接口分钟到小时级可合并批次渠道成本高按零售价计低可走预存款折扣结算周期T0 或 T1常为 T3 或月结失败率较高接口超时概率大较低但响应慢系统要求实时链路易超时需要重试需要任务队列、定时化快充链路里的超时问题不是网络抖动那么简单。运营商接口经常返回「已受理」但实际没有发货这时本地订单状态是充值中需要等待异步回调来收敛。慢充的失败通常发生在后台校验号码状态时比如号码销户、空号或者携号转网这类失败要靠对账和回调感知单靠实时查询解决不了。3. 充值接口与支付回调的幂等实现3.1 定义充值订单的 RESTful API无论是 App 还是小程序用户最终只做一件事输入手机号、选择金额、发起充值。后端需要把这个动作设计成无状态接口方便前端轮询订单状态。下面是我常用的下单接口定义参数类型说明Authorizationstring请求头 Token解析用户身份businessIdstring业务方幂等ID如下单页生成的 UUIDmobilestring充值手机号需要做合法性校验amountBigDecimal充值金额单位元rechargeTypestringFAST / SLOW / DIRECT直充可视为 FAST 的加强版notifyUrlstring可选业务方自定义回调地址Controller 层只做参数封装核心订单创建逻辑放在 service 里。PostMapping(/api/v1/recharge/orders) public ResultRechargeOrderVO createOrder(RequestBody Valid RechargeCreateRequest req, HttpServletRequest request) { String userId JwtUtil.getUserId(request.getHeader(Authorization)); RechargeOrder order rechargeService.createOrder(userId, req); return Result.ok(RechargeOrderVO.from(order)); }createOrder内部的大致步骤是校验手机号格式检查 businessId 是否已存在防止前端重复提交锁定用户的账户或支付单生成订单号并落库状态初始化为WAIT_PAY随后拼装支付参数返回给前端。注意订单号不要用雪花算法直接裸奔建议带上渠道标识例如R20240601前缀后续按订单号查询日志、定位渠道问题时非常有用。3.2 支付回调的幂等处理支付平台回调是充值系统最容易被重复触发的环节。支付宝、微信支付官方文档里都写明回调可能多次推送因此支付回调处理的第一步必须是幂等。常见的做法是给支付流水表加唯一索引payment_no回调处理时先判断流水是否已存在存在则直接返回不存在才继续处理订单。Transactional public void handlePayCallback(PayCallback callback) { if (payRecordDao.existsByPaymentNo(callback.getPaymentNo())) { log.warn(重复支付回调: {}, callback.getPaymentNo()); return; } RechargeOrder order orderDao.lockByOrderNo(callback.getOrderNo()); if (order null) { throw new BusinessException(订单不存在); } if (order.getStatus() OrderStatus.WAIT_PAY) { payRecordDao.insert(callback); order.setStatus(OrderStatus.PAYED); orderDao.updateStatus(order); rechargeProducer.send(new RechargeMessage(order.getOrderNo())); } }这段代码的关键点是lockByOrderNo使用了 SELECT FOR UPDATE把同一订单的并发回调串行化避免两个线程同时读到WAIT_PAY状态后重复改状态。支付成功消息只发送一次因为发送前已经通过状态判断拦截了重复流转。实际项目里还要校验签名签名校验失败的回调必须丢弃并记录告警防止有人伪造支付通知。3.3 充值结果回调的状态收敛支付回调解决的是「用户付没付钱」充值回调解决的是「话费到没到账」。充值回调一般来自渠道网关的开放接口网关把上游运营商返回的状态透传过来。处理这类回调同样要幂等但幂等键不是支付流水号而是充值单号rechargeNo。渠道网关侧每次重试都会带同一个rechargeNo所以本地表结构上要给recharge_no加唯一索引。public void handleRechargeCallback(RechargeCallback cb) { RechargeOrder order orderDao.findByRechargeNo(cb.getRechargeNo()); if (order null || !order.getStatus().canReceiveCallback()) { return; } if (SUCCESS.equals(cb.getResult())) { order.setStatus(OrderStatus.SUCCESS); order.setFinishedAt(new Date()); } else if (FAIL.equals(cb.getResult())) { order.setStatus(OrderStatus.FAIL); order.setFailReason(cb.getFailReason()); } orderDao.updateStatus(order); }canReceiveCallback是一个很实用的状态校验方法只有当前状态是RECHARGING时才能接收成功回执如果订单已经终态后续到达的回调直接忽略。这样能防止渠道回调乱序造成状态倒退回充值中。快充里经常出现「先收到成功后收到失败」的乱序处理原则是终态不可覆盖。4. 订单状态机与失败补偿策略4.1 订单状态建模话费充值订单最怕状态没有穷尽。你可以把状态设计成一个枚举把允许的事件迁移约束在枚举内部业务代码里不再散落各种 if 判断。状态可触发事件下一状态说明WAIT_PAYPAY_SUCCESSPAYED用户完成支付PAYEDSEND_STARTRECHARGING已下发充值渠道RECHARGINGRECHARGE_SUCCESSSUCCESS终态RECHARGINGRECHARGE_FAILFAIL终态等待退款RECHARGINGRETRYRECHARGING重试次数加一并重新下发FAILMONEY_BACKREFUNDED终态枚举内部校验便于统一处理非法迁移。比如支付回调到了订单还在 WAIT_PAY可以迁移但如果支付回调到了订单已经 SUCCESS就要忽略。把这个判断收敛到transition(OrderEvent event)方法里所有入口统一调用状态就基本不会跑飞。4.2 基于 RabbitMQ 延迟队列的重试与补偿快充失败后直接退款会损失渠道成本很多情况下失败只是上游临时故障重试一次就能成功。所以要在充值状态机里引入重试队列。使用 RabbitMQ 死信队列实现延迟重试比在应用层写Thread.sleep或定时任务扫描更可控。下面是一个基于 TTL 的延迟队列配置Bean public DirectExchange rechargeDelayExchange() { return new DirectExchange(recharge.delay.exchange); } Bean public Queue rechargeDelayQueue() { return QueueBuilder.durable(recharge.delay.queue) .deadLetterExchange(recharge.delay.exchange) .deadLetterRoutingKey(recharge.retry) .ttl(30_000) .build(); } Bean public Queue rechargeRetryQueue() { return new Queue(recharge.retry.queue, true); }这里的 TTL 设为 30 秒表示充值中订单被判定为超时后先在延迟队列里等待 30 秒到期后经死信交换机投递到recharge.retry.queue消费者监听该队列执行重发。每次消费重试消息时把消息里的重试次数加一达到上限后转为人工处理。如果直接对原订单进行重发记得先检查订单状态仍是 RECHARGING避免订单已经成功又被重试请求覆盖。慢充的重试逻辑不同它通常是批量任务周期性拉取未完成订单重试间隔约 10 分钟快充重试间隔要尽量短一般 30 秒到 2 分钟超过 3 次就进入人工核查队列。4.3 退款与对账兜底当订单被判为最终失败且已经付款需要触发退款。退款建议做成独立的补偿任务由状态机把订单从 FAIL 推到 REFUNDING再调用支付平台的退款接口而不是在充值失败的 catch 块里同步退款。同步退款的问题是渠道回调延迟很长时事务会一直占用连接把数据库连接池拖垮。Scheduled(fixedDelay 60_000) public void refundPendingOrders() { ListRechargeOrder failOrders orderDao.findByStatusAndTimeout(OrderStatus.FAIL, 5); for (RechargeOrder order : failOrders) { boolean ok refundService.refund(order.getOrderNo(), order.getPayAmount()); if (ok) { orderDao.updateStatus(order.getOrderNo(), OrderStatus.REFUNDED); } } }定时任务的粒度是每分钟扫一次只处理失败时间超过 5 分钟的订单给回调留足时间避免和正在重试的订单冲突。这里最重要的一点是退款金额必须以支付流水里的实付金额为准不能用订单金额因为充值经常有优惠券、满减订单金额往往大于实付金额。5. 性能优化、压测与容器化部署5.1 用 Redis 解决缓存击穿充值系统的高频读操作是查询套餐列表和订单状态。套餐列表可以整表缓存进 Redis但热点套餐偶尔会存在缓存过期瞬间大量请求打到 MySQL也就是缓存击穿。常见的做法是缓存逻辑上加互斥锁只允许一个线程回源查库public String getPackCache(String key) { String value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } synchronized (lockObject) { value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } value loadFromDb(key); redisTemplate.opsForValue().set(key, value, 60, TimeUnit.SECONDS); } return value; }synchronized只在单机部署时有效多实例部署时要改用 Redis 分布式锁。锁定后二次查询是必需步骤否则并发瞬间依然会有多个线程穿透到数据库。订单状态的写操作不建议缓存因为状态流转的一致性要求高缓存只能用来做「已支付」「已成功」这些非关键状态的临时透传。5.2 Nginx 层优化充值接口充值服务的实时性要求比普通查询高Nginx 默认的 60 秒代理超时对于快充接口来说太长会导致支付前端长时间等待。我通常对充值接口单独配置一组 location专门收紧超时和连接池upstream recharge_backend { server 10.0.0.11:8080 weight3; server 10.0.0.12:8080 weight3; keepalive 64; } location /api/v1/recharge/ { proxy_pass http://recharge_backend; proxy_connect_timeout 2s; proxy_read_timeout 5s; proxy_next_upstream error timeout http_502; proxy_next_upstream_tries 2; }keepalive 64保持后端连接复用避免每次请求都新建 TCP 连接proxy_read_timeout 5s让路由到慢充的请求快速失败再配合上游重试机制换一台后端重发proxy_next_upstream_tries 2防止单个后端节点故障时请求长时间挂起。充值服务一般部署在负载均衡层后面网关上需要关掉或调短响应缓冲避免余额不足这类错误被浏览器缓存。5.3 JMeter 压测与瓶颈定位上线前压测重点不是看 QPS 数字而是观察失败率、响应时间分位数、数据库连接数和 GC 频率。用 JMeter 命令行跑脚本是最适合 CI 的方式jmeter -n -t recharge-plan.jmx -l result.jtl -e -o report_dir执行后打开report_dir里的 index.html重点看 90 分位响应时间和错误率。对于充值系统我的建议是快充和慢充分开建线程组因为慢充接口的响应会很高混在一起会拉低快充的基线。常见指标参考如下指标建议值说明快充平均响应时间小于 300 ms不含前端排队快充 90 分位小于 800 ms超过则检查上游接口错误率小于 0.1%排除渠道侧超时重试数据库连接数不超过连接池 70%超过则优先查慢查询发现 CPU 高但 QPS 不涨时优先看 MySQL 慢查询日志发现接口偶尔超时但 CPU 很低时看网络连接数和 Redis 连接池是否被打满。5.4 Docker 与 Kubernetes 部署要点话费充值系统微服务化之后Docker 镜像的构建要固定基础镜像版本不要用latest。一个基础镜像示例FROM openjdk:17-jdk-slim ENV TZAsia/Shanghai COPY target/recharge-service.jar /app/app.jar ENTRYPOINT [java, -Xms512m, -Xmx512m, -jar, /app/app.jar]Kubernetes 部署时配置探针确保滚动更新期间不把流量打到未就绪的 PodlivenessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 20 periodSeconds: 10 readinessProbe: httpGet: path: /actuator/ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5readinessProbe使用专门的 ready 接口只有依赖的 Redis、MySQL、RabbitMQ 都连接成功后才返回 200。如果把 liveness 和 readiness 共用同一个接口依赖抖动时 Pod 会被频繁重启反而放大故障。另外 JVM 内存最好在启动参数里固定到与 Pod 配额一致避免容器内存超卖触发 OOMKilled。6. 对账修复把快充慢充订单状态收敛回终态6.1 渠道对账文件与本地状态比对快充和慢充的渠道商每天会输出对账文件里面包含充值单号、手机号、面值、成本价、状态。对账的意义不只是记账是修正那些既没收到成功回调也没收到失败回调的悬挂订单。我一般把对账文件解析后插入一张channel_statement表再与本地订单做左连接比对。SELECT o.order_no, o.status, s.channel_status, CASE WHEN s.channel_status SUCCESS AND o.status SUCCESS THEN NEED_FIX WHEN s.channel_status FAIL AND o.status FAIL THEN NEED_FAIL ELSE OK END AS fix_action FROM recharge_order o LEFT JOIN channel_statement s ON o.recharge_no s.recharge_no WHERE o.created_at CURDATE() - INTERVAL 3 DAY;这条 SQL 不是用来直接更新的而是生成待修复列表给对账程序消费。注意CURDATE() - INTERVAL 3 DAY这个时间窗口慢充订单可能 2 天才完成只查当天订单会把慢充未完成的单子误判为状态异常。6.2 快充慢充对账后的修复策略快充订单如果渠道返回 SUCCESS本地状态是 RECHARGING可以直接置为 SUCCESS因为渠道侧已经确认到账继续等回调反而拖延退款和结算。慢充订单则要谨慎慢充的渠道对账文件经常延迟一天才生成所以不能按快充的规则直接覆盖必须先看订单创建时间是否超过 24 小时不足 24 小时的一律保留 RECHARGING 状态继续等待。这本质上是把渠道结算特点映射为业务状态机的超时策略。对账发现的失败订单不需要立刻触发退款。渠道返回 FAIL 后还要再看有没有可能二次补单比如部分供应商对失败单号支持自动重发。我在实际项目中是这样做的对账失败订单再进入一条recharge.failure.recheck队列延迟 10 分钟重新向渠道查询一次状态查到的结果以第二次为准。二次查询仍失败才把订单标记为 FAIL 进入退款流程。这个动作保证了对账修复不会造成误退款损失。注意对账修复的更新操作要打好日志最好把修复前后状态写入对账操作流水表否则出问题后现场全部丢失。如果对账文件里出现本地完全不存在的recharge_no说明渠道侧多记了一个订单通常是因为本地订单在发单前就因超时回滚了但渠道已经受理。这类单子要把渠道单号和手机号记录到异常文件人工确认后再决定是补单还是让渠道撤单不能自动按成功入账否则渠道成本会直接变成亏损。本文还有配套的精品资源点击获取
Java话费充值系统核心设计：快充慢充、状态机与幂等对账实践
简介一份围绕‘话费充值系统快充慢充话费直充’主题整理的Java开发资源包面向后端工程师、毕业设计学生及企业充值平台开发人员。内容系统覆盖三层架构与微服务拆分、Spring Boot/Spring Cloud技术选型、MySQL与Redis优化、RabbitMQ/Kafka异步处理、JWT安全认证及支付宝/微信支付对接等关键点同时针对快充慢充两种业务场景梳理了实时直充与预存款模式、订单状态机、失败退款与重试策略并附Docker/Kubernetes容器化部署、JMeter压力测试与ELK/Prometheus监控方案能给出一套从设计到上线的完整工程思路。资源采用zip压缩包整体约175.03MB文件明细暂未展示但目录组织与文档结构更适合按设计、开发、测试、运维分阶段研读。目前已有1161人学习下载适合用来做系统参考或二次开发蓝本帮助减少方案设计时间并提升项目落地效率。1. 为什么充值系统比普通电商订单更考验状态设计话费充值系统线上化之后表面上是把话费、流量、语音包做成商品实际上它比普通电商订单多出两个不确定因子上游充值接口的响应随时可能超时或返回假失败而渠道商结算又分快充和慢充两套完全不同的账期。这类系统的核心难点不在“金额计算”而在“状态如何收敛”。如果你是做订单、支付或渠道对接的研发这套基于 Java 的话费快充慢充系统能帮你把主流程、回调、幂等和对账串起来。后面所有章节都以可运行的 Spring Boot 代码粒度去拆不绕理论。2. 充值系统架构与订单模型设计2.1 为什么先用三层架构兜底再考虑微服务话费充值涉及用户请求、支付渠道、运营商接口三个外部依赖最忌讳一上来就按微服务切十几个模块。我见过把「查询话费号码归属地」单独拆成一个服务的项目最后查一次订单要跨五个服务。常见的做法是先按三层架构落地表现层接 App 和 H5 请求业务逻辑层处理订单校验、渠道选择、支付发起数据访问层操作 MySQL。当订单量与渠道数量真正上来后再按「订单」「充值」「渠道网关」「结算」四个边界拆微服务。下面是模块拆分建议按照这个边界拆职责单一且通信链路短服务职责依赖订单服务订单创建、状态流转、查询订单库、Redis充值服务快充/慢充任务编排、回调接收渠道网关、消息队列渠道网关封装移动/联通/电信接口差异上游HTTP接口、配置中心结算服务渠道对账、成本汇总、佣金计算结算库、对账文件存储订单服务只负责业务侧的状态变更充值服务只做通道适配不关心支付结果渠道网关把运营商接口的不稳定因素隔离在系统边界任何下游接口异常都只影响网关自身。这样设计之后快充超时不会拖垮订单创建流程慢充批次任务也不会抢占实时充值资源。注意不要为「话费直充」单独建一个服务它本质是快充的一种渠道策略放在渠道网关里用配置区分。2.2 快充与慢充的通道路由2.2.1 用策略模式封装充值通道话费直充、快充、慢充的业务差异最终体现在「发送充值请求」这一步。与其在 Service 里写一长串 if-else不如定义一个通道接口把不同供货渠道的差异收敛到各自实现类里。下面是一个稳定且好扩展的接口设计public interface RechargeChannel { ChannelType channelType(); boolean support(String mobile, BigDecimal amount); RechargeResult send(RechargeOrder order); }channelType返回当前通道是快充还是慢充路由时用来做类型过滤support判断该通道能否支持本次号码和金额慢充通道通常有最低金额和号段限制send是唯一的发单入口实现类内部处理运营商接口签名、超时、异常转换。快充实现类一般直接调用运营商实时接口设置 3 到 5 秒超时超时后立即标记为「充值中」交给回调重试慢充实现类则不直接发请求而是把订单丢到慢充消息队列由后台任务按批次发货。这样一个充值服务同时连接多家供货商时只需要在启动时把实现了RechargeChannel的 Bean 收集起来统一注入路由器。2.2.2 路由与降级规则路由器的核心逻辑是筛选可用通道、按优先级排序、失败后降级。排序规则可以用「成本最低优先」或「成功率最高优先」业务初期建议用成本优先因为慢充利润本身就薄选错通道可能十分钟亏掉一周利润。给出一段常见的路由伪代码public RechargeChannel route(String mobile, BigDecimal amount, String expectType) { return channelList.stream() .filter(c - c.channelType().name().equals(expectType)) .filter(c - c.support(mobile, amount)) .sorted(Comparator.comparing(c - channelCost.get(c.channelType()).costOf(amount))) .findFirst() .orElse(null); }这段代码里channelCost是系统启动时从配置中心拉取的渠道成本表costOf(amount)返回该渠道充这一单的成本。路由失败时业务侧要有一个明显的降级开关当快充通道全部不可用时可以配置将订单降级为慢充而不是直接失败。但要小心降级必须经过用户确认或在下单页明确提示否则用户付了快充的钱半小时才到账投诉率会立刻飙升。下面是快充和慢充在工程上最重要的差异对照对比项快充慢充到账时间秒级依赖运营商实时接口分钟到小时级可合并批次渠道成本高按零售价计低可走预存款折扣结算周期T0 或 T1常为 T3 或月结失败率较高接口超时概率大较低但响应慢系统要求实时链路易超时需要重试需要任务队列、定时化快充链路里的超时问题不是网络抖动那么简单。运营商接口经常返回「已受理」但实际没有发货这时本地订单状态是充值中需要等待异步回调来收敛。慢充的失败通常发生在后台校验号码状态时比如号码销户、空号或者携号转网这类失败要靠对账和回调感知单靠实时查询解决不了。3. 充值接口与支付回调的幂等实现3.1 定义充值订单的 RESTful API无论是 App 还是小程序用户最终只做一件事输入手机号、选择金额、发起充值。后端需要把这个动作设计成无状态接口方便前端轮询订单状态。下面是我常用的下单接口定义参数类型说明Authorizationstring请求头 Token解析用户身份businessIdstring业务方幂等ID如下单页生成的 UUIDmobilestring充值手机号需要做合法性校验amountBigDecimal充值金额单位元rechargeTypestringFAST / SLOW / DIRECT直充可视为 FAST 的加强版notifyUrlstring可选业务方自定义回调地址Controller 层只做参数封装核心订单创建逻辑放在 service 里。PostMapping(/api/v1/recharge/orders) public ResultRechargeOrderVO createOrder(RequestBody Valid RechargeCreateRequest req, HttpServletRequest request) { String userId JwtUtil.getUserId(request.getHeader(Authorization)); RechargeOrder order rechargeService.createOrder(userId, req); return Result.ok(RechargeOrderVO.from(order)); }createOrder内部的大致步骤是校验手机号格式检查 businessId 是否已存在防止前端重复提交锁定用户的账户或支付单生成订单号并落库状态初始化为WAIT_PAY随后拼装支付参数返回给前端。注意订单号不要用雪花算法直接裸奔建议带上渠道标识例如R20240601前缀后续按订单号查询日志、定位渠道问题时非常有用。3.2 支付回调的幂等处理支付平台回调是充值系统最容易被重复触发的环节。支付宝、微信支付官方文档里都写明回调可能多次推送因此支付回调处理的第一步必须是幂等。常见的做法是给支付流水表加唯一索引payment_no回调处理时先判断流水是否已存在存在则直接返回不存在才继续处理订单。Transactional public void handlePayCallback(PayCallback callback) { if (payRecordDao.existsByPaymentNo(callback.getPaymentNo())) { log.warn(重复支付回调: {}, callback.getPaymentNo()); return; } RechargeOrder order orderDao.lockByOrderNo(callback.getOrderNo()); if (order null) { throw new BusinessException(订单不存在); } if (order.getStatus() OrderStatus.WAIT_PAY) { payRecordDao.insert(callback); order.setStatus(OrderStatus.PAYED); orderDao.updateStatus(order); rechargeProducer.send(new RechargeMessage(order.getOrderNo())); } }这段代码的关键点是lockByOrderNo使用了 SELECT FOR UPDATE把同一订单的并发回调串行化避免两个线程同时读到WAIT_PAY状态后重复改状态。支付成功消息只发送一次因为发送前已经通过状态判断拦截了重复流转。实际项目里还要校验签名签名校验失败的回调必须丢弃并记录告警防止有人伪造支付通知。3.3 充值结果回调的状态收敛支付回调解决的是「用户付没付钱」充值回调解决的是「话费到没到账」。充值回调一般来自渠道网关的开放接口网关把上游运营商返回的状态透传过来。处理这类回调同样要幂等但幂等键不是支付流水号而是充值单号rechargeNo。渠道网关侧每次重试都会带同一个rechargeNo所以本地表结构上要给recharge_no加唯一索引。public void handleRechargeCallback(RechargeCallback cb) { RechargeOrder order orderDao.findByRechargeNo(cb.getRechargeNo()); if (order null || !order.getStatus().canReceiveCallback()) { return; } if (SUCCESS.equals(cb.getResult())) { order.setStatus(OrderStatus.SUCCESS); order.setFinishedAt(new Date()); } else if (FAIL.equals(cb.getResult())) { order.setStatus(OrderStatus.FAIL); order.setFailReason(cb.getFailReason()); } orderDao.updateStatus(order); }canReceiveCallback是一个很实用的状态校验方法只有当前状态是RECHARGING时才能接收成功回执如果订单已经终态后续到达的回调直接忽略。这样能防止渠道回调乱序造成状态倒退回充值中。快充里经常出现「先收到成功后收到失败」的乱序处理原则是终态不可覆盖。4. 订单状态机与失败补偿策略4.1 订单状态建模话费充值订单最怕状态没有穷尽。你可以把状态设计成一个枚举把允许的事件迁移约束在枚举内部业务代码里不再散落各种 if 判断。状态可触发事件下一状态说明WAIT_PAYPAY_SUCCESSPAYED用户完成支付PAYEDSEND_STARTRECHARGING已下发充值渠道RECHARGINGRECHARGE_SUCCESSSUCCESS终态RECHARGINGRECHARGE_FAILFAIL终态等待退款RECHARGINGRETRYRECHARGING重试次数加一并重新下发FAILMONEY_BACKREFUNDED终态枚举内部校验便于统一处理非法迁移。比如支付回调到了订单还在 WAIT_PAY可以迁移但如果支付回调到了订单已经 SUCCESS就要忽略。把这个判断收敛到transition(OrderEvent event)方法里所有入口统一调用状态就基本不会跑飞。4.2 基于 RabbitMQ 延迟队列的重试与补偿快充失败后直接退款会损失渠道成本很多情况下失败只是上游临时故障重试一次就能成功。所以要在充值状态机里引入重试队列。使用 RabbitMQ 死信队列实现延迟重试比在应用层写Thread.sleep或定时任务扫描更可控。下面是一个基于 TTL 的延迟队列配置Bean public DirectExchange rechargeDelayExchange() { return new DirectExchange(recharge.delay.exchange); } Bean public Queue rechargeDelayQueue() { return QueueBuilder.durable(recharge.delay.queue) .deadLetterExchange(recharge.delay.exchange) .deadLetterRoutingKey(recharge.retry) .ttl(30_000) .build(); } Bean public Queue rechargeRetryQueue() { return new Queue(recharge.retry.queue, true); }这里的 TTL 设为 30 秒表示充值中订单被判定为超时后先在延迟队列里等待 30 秒到期后经死信交换机投递到recharge.retry.queue消费者监听该队列执行重发。每次消费重试消息时把消息里的重试次数加一达到上限后转为人工处理。如果直接对原订单进行重发记得先检查订单状态仍是 RECHARGING避免订单已经成功又被重试请求覆盖。慢充的重试逻辑不同它通常是批量任务周期性拉取未完成订单重试间隔约 10 分钟快充重试间隔要尽量短一般 30 秒到 2 分钟超过 3 次就进入人工核查队列。4.3 退款与对账兜底当订单被判为最终失败且已经付款需要触发退款。退款建议做成独立的补偿任务由状态机把订单从 FAIL 推到 REFUNDING再调用支付平台的退款接口而不是在充值失败的 catch 块里同步退款。同步退款的问题是渠道回调延迟很长时事务会一直占用连接把数据库连接池拖垮。Scheduled(fixedDelay 60_000) public void refundPendingOrders() { ListRechargeOrder failOrders orderDao.findByStatusAndTimeout(OrderStatus.FAIL, 5); for (RechargeOrder order : failOrders) { boolean ok refundService.refund(order.getOrderNo(), order.getPayAmount()); if (ok) { orderDao.updateStatus(order.getOrderNo(), OrderStatus.REFUNDED); } } }定时任务的粒度是每分钟扫一次只处理失败时间超过 5 分钟的订单给回调留足时间避免和正在重试的订单冲突。这里最重要的一点是退款金额必须以支付流水里的实付金额为准不能用订单金额因为充值经常有优惠券、满减订单金额往往大于实付金额。5. 性能优化、压测与容器化部署5.1 用 Redis 解决缓存击穿充值系统的高频读操作是查询套餐列表和订单状态。套餐列表可以整表缓存进 Redis但热点套餐偶尔会存在缓存过期瞬间大量请求打到 MySQL也就是缓存击穿。常见的做法是缓存逻辑上加互斥锁只允许一个线程回源查库public String getPackCache(String key) { String value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } synchronized (lockObject) { value redisTemplate.opsForValue().get(key); if (value ! null) { return value; } value loadFromDb(key); redisTemplate.opsForValue().set(key, value, 60, TimeUnit.SECONDS); } return value; }synchronized只在单机部署时有效多实例部署时要改用 Redis 分布式锁。锁定后二次查询是必需步骤否则并发瞬间依然会有多个线程穿透到数据库。订单状态的写操作不建议缓存因为状态流转的一致性要求高缓存只能用来做「已支付」「已成功」这些非关键状态的临时透传。5.2 Nginx 层优化充值接口充值服务的实时性要求比普通查询高Nginx 默认的 60 秒代理超时对于快充接口来说太长会导致支付前端长时间等待。我通常对充值接口单独配置一组 location专门收紧超时和连接池upstream recharge_backend { server 10.0.0.11:8080 weight3; server 10.0.0.12:8080 weight3; keepalive 64; } location /api/v1/recharge/ { proxy_pass http://recharge_backend; proxy_connect_timeout 2s; proxy_read_timeout 5s; proxy_next_upstream error timeout http_502; proxy_next_upstream_tries 2; }keepalive 64保持后端连接复用避免每次请求都新建 TCP 连接proxy_read_timeout 5s让路由到慢充的请求快速失败再配合上游重试机制换一台后端重发proxy_next_upstream_tries 2防止单个后端节点故障时请求长时间挂起。充值服务一般部署在负载均衡层后面网关上需要关掉或调短响应缓冲避免余额不足这类错误被浏览器缓存。5.3 JMeter 压测与瓶颈定位上线前压测重点不是看 QPS 数字而是观察失败率、响应时间分位数、数据库连接数和 GC 频率。用 JMeter 命令行跑脚本是最适合 CI 的方式jmeter -n -t recharge-plan.jmx -l result.jtl -e -o report_dir执行后打开report_dir里的 index.html重点看 90 分位响应时间和错误率。对于充值系统我的建议是快充和慢充分开建线程组因为慢充接口的响应会很高混在一起会拉低快充的基线。常见指标参考如下指标建议值说明快充平均响应时间小于 300 ms不含前端排队快充 90 分位小于 800 ms超过则检查上游接口错误率小于 0.1%排除渠道侧超时重试数据库连接数不超过连接池 70%超过则优先查慢查询发现 CPU 高但 QPS 不涨时优先看 MySQL 慢查询日志发现接口偶尔超时但 CPU 很低时看网络连接数和 Redis 连接池是否被打满。5.4 Docker 与 Kubernetes 部署要点话费充值系统微服务化之后Docker 镜像的构建要固定基础镜像版本不要用latest。一个基础镜像示例FROM openjdk:17-jdk-slim ENV TZAsia/Shanghai COPY target/recharge-service.jar /app/app.jar ENTRYPOINT [java, -Xms512m, -Xmx512m, -jar, /app/app.jar]Kubernetes 部署时配置探针确保滚动更新期间不把流量打到未就绪的 PodlivenessProbe: httpGet: path: /actuator/health port: 8080 initialDelaySeconds: 20 periodSeconds: 10 readinessProbe: httpGet: path: /actuator/ready port: 8080 initialDelaySeconds: 5 periodSeconds: 5readinessProbe使用专门的 ready 接口只有依赖的 Redis、MySQL、RabbitMQ 都连接成功后才返回 200。如果把 liveness 和 readiness 共用同一个接口依赖抖动时 Pod 会被频繁重启反而放大故障。另外 JVM 内存最好在启动参数里固定到与 Pod 配额一致避免容器内存超卖触发 OOMKilled。6. 对账修复把快充慢充订单状态收敛回终态6.1 渠道对账文件与本地状态比对快充和慢充的渠道商每天会输出对账文件里面包含充值单号、手机号、面值、成本价、状态。对账的意义不只是记账是修正那些既没收到成功回调也没收到失败回调的悬挂订单。我一般把对账文件解析后插入一张channel_statement表再与本地订单做左连接比对。SELECT o.order_no, o.status, s.channel_status, CASE WHEN s.channel_status SUCCESS AND o.status SUCCESS THEN NEED_FIX WHEN s.channel_status FAIL AND o.status FAIL THEN NEED_FAIL ELSE OK END AS fix_action FROM recharge_order o LEFT JOIN channel_statement s ON o.recharge_no s.recharge_no WHERE o.created_at CURDATE() - INTERVAL 3 DAY;这条 SQL 不是用来直接更新的而是生成待修复列表给对账程序消费。注意CURDATE() - INTERVAL 3 DAY这个时间窗口慢充订单可能 2 天才完成只查当天订单会把慢充未完成的单子误判为状态异常。6.2 快充慢充对账后的修复策略快充订单如果渠道返回 SUCCESS本地状态是 RECHARGING可以直接置为 SUCCESS因为渠道侧已经确认到账继续等回调反而拖延退款和结算。慢充订单则要谨慎慢充的渠道对账文件经常延迟一天才生成所以不能按快充的规则直接覆盖必须先看订单创建时间是否超过 24 小时不足 24 小时的一律保留 RECHARGING 状态继续等待。这本质上是把渠道结算特点映射为业务状态机的超时策略。对账发现的失败订单不需要立刻触发退款。渠道返回 FAIL 后还要再看有没有可能二次补单比如部分供应商对失败单号支持自动重发。我在实际项目中是这样做的对账失败订单再进入一条recharge.failure.recheck队列延迟 10 分钟重新向渠道查询一次状态查到的结果以第二次为准。二次查询仍失败才把订单标记为 FAIL 进入退款流程。这个动作保证了对账修复不会造成误退款损失。注意对账修复的更新操作要打好日志最好把修复前后状态写入对账操作流水表否则出问题后现场全部丢失。如果对账文件里出现本地完全不存在的recharge_no说明渠道侧多记了一个订单通常是因为本地订单在发单前就因超时回滚了但渠道已经受理。这类单子要把渠道单号和手机号记录到异常文件人工确认后再决定是补单还是让渠道撤单不能自动按成功入账否则渠道成本会直接变成亏损。本文还有配套的精品资源点击获取
