CN113076200B - 一种基于多路支付通道的通道流量动态调控的方法 - Google Patents

Abstract

本发明公开了一种基于多路支付通道的通道流量动态调控的方法，属于支付系统技术领域，解决了传统技术中成本低廉、交易效率较高的支付通道不能充分使用、未能充分使用各支付通道所分配的最大TPS的问题，其包括步骤A：进行基本参数检核；步骤B：进行静态路由，并获取通道列表LIST_1等步骤，实现了优先使用较优支付通道，充分利用各支付通道所分配的最大TPS的技术效果。

Description

一种基于多路支付通道的通道流量动态调控的方法

技术领域

本发明属于支付系统技术领域，具体涉及一种基于多路支付通道的通道流量动态调控的方法。

背景技术

目前作为银行接入的支付主通道“二代支付系统”仅能提供便捷的跨行转出功能，不能完全满足其它业务需求，需要寻求更多便捷、灵活的支付通道，由于接入通道繁多，并且在不断丰富和扩展，同时各通道功能有互补也有交叉，有交易类型上的不同，也有工作时间、工作效率、交易限额、成本费用、所支持的最大并发请求量等因素的差异，各种错综复杂的组合方式、通道服务是否可用等因素造成支付通道的管理和使用带来了极大挑战。

现有技术方案一般采用搭建统一支付平台的方案。此方案提供一种支付通道智能路由方法，连接业务渠道与各支付通路，屏蔽各支付通路的差异，对外给业务渠道提供标准、统一的充值、提现、转出、转入、实名认证、消费等丰富的联机支付接口功能。以此动态选择价廉质优的支付通道处理支付交易，以实现提升用户支付体验的同时，降低银行的支付通道使用成本。

目前业界所采用的统一支付平台的方案，存在以下缺陷：

1.目前业界所采用的搭建统一支付平台的方案，虽然建立了根据支付通道的成本、交易成功率、交易效率、交易限额等多个因子进行计算、选择出最优支付通道的智能路由方法，但在某个支付通道发生故障的情况下，不能及时自动监控、自动识别通道故障，并自动关闭此支付通道；当此支付通道恢复可用性后，亦不能及时自动探测、及时自动识别出此通道已恢复，并自动启用此支付通道，仅只能人工介入，手动操作和配置系统，达到停用或启用支付通道的目的。发生故障的支付通道不能及时自动关闭，会导致部分交易阻塞；已恢复可用性的支付通道未能及时自动重新启用，将导致成本低廉、交易效率较高的支付通道不能充分使用。

2.当前业界所采用的搭建统一支付平台的方案，所对接的众多支付通道中，各支付通道所能支持的最大并发请求量TPS不一致，当并发请求量超过支付通道所分配给银行的最大TPS，交易会超时、或被支付通道主动拦截报错。且某些支付通道在合作合同谈判时，支付通道会将最大TPS的量作为谈判条件提出，若分配的最大TPS较高，则交易单价成本高；若分配的最大TPS较低，则交易单价成本低。因此在确保交易成功的前提下，统一支付平台需充分、合理使用通道的最大TPS。目前现有的方案，无实时自动计算路由至各支付通道并发流量的算法，不能根据当前已分配至某通道的流量因子动态调整路由至各支付通道的流量大小，导致未能充分使用各支付通道所分配的最大TPS。

发明内容

针对现有技术中成本低廉、交易效率较高的支付通道不能充分使用、未能充分使用各支付通道所分配的最大TPS的问题，本发明提供一种基于多路支付通道的通道流量动态调控的方法，其目的在于：优先使用较优支付通道，充分利用各支付通道所分配的最大TPS

本发明采用的技术方案如下：

一种基于多路支付通道的通道流量动态调控的方法，其特征在于，包括：

步骤A：进行基本参数检核；

步骤B：进行静态路由，并获取通道列表LIST_1；

步骤C:进行特殊路由，若存在特殊路由，则将特殊路由与通道列表LIST_1求交集，并直接使用交集中的支付通道，若交集后不存在数据，则继续沿用静态路由LIST_1；

步骤D：进行动态路由，剃除不符合检查标准的支付通道，经过剃除后获得LIST_2；

步骤E：进行智能路由，通过计算得到LIST_2中最优支付通道，最终以此支付通道进行支付；

