一、 一次回调失误差点造成百万资损先讲一个真实的惨痛经历。某个凌晨支付渠道微信/支付宝回调服务突然延迟触发了我们的超时重试机制。同一笔订单支付渠道在30秒内推送了7次回调通知。由于我们的回调处理逻辑当时只做了简单的订单状态判断java// 问题代码if (order.getStatus() OrderStatus.UNPAID) {// 更新订单为已支付order.setStatus(OrderStatus.PAID);// 执行后续业务加积分、发券、通知物流…doAfterPay(order);}看起来没问题对吧但问题出在并发上——7个请求同时到达都读到了statusUNPAID于是7个线程同时执行了7次doAfterPay()结果用户积分被加了 7次。优惠券发了 7张。物流系统收到了 7个重复的发货指令。虽然最终通过人工对账挽回了大部分损失但这个教训让我们深刻认识到支付回调的幂等性设计是电商系统的生死线。本文将全面复盘我们如何从简单状态判断演进到分布式锁幂等表的完整方案希望能帮助大家避开这个坑。二、 问题的本质为什么回调一定会重复首先要达成一个共识支付回调的重复推送是常态不是异常。微信/支付宝官方文档明确说明回调可能因网络抖动、商户服务器响应慢等原因重复推送。商户服务器自身也可能因为重启、超时等触发重试机制。所以我们的设计目标非常清晰无论同一笔订单的回调被调用多少次业务处理逻辑只执行一次且结果一致。这就是幂等性Idempotency。三、 演进V1.0数据库唯一索引——最硬的防线在V1.0版本中我们采用了最简单粗暴但最有效的方法数据库唯一索引。设计思路创建一张pay_callback_log回调流水表以transaction_id支付渠道交易号作为唯一索引。收到回调时先插入流水记录插入成功才执行业务逻辑插入失败说明已被处理直接返回成功。sqlCREATE TABLEpay_callback_log(idbigint(20) NOT NULL AUTO_INCREMENT,transaction_idvarchar(64) NOT NULL COMMENT ‘渠道交易流水号’,order_novarchar(32) NOT NULL COMMENT ‘商户订单号’,statustinyint(4) DEFAULT ‘0’ COMMENT ‘处理状态0未处理 1已处理’,raw_datatext COMMENT ‘原始回调报文’,create_timedatetime DEFAULT CURRENT_TIMESTAMP,PRIMARY KEY (id),UNIQUE KEYidx_transaction_id(transaction_id) – 唯一索引防重复的核心) ENGINEInnoDB DEFAULT CHARSETutf8mb4;处理流程伪代码javaTransactional(rollbackFor Exception.class)public void handlePayCallback(PayCallbackDTO dto) {String transactionId dto.getTransactionId();try { // 1. 插入回调流水利用唯一索引防重 CallbackLog log new CallbackLog(); log.setTransactionId(transactionId); log.setOrderNo(dto.getOrderNo()); log.setRawData(JSON.toJSONString(dto)); callbackLogMapper.insert(log); // 如果transaction_id重复抛出DuplicateKeyException // 2. 执行核心业务更新订单状态、加积分、发券等 orderService.paySuccess(dto.getOrderNo()); log.setStatus(1); // 标记已处理 callbackLogMapper.updateById(log); } catch (DuplicateKeyException e) { // 重复回调直接返回成功给支付渠道的响应必须是success log.warn(重复回调transactionId{} 已处理过, transactionId); // 不做任何业务操作直接返回 }}优点实现简单数据库层保证绝对不重复插入。可靠即使应用层代码出现BUG数据库索引依然是最后一道防线。缺点性能瓶颈每次回调都要先插入数据库高并发下数据库压力大。分布式事务插入流水和更新订单在同一个Transactional中如果业务逻辑耗时较长数据库连接被长时间占用。四、 演进V2.0分布式锁Redis——更轻量的防重方案为了降低数据库压力我们引入了Redis分布式锁。设计思路使用订单号order_no作为锁的Key。收到回调时尝试获取锁获取成功则执行业务逻辑失败则说明有其他线程正在处理或已处理完成。javapublic void handlePayCallback(PayCallbackDTO dto) {String lockKey “pay” dto.getOrderNo();String lockValue UUID.randomUUID().toString();// 1. 尝试获取分布式锁超时时间30秒 Boolean locked redisClient.setNx(lockKey, lockValue, 30, TimeUnit.SECONDS); if (!locked) { log.warn(订单{}正在被其他线程处理本次回调跳过, dto.getOrderNo()); return; // 直接返回成功 } try { // 2. 双重检查再次查询订单状态防止锁超时后重复处理 Order order orderService.getByOrderNo(dto.getOrderNo()); if (order.getStatus() OrderStatus.PAID) { log.info(订单{}已支付无需重复处理, dto.getOrderNo()); return; } // 3. 执行核心业务 orderService.paySuccess(dto.getOrderNo()); } finally { // 4. 释放锁使用Lua脚本保证原子性只释放自己持有的锁 String script if redis.call(get, KEYS[1]) ARGV[1] then return redis.call(del, KEYS[1]) else return 0 end; redisClient.eval(script, Collections.singletonList(lockKey), Collections.singletonList(lockValue)); }}避坑要点锁的超时时间要合理太短会导致业务未执行完锁自动释放造成重复处理太长会影响并发性能。我们根据压测结果设置为30秒。释放锁必须用Lua脚本先get后del必须原子执行否则可能误删其他线程的锁。必须做双重检查Double-Check如果线程A执行耗时超过30秒锁自动释放线程B获得了锁此时必须再次检查订单状态防止重复执行。优点性能大幅提升Redis操作比数据库插入快一个数量级。减轻数据库压力流水表不再承担防重职责只作为审计日志。缺点依赖Redis高可用如果Redis挂了整个防重机制失效需要设计降级方案降级到数据库唯一索引。五、 演进V3.0幂等令牌Idempotent Token——最优雅的前置方案除了支付回调的防重我们还将幂等思想前置到下单环节。场景用户在提交订单时由于网络卡顿连续点击了3次“提交订单”按钮结果生成了3笔订单扣了3次库存用户一脸懵。解决方案客户端令牌 服务端缓存[用户进入下单页] -- [获取幂等令牌(token)] -- [提交订单时携带token]– [服务端校验token是否存在] -- [存在则删除并创建订单]– [不存在则提示请勿重复提交]核心代码java// 1. 获取令牌接口GetMapping(“/getToken”)public String getToken(RequestParam Long userId) {String token UUID.randomUUID().toString();String key “order:token:” userId “:” token;// 存入Redis有效期5分钟redisClient.setEx(key, “1”, 5, TimeUnit.MINUTES);return token;}// 2. 提交订单接口PostMapping(“/submit”)public Result submitOrder(RequestBody OrderSubmitDTO dto) {String tokenKey “order:token:” dto.getUserId() “:” dto.getToken();// 使用Lua脚本原子性判断key是否存在存在则删除 String script if redis.call(exists, KEYS[1]) 1 then return redis.call(del, KEYS[1]) else return 0 end; Long deleted redisClient.eval(script, Collections.singletonList(tokenKey), Collections.emptyList()); if (deleted 0) { return Result.fail(订单已提交请勿重复操作); } // 正常创建订单... return Result.ok(orderService.createOrder(dto));}核心优势真正的前置防重在业务逻辑执行之前就拦截了重复请求完全不消耗数据库和业务资源。用户体验友好明确的“请勿重复提交”提示而不是让用户等待超时。六、 踩坑实录重试风暴下的链路超时还有一个容易被忽视的问题如果支付渠道的回调被我们的防火墙或网络策略拦截了怎么办现象某次机房割接防火墙规则临时变更导致支付回调被拦截了3分钟。支付渠道在这3分钟内疯狂重试每10秒一次积压了上千个回调请求。网络恢复后所有请求瞬间涌进来我们的服务直接被打挂。解决方案去重窗口 响应码规范在网关层增加去重过滤器对同一transaction_id的请求在网关层就进行拦截5秒内重复请求直接返回200 OK给支付渠道的响应必须是200否则会持续重试。严格遵循支付渠道的响应规范处理成功返回 HTTP 200 {“code”:“SUCCESS”,“message”:“成功”}。处理失败如系统异常返回 HTTP 500 或 非SUCCESS状态码让渠道继续重试。关键误区不要因为业务逻辑已处理就返回错误码这会导致渠道误以为处理失败而持续重试最终形成无限循环。七、 总结幂等性设计的核心原则经过这三个版本的迭代我们总结出幂等性设计的五大核心原则原则 说明 我们的落地方式唯一标识 每次请求必须有唯一ID transaction_id渠道侧 / token客户端侧去重存储 记录已处理的ID支持快速查询 Redis缓存 数据库流水表双保险原子操作 检查写入必须是原子操作 数据库唯一索引 / Redis Lua脚本超时兜底 业务超时不能导致状态不一致 分布式锁超时 双重检查 定时对账监控告警 重复请求次数异常时需要告警 监控重复率阈值超过5%触发告警最终架构全景图[支付渠道回调]– [网关层去重过滤器5秒窗口]– [Redis分布式锁订单级防重]– [数据库唯一索引兜底防重]– [执行业务逻辑订单更新/积分/券/物流]– [异步落库流水表审计日志]– [返回SUCCESS给渠道]压测数据重复请求拦截率99.7%网关层Redis层接口响应时间稳定在 80ms 以内资损事件连续 6个月 零重复支付事故文末思考幂等性是分布式系统的必修课而支付回调的幂等性是电商系统的底线。没有绝对完美的方案只有层层设防、多重兜底的策略才能让团队睡得安稳。欢迎在评论区分享你们的支付回调遇到过哪些奇葩的重复场景是如何解决的