CN104050564B - 高并发通用支付方法 - Google Patents

Abstract

本发明提供一种高并发通用支付方法，包括：步骤1：当系统入口服务接收到同步请求时，生成用于保存所述同步请求的结构体TransInfo对象，并向所述TransInfo对象分配序列号，然后将所述序列号保存于TransInfo对象中；步骤2：将所述TransInfo对象放入TransInfo处理队列；步骤3：将所述TransInfo对象的序列号作为参数调用tpforward系统入口服务，从而进入服务的请求队列，等待处理，并将所述TransInfo对象的序列号保存在所述tpforward的参数中。本发明方法能够通过同时处理多个交易请求实现高并发；并通过对与外部交易系统的交互采用统一的链路管理的方式实现了高扩展性。

Description

高并发通用支付方法

技术领域

本发明涉及电子支付技术领域，尤其涉及一种高并发通用支付方法。

背景技术

随着电子客票的推广和普及，航空公司为适应市场需求的变化，也迫切希望其购票款可直接通过信用卡完成支付。主机CCV指令是一个信用卡验证指令，现在系统中绝大多数的验证操作都是通过SITA的CCA系统（信用卡授权系统）进行的，如图1所示。

CCV指令直接调用CCA，将逐步过渡到调用航信自己的开放端系统实现与各信用卡授权系统、银行及其他第三方支付平台的直连，这样可以大大节省CCA系统使用费用，并收取服务费。

在卡支付验证后台系统领域，一般采用的都是基于TUXEDO交易中间件的支付验证架构，为了满足外部系统同步调用的需求，常用的架构设计中往往存在低并发、可扩展性差、通用性差的缺点。

缺点一：低并发：外部系统调用支付验证服务时采用的是Tuxedo同步请求，每一个同步请求就会占用一个Tuxedo验证服务，通常验证服务又会调用其它的验证系统进行验证，所以一次验证通常耗费的时间可能会比较长。如果系统完全依赖于增加TUXEDO验证服务的个数来提高并发处理能力，则系统的并发处理能力将严重依赖于Tuxedo验证服务的个数。如果验证服务个数小于并发请求个数时，将导致请求堆积在处理队列中，形成一个性能的拐点，单个请求的处理时间将会在这个拐点陡然增加。

缺点二：可扩展性差：支付系统根据卡的类型不同，会调用不同的外部系统进行验证，调用外部系统的方法根据实际情况也会不同，可能是Socket也可能是MQ。因此扩展性差会表现为以下两点，一是在不影响现有服务的情况下，不能方便地接入其他服务来增强现有系统的功能；二是不能方便的扩展不同的链路，不能提供一个统一的链路管理来提供不同的链接方式，他们的链接往往是针对一个外部交易平台重新编写程序来提供一个服务来进行处理，可扩展性较差。

缺点三：通用性差：一般的支付系统都是自成体系，往往都只是针对一家银行或者信用卡授权中心进行独立处理，系统的通用性较差，增加新的卡类型往往需要重新编写所有代码，这会大大增加人力成本。

发明内容

有鉴于此，本发明提供了一种高并发通用支付方法，能够通过同时处理多个交易请求实现高并发；并通过对与外部交易系统的交互采用统一的链路管理的方式实现了高扩展性。

本发明提供的一种高并发通用支付方法，包括：

步骤1：当系统入口服务接收到同步请求时，生成用于保存所述同步请求的结构体TransInfo对象，并向所述TransInfo对象分配序列号，然后将所述序列号保存于TransInfo对象中；

步骤2：将所述TransInfo对象放入TransInfo处理队列；

步骤3：将所述TransInfo对象tpforward服务，从而进入服务的请求队列，等待处理，并将所述TransInfo对象的序列号保存在所述tpforward的参数中。

所述方法还包括：构建发送线程以遍历所述TransInfo处理队列，并根据所述TransInfo处理队列中的TransInfo对象的状态进行处理，包括：删除TransInfo处理队列中状态为无效的TransInfo对象；发送TransInfo处理队列中状态为发送前的TransInfo对象。