步骤F:进行通道并发控制，通过智能路由选中某支付通道，则在Redis中累加此支付通道的请求数，并将请求数的值每隔1分钟清零一次；

步骤G：进行通道健康监控，并关闭不健康通道；

步骤H：进行已关闭通道检测，对于检测成功的通道进行开启。

采用上述方案，可建立根据支付通道的成本、交易成功率、交易效率、交易限额等多个因子进行计算、选择出最优的支付通道，且在支付通道故障时，能够自动检测出故障，并能够自动关闭此支付通道；在支付通道从故障中恢复时，亦能够自动探测出通道已恢复，并能够自动开启此支付通道。并能够根据当前已请求至某通道的流量并发大小，动态判断当前时间是否仍继续路由支付流量至此支付通道，在确保交易成功的情况下，充分使用支付通道所分配的最大TPS。

优选的，所述步骤B的具体步骤为：

步骤B1: 根据商户号，查询商户签约信息表，查询到此商户号所签约的产品，获取所签约的产品编号A；

步骤B2：根据产品编号A，查询产品信息表，查询到此产品所支持的业务类型列表B；判断本次请求的业务类型，是否在列表B中，若存在则进行下一步，若不存在则退出交易；

步骤B3：根据卡号，查询卡bin信息表，查询到此卡号所属卡类型C、卡bin号D，其中C的值为：借记卡、贷记卡；

步骤B4：根据本次请求的业务类型、卡类型C、卡bin号D，查询通道所支持的业务和银行映射表，查询到支持本业务类型、本卡类型C、本银行卡bin的通道列表LIST_1。

优选的，所述步骤E的具体步骤为：

步骤E1：根据步骤D所得出的通道列表LIST_2，逐个遍历列表中的支付通道;

步骤E2：根据LIST_2中的各支付通道编号，从Redis中查询出本通道1分钟内的请求次数X2，并根据X2计算出1分钟内路由至此支付通道的TPS为T1；对比此支付通道所配置的最大TPS数T2，若T1大于或者等于T2，则通道并发维度因子Z_TPS则得分为60,即 Z_TPS=60；若T1小于T2，则通道并发维度因子Z_TPS则得分为100,即 Z_TPS=100,以此计算出各支付通道的并发因子得分列表Z_TPS{x};

步骤E3：根据LIST_2中的各支付通道编号，查询支付通道的交易费率，并与本笔交易金额相乘，计算得出各支付通道的交易手续费，各个支付通道的交易手续费列表为FEE_0，对FEE_0列表中各手续费值进行从大到小进行排序，例如排序后结果为FEE_1，计算各支付通道手续费因子得分列表Z_FEE；

步骤E4：根据LIST_2中的各支付通道编号，查询各支付通道的前2分钟内的交易平均耗时，得出耗时列表TUT_0,根据耗时列表TUT_0计算各支付通道的交易平均耗时因子得分列表Z_TIME；

步骤E5:配置加权权重值，分别为f1、f2、f3，对应Z_TPS、Z_FEE、Z_TIME，通过上述值求该支付通道列表的加权平均数Z_TOTAL值，其计算公式为：Z_TOTAL = (Z_TPS * f1 +Z_FEE * f2 + Z_TIME * f3) / (f1 + f2 + f3)。

步骤E6：根据步骤E5中的到的加权平均数Z_TOTAL{x}值，得到加权平均值列表Z_TOTAL{x}，选中加权平均值列表Z_TOTAL{x}中加权平均值最大的一个通道进行交易，若最大值存在多个相同值的通道，则在这几个通道中随机选择一个支付通道进行交易。

优选的，所述步骤G的具体步骤为：

步骤G1：设置定时任务，每隔2分钟执行一次，查询交易流水表，获取当前时间之前2分钟的交易流水列表JK_LIST1。每条流水包括流水号、交易状态、交易耗时、交易返回码等字段；

步骤G2：遍历JK_LIST1中的数据，根据交易返回码逐条判断，剔除因正常业务原因导致交易失败的流水，剔除因正常业务原因导致失败的交易流水后，得到JK_LIST2；

步骤G3：统计JK_LIST2中成功交易笔数为S,失败交易笔数为F，状态为处理中的交易笔数为P。计算得出交易成功率 SR，计算公式为：SR = (S / (S + F + P)) * 100%；

