CN114428697A - 大批量数据重试机制的实现 - Google Patents

Abstract

本发明公开了一种大批量数据重试机制的实现方法，实际应用场景中，出现大量数据异常后，如果将异常数据直接返回给商户，将导致商户出现大量失败交易，从而极大影响商户业务。本发明通过大批量数据重试机制，解决了上面的的问题，本发明的优点如下：操作简单，可以通过配置实现功能；安全可控，不会因重试出现长短款行为；支持数据体量大，可支持上万级别的数据重试；应用广泛，场景扩展性好，几乎可以支持所有数据量大，但实时性要求不高的场景，目前已经应用于电信话费批扣等场景；可节约银行通道成本。

Description

大批量数据重试机制的实现

技术领域

本发明涉及数据重试领域，特别涉及大批量数据集中代扣在异常情况下的大批量重试。

背景技术

现有话费批量代扣业务严重依赖于银行通道能力，实际场景下，需要综合考虑渠道成本，代扣成功率，支持扣费银行，文件回盘时效等各项因素。由于各家银行通道能力不完全一样，如果仅单纯用传统批扣模式，即商户送盘，我方系统入库，选择银行通道路由，发送银行，等待银行回盘，回盘给商户的时序。这条链路需要经过批扣系统，交易系统，银行网关，银行系统等，当某个环节出现问题时，会出现大量异常订单，如果不介入异常订单处理，则会将大批量异常订单回盘给商户，严重影响商户感知。在此业务场景下，大批量数据重试机制即为解决此问题而生。

发明内容

本发明要解决的技术问题是克服现有技术的缺陷，提供一种大批量数据重试机制的实现方法。

本发明提供了如下的技术方案：

本发明提供一种大批量数据重试机制的实现方法，包括以下步骤：

S1、系统读取分布式配置系统定义的相关配置确认重试触发响应码和最大重试次数；对于某些银行响应码信息，区分为用户原因的错误信息和系统原因的错误信息，对于用户原因，比如6502(余额不足)，6515(密码错误)，6545(无效卡号)等错误信息，由于用户原因或者卡本身的原因，无需配置配置重试触发响应码；对于系统原因的错误信息，比如6543(网络通讯故障)，6702(系统故障)等明确系统原因导致的错误失败信息，则应该加入到重试配置上；最大重试次数，实际上是用消耗时间的方式，实现提升业务成功率的效果，这个要综合考虑系统实际情况和商户本身能否接受等要素，配置一个合理的数值；

S2、失败交易按配置区分可重试和无需重试；在实际场景中，存在部分部分无需重试的场景，比如无可用银行通道，商户对大批量数据处理处理时效限制等，此时通过关停重试定时任务，配置可重试次数为0，达到不重试的效果；当出现系统异常，银行通道异常，商户在追求扣费成功率的基础上，可以容忍的较长时间的处理，此时通过开启定时任务，配置可重试次数，达到重试效果；

S3、可重试订单信息记入重试记录表；重试记录表登记批次号，流水号，原流水号，重试次数，状态等信息；系统运行时，检测可重试配置是否满足要求，当订单记录满足重试次数<最大次数，返回码在配置的重试响应码返回内，系统将订单信息插入重试记录表；

S4、系统定时任务扫描重试订单表，对满足条件的订单发起重试扣款；定时任务间隔时长可控制，每批次取重试笔数可控制，重试次数可控制；在实际应用中，可通过智能路由的方式，对于重试的订单进行通道路由切换；

S5、系统通过对重试订单结果进行扫描，当扫描的结果不符合再次重试的要求，比如错误码已经不在重试列表或者重试次数已经超过最大次数，则会将信息更新至主单表；待所有数据更新完毕，满足回盘条件，系统发起回盘，完成本次交易。

与现有技术相比，本发明的有益效果如下：

1.支持大批量数据重试，理论上来说，可以支持到百万级别的数据处理，

(1)传统重试机制，一般是针对单笔扣费的处理方式，处理能力有限，但是不适合于针对批扣等场景的处理，当出现系统异常，或者银行异常时，出现上万笔异常情形下，传统重试机制显然不适用；

(2)大批量数据重试机制通过预置中间状态，阻断回盘动作，通过定时任务扫描异常批次内的明细，实现对全量异常订单重试能力；

2.确定性错误码信息，杜绝重复扣款可能性；

3.多通道扣费，最大限度“榨取”银行能力；

4.节约成本，通过算法机制，优先走低费率的通道，从而在最大程度上节约了银行通道手续费成本。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1是本发明的系统结构示意图；

图2是本发明实例应用示意图；

图3是本发明重试单与原单对应关系示意图。

具体实施方式

以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。其中附图中相同的标号全部指的是相同的部件。

实施例1

