1. 引言

支付中台系统由于其通用、便捷性和高效率的优点，在应用接入与渠道对接聚合中发挥着不可或缺的作用。然而，确保支付中台的可靠性与安全性需要复杂的技术支持。本文将深入探讨回调重试机制和ACK机制，这两种机制在保障交易信息准确传输中扮演着关键角色。

2. 回调重试机制

2.1. 什么是回调重试机制？

回调重试机制是一种在支付交易过程中，用于确保支付信息成功传递给业务服务的技术。当支付中台首次尝试发送交易信息至业务服务器失败时（可能由于网络问题或服务器故障），它会在预定的时间间隔后重试发送。

2.2. 回调重试的必要性

保证数据传输可靠性： 网络不稳定或服务器问题可能导致数据传输失败，重试机制确保信息最终被接收。
提高交易的成功率： 通过多次尝试，减少因技术问题导致的交易失败。

2.3. 回调重试的流程

初始尝试： 支付中台在交易完成后发送通知到业务侧。
失败检测： 如果业务侧未能确认接收，支付中台标记此次尝试为失败。
自动重试： 根据预设的时间间隔，支付中台进行重试。
成功确认： 一旦业务侧成功处理信息并反馈，重试停止。

2.4. 回调重试的挑战

频繁重试： 频繁重试不仅对支付中台性能消耗过多，也对业务侧造成一定影响。
重试时间间隔： 重试间隔不能过短也不宜过长，应制定妥善的间隔方案。

3. ACK机制

3.1. 什么是ACK机制？

ACK机制指的是在接收和处理完支付中台发送的信息后，业务侧服务器向支付中台发送一个确认响应。这个响应告知支付中台信息已被成功接收和处理。

3.2. ACK机制的作用

减少不必要的重试： 通过ACK确认，支付中台知道信息已被成功处理，无需再次发送。
防止数据冗余和混乱： 确保每笔交易只被处理一次。

3.3. 实施ACK机制的挑战

确保实时性： 业务侧系统需要及时处理交易信息并发送ACK。
处理失败情况： 在ACK发送失败或未被支付中台接收的情况下，需要有备用方案。

4. 回调重试与ACK机制的协同作用

这两种机制共同确保了交易信息的准确性和完整性。回调重试保证信息最终到达业务侧，而ACK机制则确认业务侧已正确处理这些信息。它们的协同作用对于维护在线支付的流畅性和安全性至关重要，协同处理流程如下。

5. 落地案例

5.1. 案例说明

下面一张图详细描述了业务侧-中台-支付渠道之间的整个下单、支付、回调的步骤与交互过程，方便我们理解大概的流程。

5.2. ACK机制落地

当中台回调给业务对接方时，需要根据业务对接方的回调返回结果来确定业务对接方是否已经正确处理订单，以及处理订单的结果和状态。

5.2.1. 回调请求体示例

json 复制代码

{
  "businessOrderId": "string,业务订单ID",
  "centerPlatformOrderId": "string,中台订单ID",
  "platformOderId": "string,三方订单ID",
  "state": "订单状态,参观订单状态定义",
  "details": {
    // 渠道特定信息字段...
  }
}

5.2.2. 回调响应体定义

json 复制代码

{
    "code": 200, //code返回200代表回调业务方成功
    "message": "ok",
    "data": {
        "eventState": 1,//回调事件业务处理状态，1:已成功处理，0：未知状态，-1：处理时异常 ...
    }
}

5.2.3. 回调响应处理机制

当code=200并且data数据中eventState=1时，代表业务方已经成功处理订单，则订单完成，无需重试回调。
当code≠200或者data数据中eventState≠1时，代表业务方未处理的订单或者处理异常，需要进行重试回调

5.3. 重试机制落地

当中台回调给业务对接方时，若业务方无正确响应、回调结果异常、响应超时，则启动重试机制策略。

5.3.1. 重试方案

使用RocketMQ延迟消息队列进行延迟重试操作。
使用Redis以订单ID作为Key统计回调重试次数。

5.3.2. 重试策略

退避策略：以1S、5S、30S、1min、2min、5min、10min、30min依次进行自动重试。
兜底策略：若最终退避策略30min始终无法回调成功，发送告警消息，此时联系相关人员进行订单确认。

5.3.3. 策略执行

中台初始收到支付渠道服务提供商的回调立即执行一次回调业务侧操作
回调业务侧时捕获http请求，若出现异常或者超时未响应，执行重试策略。
回调业务侧时若业务方有响应，但未成功返回code=200或者data数据中未成功返回eventState=1，执行重试策略。
回调业务侧之前中台服务出现异常，需要进行异常捕获，执行重试策略。
回调业务侧后一直重试直至退避策略到达30min，标记重试次数已满并发送告警消息，由相关人员进行订单排查或处理。
回调业务侧成功ACK返回相应的正确数据，标记订单已处理成功，退出重试策略。

6. 后续版本优化展望

6.1. 精细化回调重试策略

回调失败原因分类：对回调失败的原因进行详细分类（如网络问题、服务器超载、数据格式错误等），并针对不同原因采取不同的重试策略。
逐步增长的重试间隔：根据失败类型和历史数据，实现逐步增长的重试间隔，避免频繁重试导致的系统负担。

6.2. 精细化ACK响应处理

细分ACK响应状态：不仅仅是简单的成功或失败，而是更多层次的状态表示，如"已接收但未处理"、"处理中"、"处理成功"等。
智能ACK响应解析：根据ACK响应的细节，智能判断下一步操作，如是否需要重试，或是否需人工干预。

6.3. 提升系统的弹性和稳定性

自适应流量控制：在系统负载高时，自动调整回调业务侧频率，避免过载。
优化资源分配：根据实时监控数据，动态调整服务器资源，以优化处理能力。

6.4. 长连接优化

采用HTTP长连接：在与业务服务器的通信中，采用HTTP长连接（而非短连接），减少因频繁建立和断开连接带来的开销。
连接复用：在长连接的基础上，实现连接的复用，提高响应速度，减少资源消耗。

6.5. 回调线程池管理和优化

动态线程池调整：根据实时负载和性能指标（如队列长度、处理时间），动态调整线程池中线程的数量。在交易高峰期自动增加线程数，低峰期适当减少，以优化资源使用和响应时间。
线程池监控：实时监控线程池的状态，如队列大小、活跃线程数等，及时发现潜在的性能瓶颈。

【从0-1业务中台】回调重试与ACK机制的深度解析