步骤G4：遍历JK_LIST1，累加交易耗时字段，得到JK_LIST1中所有交易的总耗时TT（total time），统计JK_LIST1中交易总笔数为N，计算得出JK_LIST1中所有交易的平均耗时AT（average time），计算公式为： AT = TT / N；

步骤G5：根据通道编号，查询数据库，获取到此通道所配置的最低交易成功率阈值LSR（lowest success rate），对比SR与LSR大小，若SR小于LSR，则自动修改通道状态，关闭此支付通道。

步骤G6：根据通道编号，以及通道交易平均耗时AT，更新Redis中此通道的平均耗时值。

采用上述方案，通过自动化持续监控，每2分钟扫描一次交易结果，根据交易量、成功率、失败率等维度综合判断每个支付通道的健康度，根据健康度自动化调整支付通道状态，从而高效、实时的调整是否继续路由流量至此支付通道。

优选的，所述步骤H的具体步骤为：

H1：定时任务每隔10分钟执行1次，查询状态为已关闭的通道，得到已关闭通道的列表CTD_LIST；

H2：遍历CTD_LIST，对每个支付通道发起1笔探测交易，探测交易所使用的卡号、户名、手机号等交易要素为前期所准备的探测交易专用账户要素；

H3：若以上探测交易成功，则继续发送10笔探测交易；

H4：若以上探测交易成功率超过通道最低交易成功率阈值LSR，则继续发送100笔探测交易；

H5：若以上探测交易成功率超过通道最低交易成功率阈值LSR，则继续发送300笔探测交易；

H6：若以上探测交易成功率超过通道最低交易成功率阈值LSR，则自动更新此支付通道状态，将此支付通道自动开启。探测交易的成功率计算逻辑与步骤G3一致，计算公式为：SR = (S/(S + F + P)) * 100%；

H7：探测交易资金回流，如果探测交易类型为收款，则计算探测交易的收款笔数和金额，通过付款交易一次性回流资金至收款交易的付款账户；如果探测交易类型为付款，则计算探测交易的付款笔数和金额，通过收款交易一次性回流资金至付款交易的付款账户。

采用上述方案，针对已经关闭的支付通道，使用自动化探测机制，探测已关闭支付通道是否已经恢复健康度，若探测交易的成功率大于通道最低交易成功率阈值LSR，则自动开启此支付通道。自动化探测机制有效的节省了人工介入判断支付通道是否已恢复的相关工作，提高了处理异常支付通道的效率。

优选的，所述步骤F的具体步骤为：

步骤F1：根据通道编号，查询Redis数据，获取到此通道当前的并发数X1，并通过基于Redisson分布式锁对X1进行加锁，并设置加锁超时时间为2秒；

步骤F2：加锁成功状态下，对当前支付通道的并发数X1加1，递增1个请求数；

步骤F3：递增完毕，对当前支付通道的并发数X1值进行解锁；

步骤F4：若加锁失败，或加锁耗时超过2秒，由于并发数X1的计算可以容忍一定的误差，所以直接忽略本次累加，本次不再累加，继续下一步；

步骤F5：针对并发数X1的key设置Redis有效期为60秒，当设定的时间到达，Redis主动清理X1的值，程序进入下一统计时间段的重新累加。

采用上述方案，通过累加单位时间内请求至某支付通道的流量，并对比支付通道所配置的最大TPS值，从而动态调整路由至每个支付通道的流量，使每个支付通道所承载的请求并发数始终在最大TPS范围内，减少因支付通道并发数不足而导致的交易异常，也充分利用了每个支付通道的并发能力。

综上所述，由于采用了上述技术方案，本发明的有益效果是：

1.可建立根据支付通道的成本、交易成功率、交易效率、交易限额等多个因子进行计算、选择出最优的支付通道，且在支付通道故障时，能够自动检测出故障，并能够自动关闭此支付通道；在支付通道从故障中恢复时，亦能够自动探测出通道已恢复，并能够自动开启此支付通道。并能够根据当前已请求至某通道的流量并发大小，动态判断当前时间是否仍继续路由支付流量至此支付通道，在确保交易成功的情况下，充分使用支付通道所分配的最大TPS。

