一种基于柔性分布式事务的聚合双活支付方法及系统

技术领域

本发明涉及聚合支付业务领域，具体而言，涉及一种基于柔性分布式事务的聚合双活支付方法及系统。

背景技术

随着中国电信集团推进5G会员运营、O2O商户金卡等线上业务的发展，微信小程序、翼支付客户端等用户触达渠道将逐步拓展多品类运营产品。通过聚合支付业务赋能商家实现对微信、支付宝用户的收单、退款，是拓展用户和商户的十分重要的手段。

聚合支付对支付系统的稳定性、拓展性、安全性等性能要求很高，而目前的聚合支付系统存在以下问题：1.接口及应用杂糅，安全性和稳定性不足：现有聚合支付业务通过3.0网银支付链路实现，接口糅杂在一起，拓展性差、稳定性得不到保障；2.研发效能较低；3.异常人工处理机制不完善：一旦出现业务降级或者不可用，将极大降低商户与用户的使用体验，同时容易引起大量投诉。

发明内容

本发明的目的在于提供一种基于柔性分布式事务的聚合双活支付方法及系统，通过设置差错补偿机制，提高了平台容错试错的能力，保障平台的稳定性和健壮性；并采用柔性分布式事务处理方式，保证事务的最终一致性，使平台在聚合收单场景下具有更高的性能、更快的响应速度，交易处理更加高效。

本发明的实施例是这样实现的：

第一方面，本申请实施例提供一种基于柔性分布式事务的聚合双活支付方法，其包括：

基于流量路由标准，在开放平台构建双活环境，并为不同的环境赋予对应的环境标识；

获取新增支付订单，根据订单对应的环境标识，将订单切入对应的环境链路下传输至支付平台；若环境出现异常，则将订单切入另一个环境链路下并传输至支付平台；

支付平台根据新增支付订单的聚合支付请求进行扣款，并从信息流和资金流两方面进行柔性分布式事务处理，保证订单信息的一致性；

将处理得到的结果同步返回/通过异步消息通知的方式发送至上层聚合交易系统。

基于第一方面，在本发明的一些实施例中，信息流的处理过程包括：

响应于新增支付订单的聚合支付请求，调用营销系统进行优惠核销，若核销成功则调用清分系统，进行金额扣减；若清分失败，则对已核销的优惠进行回退，保证各系统订单状态一致。

基于第一方面，在本发明的一些实施例中，资金流的处理过程包括：

若调用营销系统返回成功，则完成立减内部户到支付内部户的记账操作；若调用清分系统返回成功，则完成清分内部户到支付内部户的记账操作；若调用营销系统和清分系统均成功后，则完成支付内部户到商户待结算户的记账操作；并且当信息流进行回退时，记账信息同步回退。

基于第一方面，在本发明的一些实施例中，还包括：

响应于交易请求，进行落单、限额校验和风控校验，校验均通过后，则新增支付订单。

第二方面，本申请实施例提供一种基于柔性分布式事务的聚合双活支付系统，其包括：

环境标识设置模块，用于基于流量路由标准，在开放平台构建双活环境，并为不同的环境赋予对应的环境标识；

聚合双活链路模块，用于获取新增支付订单，根据订单对应的环境标识，将订单切入对应的环境链路下传输至支付平台；若环境出现异常，则将订单切入另一个环境链路下并传输至支付平台；

聚合支付模块，支付平台根据新增支付订单的聚合支付请求进行扣款，并从信息流和资金流两方面进行柔性分布式事务处理，保证订单信息的一致性；

结果返回模块，用于将处理得到的结果同步返回/通过异步消息通知的方式发送至上层聚合交易系统。

第三方面，本申请实施例提供一种电子设备，其包括存储器，用于存储一个或多个程序；处理器。当上述一个或多个程序被上述处理器执行时，实现如上述第一方面中任一项上述的方法。

第四方面，本申请实施例提供一种计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现如上述第一方面中任一项上述的方法。

相对于现有技术，本发明的实施例至少具有如下优点或有益效果：

本申请实施例提供一种基于柔性分布式事务的聚合双活支付方法及系统，首先，基于流量路由标准，在开放平台构建双活环境，并为不同的环境赋予对应的环境标识。然后，获取新增支付订单，根据订单对应的环境标识，将订单切入对应的环境链路下传输至支付平台；若环境出现异常，则将订单切入另一个环境链路下并传输至支付平台。从而实现两套环境的数据隔离，使两环境下的数据互不影响，达到应用的高可用性，提高容灾度，保证交易不受影响。之后，支付平台根据新增支付订单的聚合支付请求进行扣款，并从信息流和资金流两方面进行柔性分布式事务处理，保证订单信息的一致性。比起用现存的重量级分布式框架，具有更高的效率、更快的响应速度，对带有运营商特色的特殊业务存在更多的操作空间。最后，将处理得到的结果同步返回/通过异步消息通知的方式发送至上层聚合交易系统，进行后续处理。整体而言，本申请一方面通过设置差错补偿机制，提高了平台容错试错的能力，保障平台的稳定性和健壮性；另一方面，采用柔性分布式事务处理方式，保证事务的最终一致性，使平台在聚合收单场景下具有更高的性能、更快的响应速度，交易处理更加高效。