当TransInfo处理队列为空时，所述发送线程会进行阻塞以等待新的TransInfo对象被放入所述TransInfo处理队列中。

所述方法还包括：构建接收线程以遍历所述TransInfo处理队列，并将服务返回的数据放入所述TransInfo处理队列中对应的TransInfo对象中，并相应修改所述TransInfo对象的状态为已接收。

所述方法还包括：系统入口服务调用自身的tpforward请求到达时，提取所述tpforward请求中保存的TransInfo对象的序列号，从TransInfo队列中找到对已的TransInfo对象，如果所述对已的TransInfo对象的状态为已接收，则将接收到的结果tpreturn（返回请求）给外部系统，并将所述对已的TransInfo对象的状态更新为无效，结束一次外部请求过程；其中，所述tpforward请求即tpforward服务的TransInfo对象所保存的同步请求。

所述方法还包括：将外部链路抽象为类Link，提供统一的调用接口，BSP验证或者UATP的验证的具体实现都从Link类派生，发送线程和接收线程中的发送和接收处理，都只依赖与Link接口，从而不用关心链路的具体实现。

所述方法还包括：将每种支付方式的业务处理代码进行封装，包括接收数据的解析，发送报文的组装，数据库的查询更新操作；不同的支付方式有不同的处理要求，通过将不同的处理过程封装为独立的类，以统一的接口插入支付引擎，实现支付业务处理的可扩展性。

综上所述，本发明主要应用于卡支付验证后台系统领域，具备高并发、插件服务、扩展性强等特点：

本发明方法具有高并发处理的优点。在本发明中，一个服务进程可同时处理多个交易请求，在同一时刻有大量用户访问的情况下，基本不用担心由于处理进程数不够而造成的问题，能够保证1个进程在每秒40个请求的状态。

本发明方法具有可扩展性强的优点。本发明中采用插件开发模式，每一个新增的服务都可以在不改变原有服务的基础上，以插件的模式与现有服务共存。另外，本发明在与外部交易系统进行交互的方式上，提供了统一的链路管理，目前支持SOCKET和MQ两种链接方式，这两种方式几乎可以涵盖所有的链接方式。

在本发明中，具有通用性强的优点。本发明能整合航信现有主机支付产品线开放端所有卡支付系统，目前已经整合了UATP直连支付及BSP订座支付引擎两个系统。代码具备很强的通用性，如未来需要接入新的银行或者信用卡组织，只需在该引擎的基础上编写自己的业务模块代码即可，大大提高了代码复用率，缩减了人力成本。

附图说明

为了更清楚地说明本发明实施例或现有技术中的方案，下面将对实施例中所需要使用的附图作一简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员而言，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1为现有系统中执行验证操作的SITA的CCA系统的业务结构图；

图2为本发明一实施例提供的高并发通用支付方法的流程示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整的描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动的前提下所获得的所有其他实施例，都属于本发明保护的范围。

图2为本发明一实施例提供的高并发通用支付方法的流程示意图，如图2所示，本实施例的高并发通用支付方法，包括：

步骤1：当系统入口服务接收到同步请求时，生成用于保存所述同步请求的结构体TransInfo对象，并向所述TransInfo对象分配序列号，然后将所述序列号保存于TransInfo对象中；

步骤2：将所述TransInfo对象放入TransInfo处理队列；

步骤3：将所述TransInfo对象tpforward系统入口服务，从而进入服务的请求队列，等待处理，并将所述TransInfo对象的序列号保存在所述tpforward的参数中。

可选地，所述方法还包括：构建发送线程以遍历所述TransInfo处理队列，并根据所述TransInfo处理队列中的TransInfo对象的状态进行处理，包括：删除TransInfo处理队列中状态为无效的TransInfo对象；发送TransInfo处理队列中状态为发送前的TransInfo对象。发送给外部系统的服务，根据业务不同会不一样，比如UAPT就是UATP验证服务，BSP就是BSP验证服务。当TransInfo处理队列为空时，所述发送线程会进行阻塞以等待新的TransInfo对象被放入所述TransInfo处理队列中。