2.通过累加单位时间内请求至某支付通道的流量，并对比支付通道所配置的最大TPS值，从而动态调整路由至每个支付通道的流量，使每个支付通道所承载的请求并发数X1始终在最大TPS范围内，减少因支付通道并发数X1不足而导致的交易异常，也充分利用了每个支付通道的并发能力。

3.通过自动化持续监控，每2分钟扫描一次交易结果，根据交易量、成功率、失败率等维度综合判断每个支付通道的健康度，根据健康度自动化调整支付通道状态，从而高效、实时的调整是否继续路由流量至此支付通道。

4.针对已经关闭的支付通道，使用自动化探测机制，探测已关闭支付通道是否已经恢复健康度，若探测交易的成功率大于通道最低交易成功率阈值LSR，则自动开启此支付通道。自动化探测机制有效的节省了人工介入判断支付通道是否已恢复的相关工作，提高了处理异常支付通道的效率。

附图说明

本发明将通过例子并参照附图的方式说明，其中：

图1是本发明的一种实施方式的总体流程图；

图2是本发明的支付通道运行状态自动化控制图。

具体实施方式

本说明书中公开的所有特征，或公开的所有方法或过程中的步骤，除了互相排斥的特征和/或步骤以外，均可以以任何方式组合。

下面结合图1、图2对本发明作详细说明。

实施例一：

一种基于多路支付通道的通道流量动态调控的方法，包括：

步骤A：进行基本参数检核；

步骤B：进行静态路由，并获取通道列表LIST_1；

步骤C:进行特殊路由，若存在特殊路由，则将特殊路由与通道列表LIST_1求交集，并直接使用交集中的支付通道，若交集后不存在数据，则继续沿用静态路由LIST_1；

步骤D：进行动态路由，剃除不符合检查标准的支付通道，经过剃除后获得LIST_2；

步骤E：进行智能路由，通过计算得到LIST_2中最优支付通道，最终以此支付通道进行支付；

步骤F:进行通道并发控制，通过智能路由选中某支付通道，则在Redis中累加此支付通道的请求数，并将请求数的值每隔1分钟清零一次；

步骤G：进行通道健康监控，并关闭不健康通道；

步骤H：进行已关闭通道检测，对于检测成功的通道进行开启。

所述步骤B的具体步骤为：

步骤B1: 根据商户号，查询商户签约信息表，查询到此商户号所签约的产品，获取所签约的产品编号A；

步骤B2：根据产品编号A，查询产品信息表，查询到此产品所支持的业务类型列表B；判断本次请求的业务类型，是否在列表B中，若存在则进行下一步，若不存在则退出交易；

步骤B3：根据卡号，查询卡bin信息表，查询到此卡号所属卡类型C、卡bin号D。其中C的值为：借记卡、贷记卡；

步骤B4：根据本次请求的业务类型、卡类型C、卡bin号D，查询通道所支持的业务和银行映射表，查询到支持本业务类型、本卡类型C、本银行卡bin的通道列表LIST_1；

所述步骤E的具体步骤为：

步骤E1：根据步骤D所得出的通道列表LIST_2，逐个遍历列表中的支付通道;

步骤E2：根据LIST_2中的各支付通道编号，从Redis中查询出本通道1分钟内的请求次数X2，并根据X2计算出1分钟内路由至此支付通道的TPS为T1；对比此支付通道所配置的最大TPS数T2，若T1大于或者等于T2，则通道并发维度因子Z_TPS则得分为60（分数大小可根据配置灵活调整）,即 Z_TPS=60；若T1小于T2，则通道并发维度因子Z_TPS则得分为100,即 Z_TPS=100，以此计算出各支付通道的并发因子得分列表Z_TPS；

步骤E3：根据LIST_2中的各支付通道编号，查询支付通道的交易费率，并与本笔交易金额相乘，计算得出各支付通道的交易手续费，各个支付通道的交易手续费列表为FEE_0，对FEE_0列表中各手续费值进行从大到小进行排序，例如排序后结果为FEE_1，计算各支付通道手续费因子得分列表Z_FEE；

步骤E4：根据LIST_2中的各支付通道编号，查询各支付通道的前2分钟内的交易平均耗时，得出耗时列表TUT_0,根据耗时列表TUT_0计算各支付通道的交易平均耗时因子得分列表Z_TIME；

