编者按介：在订单支付过程中，我们经常遇到这样的问题：显然支付了钱，但也扣除了钱，但订单没有成功。


在上面，作者为我们分享了一个解决方案。


在本文中，作者结合实际情况和案例总结了两种系统设计方案。


上次在文章《钱被扣了，订单却没有成功！支付异常最完整的解决方案》中提到，支付过程会出现「掉单、卡单」在这种情况下，对于用户来说，体验非常差，显然他们付了钱，扣除了钱，但订单没有成功。


在最后一篇文章中，我们简要介绍了解决方案。


这一次，小黑哥根据实际生产情况给出了两个详细的设计方案： 定期轮询补偿方案 延迟消息补偿计划 可根据自己系统的实际情况进行选择性参考。


「当然，以下设计方案可能并不完美。


如果读者有其他解决方案，请留言指出，一起讨论，一起成长~」 一、定期轮询补偿方案 1. 整体流程 本方案主要采用定期任务，批量查询订单记录，驱动查询具体支付结果，更新内部订单。


总体方案流程图如下： 定期任务补偿 前三个过程没什么好说的，正常的支付过程，我们详细说明下面几个步骤。


第三步调用支付通道后，如果支付通道端返回「支付受理成功或支付处理成功」，我们需要调用第四步，将此类订单插入单表。


如果支付直接成功，则可以返回正常流程。


回顾一下，支付宝、微信支付、网银支付等网关支付。


在这种支付模式下，支付渠道只能成功返回支付验收，具体支付结果需要接收支付渠道端的支付通知。


我们称之为异步支付。


还有同步支付，如银行卡支付、微信、支付宝代扣支付可以同步返还支付结果。


第五步，补充应用程序定期查询数据库，批量查询订单记录；第六步，补充应用程序使用线程池和多线程异步查询；第七步，调用支付渠道支付查询接口。


如果第七步的支付结果被查询为以下状态： 「支付结果是扣款成功」 「付款结果显然是失败」 「查询掉单记录最大次数」 「第八步删除单记录。


」 最后，如果订单查询仍在处理中，则在一定延迟后，重复第五步，重新订单补偿，直到成功或查询达到最大时间。


2. 相关问题 「为什么需要新的掉单表？不能直接使用支付订单表查询未成功订单吗？」 事实上，支付订单表确实可以直接使用，然后批量查询当天未成功的订单，补充程序启动支付查询。


那为什么要新建掉单表呢？ 这主要是因为数据库查询的效率，因为支付订单表每天都会有大量的新记录。


随着时间的推移，这个表会有越来越多的记录。


「付款记录越多，批量范围查询效率越低，查询速度越慢。


」 因此，为了查询效率，建立一个新的单表。


这张表只记录未成功支付的订单，所以数据量会很小，所以查询效率会很高。


此外，订单丢失表中的记录不会永久保存，而是暂时的。


当支付结果查询成功，或支付结果明显失败，或查询次数达到规定的最大次数时，将删除订单记录。


「这就是为什么第八步需要删除单表。


」 如果您需要保存每个订单丢失表的查询细节，建议添加另一个订单丢失查询记录表，以保存每个查询记录。


如果您有其他问题，请留言。


3. 方案优缺点 定期轮询补偿方案最大的优点可能是系统架构方案相对简单，易于实施方案的缺点主要是「定时任务」上。


定期任务轮询方案自然会有以下不足: 「轮询效率略低」； 每次查询数据库都被记录下来，它仍然会被扫描（补充程序将根据某些策略决定是否启动支付渠道查询）「重复计算」的嫌疑； 「时效性不够好」，若每小时轮询一次，最坏情况下，时间误差小时； 为了解决时效性问题，提高定期任务查询效率， 1 跟踪查询效率 2 重复计算问题会更加明显。


二、延迟消息补偿方案 下面介绍另一种订单损失补偿方案，延迟消息补偿方案，整个过程类似于定期任务方案，最大的区别可能是从一个「拉模式」变成一种「推模式」。


总体方案流程图如下： 该方案的主要流程与定时方案相似，主要区别在于第四步、第五步和第八步。


第四步的过程从插入单表变为「延迟队列发送订单消息」；第五步，补充程序接收订单消息，然后触发付款订单查询；第八步，如果第七步的付款结果查询如下： 支付结果是扣款成功 付款结果显然是失败 查询掉单记录最大次数 补充程序将通知延迟队列成功消费，延迟队列将删除此订单。


其他状态将告知消费无效，延迟队列将在一定延迟后再次发送订单消息，然后继续重复第五步。


方案优缺点： 与定期轮询方案相比，延迟消息方案： 无需查询所有订单 效率高，时效性好 但是，延迟消息的计划需要基于「延迟队列」，实现起来比较复杂，目前开源实现也比较少。


三、小结 在支付过程中，我们可以采用异步补偿方案来解决这个问题，异步补偿方案可以采用以下两种： 定期轮询补偿方案 延迟消息补偿计划 定期轮询补偿方案相对简单，但时效性稍差。


一般来说，延迟消息补偿方案比较好，但实现起来比较复杂。


如果没有定制的延迟时间要求，可以直接使用 RocketMQ 推迟新闻，简单快捷。


另外「延迟队列」还有很多场景更多，不仅可以用于订单补偿，还可以用于支付订单和其他场景。


因此，有能力开发的团队可以开发一个通用的延迟队列。


推荐历史支付文章： 1. 轻轻扫描，立即扣除，解释付款代码背后的原则 2. 产品设计：解释银行卡支付背后的原则 3. 手机没有网络，但仍然可以支付，原则是什么？ 4. 钱被扣了，但订单没有成功！异常支付最完整的解决方案 5. 一个订单，却误付了两笔钱！如何解决这种重复支付异常？ 作者：楼下小黑哥；微信公众号@程序通事、支付行业、后端技术 特别说明：本网站的主要目的是收集与互联网运营相关的干货知识，为运营伙伴提供便利。


本网站收集的公共内容来自互联网或用户的贡献，这并不意味着本网站同意其观点，也不对网站内容的真实性负责。


如有侵权行为，请联系网站管理员删除，。