附图说明

为了更清楚地说明本发明实施例的技术方案，下面将对实施例中所需要使用的附图作简单地介绍，应当理解，以下附图仅示出了本发明的某些实施例，因此不应被看作是对范围的限定，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他相关的附图。

图1为本发明提供的一种基于柔性分布式事务的聚合双活支付方法一实施例的步骤框图；

图2为本发明提供的一种基于柔性分布式事务的聚合双活支付方法一实施例中聚合双活环境的实现过程；

图3为本发明提供的一种基于柔性分布式事务的聚合双活支付方法一实施例中采用银行卡+营销支付的流程示意图；

图4-a为本发明提供的一种基于柔性分布式事务的聚合双活支付方法一实施例的下单支付流程的部分示意图；

图4-b为本发明提供的一种基于柔性分布式事务的聚合双活支付方法一实施例的下单支付流程的另一部分示意图；

图5为本发明提供的一种基于柔性分布式事务的聚合双活支付系统的结构框图；

图6为本发明实施例提供的一种电子设备的结构框图。

图标：1、存储器；2、处理器；3、通信接口；11、环境标识设置模块；12、聚合双活链路模块；13、聚合支付模块；14、结果返回模块。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。通常在此处附图中描述和示出的本申请实施例的组件可以以各种不同的配置来布置和设计。

因此，以下对在附图中提供的本申请的实施例的详细描述并非旨在限制要求保护的本申请的范围，而是仅仅表示本申请的选定实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

实施例

下面结合附图，对本申请的一些实施方式作详细说明。在不冲突的情况下，下述的各个实施例及实施例中的各个特征可以相互组合。

请参照图1，图1所示为本申请实施例提供的一种基于柔性分布式事务的聚合双活支付方法的步骤框图，该方法包括以下步骤：

步骤S1：基于流量路由标准，在开放平台构建双活环境，并为不同的环境赋予对应的环境标识。

上述步骤中，随着商业经营的5G金卡商户的不断推进，以及聚合业务的不断发展，对于外在流量的不可预测性和冲击性必须要做好重点业务的流量控制。因此，为达到系统的高可用的要求，在系统中设计了聚合双活环境，以提高系统的可用性、稳定性。本发明从商户和用户的维度，通过设置环境标识，从开放平台开始做流量分仓、限流直到底层业务平台。每笔交易走哪个环境从开放平台就已经路由决定好。例如：日常南京1环境标识设置为：aggregation.trade.constant.env＝PRO；南京2环境标识设置为：aggregation.trade.constant.env＝PRO-NJ2。

步骤S2：获取新增支付订单，根据订单对应的环境标识，将订单切入对应的环境链路下传输至支付平台；若环境出现异常，则将订单切入另一个环境链路下并传输至支付平台。

请参照图2，在开放平台进行流量路由并打上对应的环境标识后，比如同一套应用分别在两套环境中独立部署，走南京1环境的就通过赋予PRO标识传输下去，走南京2环境的就通过赋予PRO-NJ2标识传输下去。从而形成两条独立的链路，保证环境的高度隔离。而后在传输过程中，如果收单平台在南京1环境出现异常，则可以及时将开关标识打到PRO-NJ2上，将订单流量全部切入南京2环境，以保证交易不受影响。

进一步地，在进行新老版本系统同步过程中，可以为商户指定对应的环境链路，形成商户名单。然后应用时，就直接按照指定商户路由到指定链路，完成新版本验证。示例性的，在实现灰度发布中，将指定应用节点通过标签形式设置为灰度标签，例如：

RpcContext.getContext().setAttachment(CommonConstants.TAG_KE Y,"mixpay")，从而实现真正的独立部署，提升系统的高可用能力。

上述步骤通过在底层聚合支付平台设置环境标识，实现两套环境的数据隔离，使得PRO和PRO-NJ2两个环境的数据完全隔离、互不影响，保证环境的高度隔离，达到应用的高可用要求，提高容灾度。

步骤S3：支付平台根据新增支付订单的聚合支付请求进行扣款，并从信息流和资金流两方面进行柔性分布式事务处理，保证订单信息的一致性。

进一步地，信息流与资金流两个分支的处理过程如下：

信息流：响应于新增支付订单的聚合支付请求，调用营销系统进行优惠核销，若核销成功则调用清分系统，进行金额扣减；若清分失败，则对已核销的优惠进行回退，保证各系统订单状态一致。

资金流：若调用营销系统返回成功，则完成立减内部户到支付内部户的记账操作；若调用清分系统返回成功，则完成清分内部户到支付内部户的记账操作；若调用营销系统和清分系统均成功后，则完成支付内部户到商户待结算户的记账操作；并且当信息流进行回退时，记账信息同步回退。