步骤E5:配置加权权重值，分别为f1、f2、f3，对应Z_TPS、Z_FEE、Z_TIME，通过上述值求该支付通道列表的加权平均数Z_TOTAL值，其计算公式为：Z_TOTAL = (Z_TPS * f1 +Z_FEE * f2 + Z_TIME * f3) / (f1 + f2 + f3)。

步骤E6：根据步骤E5中的到的加权平均数Z_TOTAL值，得到加权平均值列表Z_TOTAL{x}，选中加权平均值列表Z_TOTAL{x}中加权平均值最大的一个通道进行交易，若最大值存在多个相同值的通道，则在这几个通道中随机选择一个支付通道进行交易。

所述步骤G的具体步骤为：

步骤G1：设置定时任务，每隔2分钟执行一次，查询交易流水表，获取当前时间之前2分钟的交易流水列表JK_LIST1。每条流水包括流水号、交易状态、交易耗时、交易返回码等字段；

步骤G2：遍历JK_LIST1中的数据，根据交易返回码逐条判断，剔除因正常业务原因导致交易失败的流水，剔除因正常业务原因导致失败的交易流水后，得到JK_LIST2；

步骤G3：统计JK_LIST2中成功交易笔数为S,失败交易笔数为F，状态为处理中的交易笔数为P。计算得出交易成功率 SR（ success rate），计算公式为：SR = (S / (S + F +P)) * 100%；

步骤G4：遍历JK_LIST1，累加交易耗时字段，得到JK_LIST1中所有交易的总耗时TT（total time），统计JK_LIST1中交易总笔数为N，计算得出JK_LIST1中所有交易的平均耗时AT（average time），计算公式为： AT = TT / N；

步骤G5：根据通道编号，查询数据库，获取到此通道所配置的最低交易成功率阈值LSR（lowest success rate），对比SR与LSR大小，若SR小于LSR，则自动修改通道状态，关闭此支付通道；

步骤G6：根据通道编号，以及通道交易平均耗时AT，更新Redis中此通道的平均耗时值。

所述步骤H的具体步骤为：

H1：定时任务每隔10分钟执行1次，查询状态为已关闭的通道，得到已关闭通道的列表CTD_LIST；

H2：遍历CTD_LIST，对每个支付通道发起1笔探测交易，探测交易所使用的交易要素为前期所准备的探测交易专用账户要素；

H3：若以上探测交易成功，则继续发送10笔探测交易；

H4：若以上探测交易成功率超过通道最低交易成功率阈值LSR，则继续发送100笔探测交易；

H5：若以上探测交易成功率超过通道最低交易成功率阈值LSR，则继续发送300笔探测交易；

H6：若以上探测交易成功率超过通道最低交易成功率阈值LSR，则自动更新此支付通道状态，将此支付通道自动开启。探测交易的成功率计算逻辑与步骤G3一致，计算公式为：SR = (S/(S + F + P)) * 100%；

H7：探测交易资金回流，如果探测交易类型为收款，则计算探测交易的收款笔数和金额，通过付款交易一次性回流资金至收款交易的付款账户；如果探测交易类型为付款，则计算探测交易的付款笔数和金额，通过收款交易一次性回流资金至付款交易的付款账户。

所述步骤F的具体步骤为：

步骤F1：根据通道编号，查询Redis数据，获取到此通道当前的并发数X1，并通过基于Redisson分布式锁对X1进行加锁，并设置加锁超时时间为2秒；

步骤F2：加锁成功状态下，对当前支付通道的并发数X1加1，递增1个请求数；

步骤F3：递增完毕，对当前支付通道的并发数X1值进行解锁；

步骤F4：若加锁失败，或加锁耗时超过2秒，由于并发数X1的计算可以容忍一定的误差，所以直接忽略本次累加，本次不再累加，继续下一步；

步骤F5：针对并发数X1的key设置Redis有效期为60秒，当设定的时间到达，Redis主动清理X1的值，程序进入下一统计时间段的重新累加。

