什么？ 前言 为什么？ 为什么需要赔偿和补充订单？

我们先简单解释一下什么是“补偿”和“补货单”：

正常情况下，我们的订单系统发起支付并调用支付接口，支付接口同步返回订单支付成功或失败或正在处理中。 但由于系统暴露在网络中，网络不稳定必然导致以下可能：

HOW 追加订单如何实现补偿？

接下来我们从两个维度来设计并实现补单补偿机制。

1.基本设计

唯一的订单号和幂等性应该是订单系统和支付系统的基础。 想象一下，如果两个具有相同订单号的订单被支付两次，将会产生严重的后果，所以无论是订单系统还是支付系统，首先需要保证的是订单的唯一性和幂等性。 也就是同一个订单号进入支付系统时补单，需要返回已有的订单补单，而不是直接插入数据库（不了解幂等的可以自行搜索，不再赘述这里）。

异常机制是业务订单系统中需要考虑的一个开发设计点。 想象一下，订单请求超时，报错，报订单业务错误。 我们将两者视为失败是否合理？ 因此，在“网络超时等系统级异常”的情况下，我们不需要对订单进行状态操作，而是标记订单或者不需要标记订单等待补偿，而“失败”订单业务”如：余额不足、账户异常等其他业务异常需要根据业务单独处理，并记录错误原因，方便查看。

订单查询机制是支付系统的核心部分，用于订单补补和补偿。 支付系统需要提供对外的查询接口，以便调用者可以了解订单的状态以及订单是否存在，从而方便进行订单补货和补偿操作。 注意最重要的是，在设计订单补偿和补货时，需要考虑支付系统与订单的时间差（存在调用支付系统后立即查询订单接口返回订单不存在的风险）不存在）

补偿：调用查询接口查找订单。 如果成功，则将订单更新为最终状态并结束流程。

订单补货：如果发现订单不存在，则需要再次调用支付接口完成订单补货（原订单号）

2、具体实施方法

在实现补单补货的业务中，定时任务是一个比较好的执行方案。 市面上的XXL-job和elastic-job是比较成熟的第三方定时任务解决方案，已经应用于生产。

业务实施：可使用两个岗位。

一是定期查看订单表中正在处理的订单，然后调用查询接口查看订单是否已经成功。 如果更新成功，则等待下一个计划任务，如果不成功则等待下一个计划任务。

第二个作业检查正在处理的订单是否存在。 如果不存在，则使用订单补货逻辑。

与rocketmq类似，具有延迟消息的功能。 具体来说，它在发送消息时设置延迟发送级别。 消息会在一段时间后发送，而不是立即发送（关于rocketmq延迟消息的文章有很多，这里不再讨论）。 正好可以做订单的补偿逻辑，具体实现是：

RocketMQ默认补偿级别为： 1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h（16级）

1.自定义补偿间隔，自定义补偿间隔如5s、30s、1m、2m、2m、4m、4m、5m、2m、5m、5m、30m、1h、2h，如果每次收到都这样做message 如果订单正在查询或处理中，则补偿次数+1。 使用自定义补偿时间查看rocketmq的补偿等级来自定义补偿时间间隔。

2. 设置最大补偿次数。 我们可以自定义最大补偿次数，比如30次。 这样，我们自定义的补偿间隔后，就会按照上次延迟消息间隔进行补偿，直到30次为止。

总结

本文介绍支付系统高可用核心：订单补补的实现方法及实现方法。 这是一个非常好的思维方式，可以应用到很多系统和业务中。 具体的实现方法有所不同，但思想大致相同。 我希望它能给你带来启发。 如果您有任何疑问，请随时给我留言。

以上内容均来自网络搜集，如有侵权联系客服删除