上述步骤中，柔性事务保持最终一致性主要用于多资金源支付场景，例如：余额+营销支付方式、银行卡+营销支付方式、白条+营销支付方式等。其中，营销支付方式包含：立减、红包金、代金券等。而在多资金源支付情况下会涉及调用多个系统，存在跨系统、跨数据库的情况，所以通常会采用尝试、确认和回退操作，以保证分布式事务的一致性。而本发明针对多资金支付请求，通过信息流与资金流两个分支实现订单处理与记账，两分支相互独立又有先后顺序依赖，从而保证事务的一致性。

具体的，请参照图3，以银行卡+营销支付方式的柔性分布式事务处理为例，信息流与资金流两个分支的处理过程如下：

信息流：多资金源调用时，先调用营销立减系统进行立减优惠的核销，若此时核销失败，则代表该笔订单失败；若核销成功，则继续调用清分系统，对银行卡金额进行扣减。若清分成功，即银行卡金额扣减成功；若清分失败，则需对已核销的立减优惠进行回退操作，保证各系统订单状态一致，完成订单信息流闭环。

资金流：在营销调用返回成功后，完成立减内部户到支付内部户的记账操作；在清分调用返回成功后，完成清分内部户到支付内部户的记账操作；在营销、清分系统均调用成功后，再完成支付内部户到商户待结算户的记账操作。同时，在信息流需要回退时，将记账信息同步回退。从而，通过使用异步保成功机制，降低账务系统的耦合度，使记账功能不影响订单信息的流转闭环，还可以使资金流和信息流保持一致。比起用现存的重量级分布式框架，具有更高的效率、更快的响应速度，对带有运营商特色的特殊业务存在更多的操作空间。

步骤S4：将处理得到的结果同步返回/通过异步消息通知的方式发送至上层聚合交易系统。

上述步骤中，通过同步返回/通过异步消息通知的方式将处理得到的结果发送至上层聚合交易系统，以进行后续处理。例如支付失败、支付成功通知等。

基于第一方面，在本发明的一些实施例中，还包括：响应于交易请求，进行落单、限额校验和风控校验，校验均通过后，则新增支付订单。

请参照图4-a和图4-b，两者展示了聚合交易与支付的下单支付流程的完整示意图。接收到订单支付请求后，首先进行参数校验和转换，在各类表中同步新增记录。例如订单表、内部营销表、分账表等。然后调用限额中心查询商户贷记卡额度，进行限额校验，并调用风控交易进行风控校验。校验均通过后，则新增支付订单，对订单表和支付表进行更新，并调用聚合双活支付接口进行支付。之后，根据聚合支付结果(失败、成功、超时处理)进行相应更新和消息返回。须注意的是，此流程中：1.聚合交易无前向收费历史交易，不支持前向收费；2.所有流水号自增序号均接入poseidon；3.下单与支付合并，不再发送下单成功kafka。

基于同样的发明构思，本发明还提出一种基于柔性分布式事务的聚合双活支付系统，请参照图5，图5为本申请实施例提供的一种基于柔性分布式事务的聚合双活支付系统的结构框图。该系统包括：

环境标识设置模块11，用于基于流量路由标准，在开放平台构建双活环境，并为不同的环境赋予对应的环境标识；

聚合双活链路模块12，用于获取新增支付订单，根据订单对应的环境标识，将订单切入对应的环境链路下传输至支付平台；若环境出现异常，则将订单切入另一个环境链路下并传输至支付平台；

聚合支付模块13，支付平台根据新增支付订单的聚合支付请求进行扣款，并从信息流和资金流两方面进行柔性分布式事务处理，保证订单信息的一致性；

结果返回模块14，用于将处理得到的结果同步返回/通过异步消息通知的方式发送至上层聚合交易系统。

请参照图6，图6为本申请实施例提供的一种电子设备的结构框图。该电子设备包括存储器1、处理器2和通信接口3，该存储器1、处理器2和通信接口3相互之间直接或间接地电性连接，以实现数据的传输或交互。例如，这些元件相互之间可通过一条或多条通讯总线或信号线实现电性连接。存储器1可用于存储软件程序及模块，如本申请实施例所提供的一种基于柔性分布式事务的聚合双活支付系统对应的程序指令/模块，处理器2通过执行存储在存储器1内的软件程序及模块，从而执行各种功能应用以及数据处理。该通信接口3可用于与其他节点设备进行信令或数据的通信。

以上所述仅为本申请的优选实施例而已，并不用于限制本申请，对于本领域的技术人员来说，本申请可以有各种更改和变化。凡在本申请的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本申请的保护范围之内。

对于本领域技术人员而言，显然本申请不限于上述示范性实施例的细节，而且在不背离本申请的精神或基本特征的情况下，能够以其它的具体形式实现本申请。因此，无论从哪一点来看，均应将实施例看作是示范性的，而且是非限制性的，本申请的范围由所附权利要求而不是上述说明限定，因此旨在将落在权利要求的等同要件的含义和范围内的所有变化囊括在本申请内。不应将权利要求中的任何附图标记视为限制所涉及的权利要求。