在上述实施例中，为说明本发明中的方法，设定所有通道列表LIST_1为LIST_1[TD1,TD2,TD3,TD4,TD5,TD6,TD7,TD8,TD9,TD10,TD11,TD12,TD13,TD14,TD15]，其中含有15个支付通道，在完成步骤D的动态路由后，将不通过的支付通道剔除，得到LIST_2[TD1,TD2,TD4,TD5,TD7,TD8,TD9,TD11,TD12,TD15]，将LIST_2进行智能路由，逐个遍历TD1,TD2,TD4……TD15等剩余支付通道。根据通道编号从Redis中查询出本通道1分钟内的请求次数X2，并计算1分钟内路由至此支付通道的TPS。根据各支付通道的费率，与本笔交易金额做乘法，计算出本笔交易的手续费；根据通道编号，从Redis中查询出本通道前2分钟内的交易平均耗时值；综合手续费、交易平均耗时、各支付通道当前的TPS等因子，根据这3个维度所配置的权重f1、f2、f3，计算出各支付通道的加权平均分数，根据各支付通道所获得的加权平均分数对比出最优支付通道，最终以此支付通道进行交易。

以上所述实施例仅表达了本申请的具体实施方式，其描述较为具体和详细，但并不能因此而理解为对本申请保护范围的限制。应当指出的是，对于本领域的普通技术人员来说，在不脱离本申请技术方案构思的前提下，还可以做出若干变形和改进，这些都属于本申请的保护范围。

Claims (4)

1.一种基于多路支付通道的通道流量动态调控的方法，其特征在于，包括：

步骤A：进行基本参数检核；

步骤B：进行静态路由，并获取通道列表LIST_1；

步骤C:进行特殊路由，若存在特殊路由，则将特殊路由与通道列表LIST_1求交集，并直接使用交集中的支付通道，若交集后不存在数据，则继续沿用静态路由LIST_1；

步骤D：进行动态路由，剃除不符合检查标准的支付通道，经过剃除后获得LIST_2；

步骤E：进行智能路由，通过计算得到LIST_2中最优支付通道，最终以此支付通道进行支付；

步骤F:进行通道并发控制，通过智能路由选中某支付通道，则在Redis中累加此支付通道的请求数，并将请求数的值每隔1分钟清零一次；

步骤G：进行通道健康监控，并关闭不健康通道；

步骤H：进行已关闭通道检测，对于检测成功的通道进行开启；

所述步骤E的具体步骤为：

步骤E1：根据步骤D所得出的通道列表LIST_2，逐个遍历列表中的支付通道;

步骤E2：根据LIST_2中的各支付通道编号，从Redis中查询出本通道1分钟内的请求次数X2，并根据X2计算出1分钟内路由至此支付通道的TPS为T1；对比此支付通道所配置的最大TPS数T2，若T1大于或者等于T2，则通道并发维度因子Z_TPS则得分为60,即 Z_TPS=60；若T1小于T2，则通道并发维度因子Z_TPS则得分为100,即 Z_TPS=100，以此计算出各支付通道的并发因子得分列表Z_TPS；

步骤E3：根据LIST_2中的各支付通道编号，查询支付通道的交易费率，并与本笔交易金额相乘，计算得出各支付通道的交易手续费，各个支付通道的交易手续费列表为FEE_0，对FEE_0列表中各手续费值进行从大到小进行排序，例如排序后结果为FEE_1，计算各支付通道手续费因子得分列表Z_FEE；

步骤E4：根据LIST_2中的各支付通道编号，查询各支付通道的前2分钟内的交易平均耗时，得出耗时列表TUT_0,根据耗时列表TUT_0计算各支付通道的交易平均耗时因子得分列表Z_TIME；

步骤E5:配置加权权重值，分别为f1、f2、f3，对应Z_TPS、Z_FEE、Z_TIME，通过上述值求该支付通道列表的加权平均数Z_TOTAL值，其计算公式为：Z_TOTAL = (Z_TPS * f1 + Z_FEE * f2 + Z_TIME * f3) / (f1 + f2 + f3)；

步骤E6：根据步骤E5中的到的加权平均数Z_TOTAL值，得到加权平均值列表Z_TOTAL{x}，选中加权平均值列表Z_TOTAL{x}中加权平均值最大的一个通道进行交易，若最大值存在多个相同值的通道，则在这几个通道中随机选择一个支付通道进行交易；

所述步骤G的具体步骤为：