可选地，所述方法还包括：构建接收线程以遍历所述TransInfo处理队列，并将外部系统服务返回的数据放入所述TransInfo处理队列中对应的TransInfo对象中，并相应修改所述TransInfo对象的状态为已接收。外部系统服务，根据业务不同会不一样。

发送线程和接收线程都是跟外部系统服务交互，交互方式根据外部系统服务的类型，使用不同的链路方式。比如外部可能是消息队列进行交互，也可能是用Socket通过TCP/IP协议进行交互。

可选地，所述方法还包括：系统入口服务调用自身的tpforward请求到达时，提取所述tpforward请求中保存的TransInfo对象的序列号，根据序列号遍历TansInfo队列，从TransInfo队列中找到对已的TransInfo对象，如果所述对已的TransInfo对象的状态为已接收，则将接收到的结果tpreturn（返回请求）给外部系统，并将所述对已的TransInfo对象的状态更新为无效，结束一次外部请求过程；其中，所述tpforward请求即tpforward服务的TransInfo对象所保存的同步请求。

可选地，所述方法还包括：将外部链路抽象为类Link，提供统一的调用接口，BSP验证或者UATP的验证的具体实现都从Link类派生，发送线程和接收线程中的发送和接收处理，都只依赖与Link接口，从而不用关心链路的具体实现。

可选地，所述方法还包括：将每种支付方式的业务处理代码进行封装，包括接收数据的解析，发送报文的组装，数据库的查询更新操作；不同的支付方式有不同的处理要求，通过将不同的处理过程封装为独立的类，以统一的接口插入支付引擎，实现支付业务处理的可扩展性。

最后应说明的是：以上实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换，而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的精神和范围。

Claims (5)

1.一种高并发通用支付方法，其特征在于，所述方法包括：

步骤1：当系统入口服务接收到同步请求时，生成用于保存所述同步请求的结构体TransInfo对象，并向所述TransInfo对象分配序列号，然后将所述序列号保存于TransInfo对象中；

步骤2：将所述TransInfo对象放入TransInfo处理队列；

步骤3：将所述TransInfo对象的序列号作为参数调用tpforward系统入口服务，从而进入系统入口服务的请求队列，等待处理，并将所述TransInfo对象的序列号保存在所述tpforward的参数中；

步骤4：构建发送线程以遍历所述TransInfo处理队列，并根据所述TransInfo处理队列中的TransInfo对象的状态进行处理；

步骤5：构建接收线程以遍历所述TransInfo处理队列，并将外部系统服务返回的数据放入所述TransInfo处理队列中对应的TransInfo对象中，并相应修改所述TransInfo对象的状态为已接收；

步骤6：系统入口服务调用自身的tpforward请求到达时，提取所述tpforward请求中保存的TransInfo对象的序列号，从TransInfo队列中找到对应的TransInfo对象，如果所述对应的TransInfo对象的状态为已接收，则将接收到的结果返回请求tpreturn给外部系统，并将所述对应的TransInfo对象的状态更新为无效，结束一次外部请求过程。

2.根据权利要求1所述的高并发通用支付方法，其特征在于，所述步骤4包括：删除TransInfo处理队列中状态为无效的TransInfo对象；发送TransInfo处理队列中状态为发送前的TransInfo对象。

3.根据权利要求2所述的高并发通用支付方法，其特征在于，当TransInfo处理队列为空时，所述发送线程会进行阻塞以等待新的TransInfo对象被放入所述TransInfo处理队列中。

4.根据权利要求1所述的高并发通用支付方法，其特征在于，所述方法还包括：将外部链路抽象为类Link，提供统一的调用接口，BSP验证或者UATP的验证的具体实现都从Link类派生，发送线程和接收线程中的发送和接收处理，都只依赖与Link接口，从而不用关心链路的具体实现。

5.根据权利要求4所述的高并发通用支付方法，其特征在于，所述方法还包括：将每种支付方式的业务处理代码进行封装，包括接收数据的解析，发送报文的组装，数据库的查询更新操作；不同的支付方式有不同的处理要求，通过将不同的处理过程封装为独立的类，以统一的接口插入支付引擎，实现支付业务处理的可扩展性。