登录
HOW如何实现补偿、补单补偿机制？
2023-10-02
1259浏览
HOW如何实现补偿、补单补偿机制？接下来我们用两个维度去设计实现补单补偿机制订单查询的机制是支付系统进行补单和补偿比较核心的一环，支付系统需要对外提供查询接口，让调用方能够知道订单的状态，以及订单是否存在，方便进行补单和补偿的操作，注意的是在设计订单的补偿和补单时需要考虑支付系统落单的时间差（调用支付系统后瞬间做出订单查询接口会返回订单不存在的风险）
什么？ 前言 为什么？ 为什么需要赔偿和补充订单？
我们先简单解释一下什么是“补偿”和“补货单”：
正常情况下，我们的订单系统发起支付并调用支付接口，支付接口同步返回订单支付成功或失败或正在处理中。 但由于系统暴露在网络中，网络不稳定必然导致以下可能：
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次为止。
总结
本文介绍支付系统高可用核心：订单补补的实现方法及实现方法。 这是一个非常好的思维方式，可以应用到很多系统和业务中。 具体的实现方法有所不同，但思想大致相同。 我希望它能给你带来启发。 如果您有任何疑问，请随时给我留言。
以上内容均来自网络搜集，如有侵权联系客服删除
相关阅读
图文阅读