步骤G1：设置定时任务，每隔2分钟执行一次，查询交易流水表，获取当前时间之前2分钟的交易流水列表JK_LIST1，每条流水包括流水号、交易状态、交易耗时、交易返回码；

步骤G2：遍历JK_LIST1中的数据，根据交易返回码逐条判断，剔除因正常业务原因导致交易失败的流水，剔除因正常业务原因导致失败的交易流水后，得到JK_LIST2；

步骤G3：统计JK_LIST2中成功交易笔数为S,失败交易笔数为F，状态为处理中的交易笔数为P，计算得出交易成功率SR，计算公式为：SR = (S / (S + F + P)) * 100%；

步骤G4：遍历JK_LIST1，累加交易耗时字段，得到JK_LIST1中所有交易的总耗时TT，统计JK_LIST1中交易总笔数为N，计算得出JK_LIST1中所有交易的平均耗时AT，计算公式为：AT = TT / N；

步骤G5：根据通道编号，查询数据库，获取到此通道所配置的最低交易成功率阈值LSR，对比SR与LSR大小，若SR小于LSR，则自动修改通道状态，关闭此支付通道；

步骤G6：根据通道编号，以及通道交易平均耗时AT，更新Redis中此通道的平均耗时值。

2.根据权利要求1所述的一种基于多路支付通道的通道流量动态调控的方法，其特征在于，所述步骤B的具体步骤为：

步骤B1: 根据商户号，查询商户签约信息表，查询到此商户号所签约的产品，获取所签约的产品编号A；

步骤B2：根据产品编号A，查询产品信息表，查询到此产品所支持的业务类型列表B；判断本次请求的业务类型，是否在列表B中，若存在则进行下一步，若不存在则退出交易；

步骤B3：根据卡号，查询卡bin信息表，查询到此卡号所属卡类型C、卡bin号D，其中C的值为：借记卡、贷记卡；

步骤B4：根据本次请求的业务类型、卡类型C、卡bin号D，查询通道所支持的业务和银行映射表，查询到支持本业务类型、本卡类型C、本银行卡bin的通道列表LIST_1。

3.根据权利要求1所述的一种基于多路支付通道的通道流量动态调控的方法，其特征在于，所述步骤H的具体步骤为：

H1：定时任务每隔10分钟执行1次，查询状态为已关闭的通道，得到已关闭通道的列表CTD_LIST；

H2：遍历CTD_LIST，对每个支付通道发起1笔探测交易，探测交易所使用的交易要素为前期所准备的探测交易专用账户要素；

H3：若以上探测交易成功，则继续发送10笔探测交易；

H4：若以上探测交易成功率超过通道最低交易成功率阈值LSR，则继续发送100笔探测交易；

H5：若以上探测交易成功率超过通道最低交易成功率阈值LSR，则继续发送300笔探测交易；

H6：若以上探测交易成功率超过通道最低交易成功率阈值LSR，则自动更新此支付通道状态，将此支付通道自动开启，探测交易的成功率计算逻辑与步骤G3一致，计算公式为：SR=(S/(S + F + P)) * 100%；

H7：探测交易资金回流，如果探测交易类型为收款，则计算探测交易的收款笔数和金额，通过付款交易一次性回流资金至收款交易的付款账户；如果探测交易类型为付款，则计算探测交易的付款笔数和金额，通过收款交易一次性回流资金至付款交易的付款账户。

4.根据权利要求1所述的一种基于多路支付通道的通道流量动态调控的方法，其特征在于，所述步骤F的具体步骤为：

步骤F1：根据通道编号，查询Redis数据，获取到此通道当前的并发数X1，并通过基于Redisson分布式锁对X1进行加锁，并设置加锁超时时间为2秒；

步骤F2：加锁成功状态下，对当前支付通道的并发数X1加1，递增1个请求数；

步骤F3：递增完毕，对当前支付通道的并发数X1值进行解锁；

步骤F4：若加锁失败，或加锁耗时超过2秒，由于并发数X1的计算可以容忍一定的误差，所以直接忽略本次累加，本次不再累加，继续下一步；

步骤F5：针对并发数X1的key设置Redis有效期为60秒，当设定的时间到达，Redis主动清理X1的值，程序进入下一统计时间段的重新累加。

Images