如图1-3，本发明提供一种大批量数据重试机制实现的方法，包括以下步骤：

S1、系统读取分布式配置系统定义的相关配置确认重试触发响应码和最大重试次数。对于某些银行响应码信息，区分为用户原因的错误信息和系统原因的错误信息，对于用户原因，比如6502(余额不足)，6515(密码错误)，6545(无效卡号)等错误信息，由于用户原因或者卡本身的原因，无需配置配置重试触发响应码；对于系统原因的错误信息，比如6543(网络通讯故障)，6702(系统故障)等明确系统原因导致的错误失败信息，则应该加入到重试配置上。最大重试次数，实际上是用消耗时间的方式，实现提升业务成功率的效果，这个要综合考虑系统实际情况和商户本身能否接受等要素，配置一个合理的数值。

S2、失败交易按配置区分可重试和无需重试。在实际场景中，存在部分部分无需重试的场景，比如无可用银行通道，商户对大批量数据处理处理时效限制等，此时通过关停重试定时任务，配置可重试次数为0，达到不重试的效果。当出现系统异常，银行通道异常，商户在追求扣费成功率的基础上，可以容忍的较长时间的处理，此时通过开启定时任务，配置可重试次数，达到重试效果。

S3、可重试订单信息记入重试记录表。重试记录表登记批次号，流水号，原流水号，重试次数，状态等信息。系统运行时，检测可重试配置是否满足要求，当订单记录满足重试次数<最大次数，返回码在配置的重试响应码返回内，系统将订单信息插入重试记录表。

S4、系统定时任务扫描重试订单表，对满足条件的订单发起重试扣款。定时任务间隔时长可控制，每批次取重试笔数可控制，重试次数可控制。在实际应用中，可通过智能路由的方式，对于重试的订单进行通道路由切换。

S5、系统通过对重试订单结果进行扫描，当扫描的结果不符合再次重试的要求，比如错误码已经不在重试列表或者重试次数已经超过最大次数，则会将信息更新至主单表。待所有数据更新完毕，满足回盘条件，系统发起回盘，完成本次交易。

具体的，示例过程如下：

1.读取分布式配置系统定义的相关配置确认重试触发响应码和最大重试次数；

2.失败交易按配置区分可重试和无需重试；

3.可重试订单信息记入重试记录表；

4.根据原单生成新的重试订单记录；

5.定时获取重试订单列表发起交易请求；

6.重试订单更新重试表记录状态，成功交易更新订单表记录，失败交易继续按配置区分可重试和无需重试；

7.继续根据原单生成新的重试订单记录，重试次数+1；

8.重试直至响应码不匹配试触发响应码或达到最大重试次数。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (1)

1.大批量数据重试机制的实现，其特征在于，包括以下步骤：

S1、系统读取分布式配置系统定义的相关配置确认重试触发响应码和最大重试次数；对于某些银行响应码信息，区分为用户原因的错误信息和系统原因的错误信息，对于用户原因，比如6502(余额不足)，6515(密码错误)，6545(无效卡号)等错误信息，由于用户原因或者卡本身的原因，无需配置配置重试触发响应码；对于系统原因的错误信息，比如6543(网络通讯故障)，6702(系统故障)等明确系统原因导致的错误失败信息，则应该加入到重试配置上；最大重试次数，实际上是用消耗时间的方式，实现提升业务成功率的效果，这个要综合考虑系统实际情况和商户本身能否接受等要素，配置一个合理的数值；

S2、失败交易按配置区分可重试和无需重试；在实际场景中，存在部分部分无需重试的场景，比如无可用银行通道，商户对大批量数据处理处理时效限制等，此时通过关停重试定时任务，配置可重试次数为0，达到不重试的效果；当出现系统异常，银行通道异常，商户在追求扣费成功率的基础上，可以容忍的较长时间的处理，此时通过开启定时任务，配置可重试次数，达到重试效果；

S3、可重试订单信息记入重试记录表；重试记录表登记批次号，流水号，原流水号，重试次数，状态等信息；系统运行时，检测可重试配置是否满足要求，当订单记录满足重试次数<最大次数，返回码在配置的重试响应码返回内，系统将订单信息插入重试记录表；

S4、系统定时任务扫描重试订单表，对满足条件的订单发起重试扣款；定时任务间隔时长可控制，每批次取重试笔数可控制，重试次数可控制；在实际应用中，可通过智能路由的方式，对于重试的订单进行通道路由切换；

S5、系统通过对重试订单结果进行扫描，当扫描的结果不符合再次重试的要求，比如错误码已经不在重试列表或者重试次数已经超过最大次数，则会将信息更新至主单表；待所有数据更新完毕，满足回盘条件，系统发起回盘，完成本次交易。

Images