CN109345218B - 支付信息分流方法、系统、装置及存储介质 - Google Patents

Abstract

本发明公开了一种基于商户维度的支付信息分流方法、系统、装置及存储介质，所述方法包括：商户客户端将交易请求提交至服务器；所述服务器识别所述交易请求中的商户号，并根据所述商户号和分流策略确定所述商户号对应的支付通道的通道号，以将所述通道号返回至所述商户客户端；所述商户客户端根据所述通道号将所述交易请求提交至所述通道号对应的支付通道进行交易处理。本发明的方法基于商户维度对支付信息进行分流处理，保证了支付平台的高性能和高可用性，且对交易量不同的商户采取不同的交易分流策略，在保证交易量大的重点商户能有充足的系统资源应对交易高峰的同时，也保证了普通商户的稳定运行，使其不会受可能出现的系统波动的影响。

Description

支付信息分流方法、系统、装置及存储介质

技术领域

本发明涉及信息处理领域，更为具体而言，涉及一种基于商户维度的支付信息分流方法、系统、装置及存储介质。

背景技术

随着互联网及移动互联网的高速发展，大众的生活、工作、娱乐、购物等方式已经被全面颠覆和改变，越来来越多的人选择通过网络进行各类交易。目前，系统的交易请求的分流一般基于客户维度，按客户进行交易分流，例如：将不同范围IP的客户交易请求分流至不同的系统通道进行处理或按客户ID将客户交易请求进行分流，通道中的应用服务器响应客户请求，客户的交易流水也记录在该通道的数据库。有的系统也会将交易流水同步记录在其他通道数据库，或者所有通道公用一个数据库。但是，按客户分流，则不同客户从同一家商户网站发起的支付请求会被分流到不同的通道，同一家商户的支付流水会分散记录到不同的系统通道中。由于流水的分散记录，导致网上支付的很多相关功能无法实现，例如：订单判重、批量订单查询、订单退款功能等。

订单判重是基于商户维度进行，需在该商户所有的支付流水中，按订单号进行查询，如果有支付成功的记录，则判断订单重复。如果同一家商户的支付流水分散到不同的系统通道中，则无法实现。同样的，批量订单查询由商户系统主动发起，商户系统需从支付平台获取本商户订单的相关信息，以便商户系统进行相关的业务逻辑处理。该功能也要求同一家商户的流水必须在同个通道数据库。订单退款由商户系统主动发起，同样基于商户维度进行。以上功能在保障商户和客户的权益方面都起着重要的作用。

目前支付平台通常通过查询所有通道的数据库来调取所有的支付流水，以解决上面提到的问题。但数据库操作一般是一个交易请求中的资源耗费最大的部分，往往成为一个系统的瓶颈。可想而知，上述方法查询效率会极其低下，达不到分流提高系统性能的目的。同样的，如果将支付流水同时记录在所有通道数据库，虽然可以解决上面的问题，同样会大大降低系统性能。如果所有通道公用一个数据库，则数据库会成为支付平台的单点故障节点，无法实现系统的多活和高可用性，失去了分流的目的。

发明内容

为了解决现有技术中存在的上述问题，本发明提供了一种基于商户维度的支付信息分流方法、系统、装置及存储介质，通过按商户维度对支付信息进行分流处理，保证了支付平台的高性能和高可用性。

根据本发明的实施方式，提供了一种基于商户维度的支付信息分流方法，所述方法包括：商户客户端将交易请求提交至服务器；所述服务器识别所述交易请求中的商户号，并根据所述商户号和分流策略确定所述商户号对应的支付通道的通道号，以将所述通道号返回至所述商户客户端；所述商户客户端根据所述通道号将所述交易请求提交至所述通道号对应的支付通道进行交易处理。

在本发明的一些实施方式中，所述分流策略包括：若所述商户号对应的商户的平均交易量大于预设的阈值，单独为所述商户分配支付通道；否则，通过对所述商户号取模确定所述商户号对应的支付通道的通道号。

在本发明的一些实施方式中，所述分流策略通过参数的动态加载实现动态调整。

在本发明的一些实施方式中，所述支付通道具有独立的数据库以存储该支付通道中的支付流水。

在本发明的一些实施方式中，所述商户客户端根据所述通道号将所述交易请求提交至所述通道号对应的支付通道进行交易处理包括：所述商户客户端根据所述通道号生成servlet(Java Servlet，小服务程序或服务连接器)，并通过所述servlet将所述交易请求提交至所述支付通道。

在本发明的一些实施方式中，所述商户客户端将所述通道号保存在cookie中。

同时，本发明提供了一种基于商户维度的支付信息分流系统，所述系统至少包括多个支付通道、商户客户端和服务器；其中，支付通道用于根据交易请求进行交易处理；其中，商户客户端包括：第一通讯模块，用于将所述交易请求提交至所述服务器，并接受所述服务器返回的通道号；转接模块，用于根据所述通道号将所述交易请求提交至所述通道号对应的支付通道进行交易处理；其中，服务器包括：识别模块，用于识别所述交易请求中的商户号，并根据所述商户号和分流策略确定所述商户号对应的支付通道的通道号；第二通讯模块，用于将所述通道号返回至所述商户客户端。

在本发明的一些实施方式中，所述识别模块包括：分流单元，用于在所述商户号对应的商户的平均交易量大于预设的阈值的情况下，单独为所述商户分配支付通道；否则，通过对所述商户号取模确定所述商户号对应的支付通道的通道号。

在本发明的一些实施方式中，所述分流策略通过参数的动态加载实现动态调整。

在本发明的一些实施方式中，所述支付通道具有独立的数据库以存储该支付通道中的支付流水。

在本发明的一些实施方式中，所述转接模块包括：servlet生成单元，用于根据所述通道号生成servlet，并通过所述servlet将所述交易请求提交至所述支付通道。

在本发明的一些实施方式中，所述商户客户端还包括：存储模块，用于将所述通道号保存在cookie中

此外，本发明提供了一种基于商户维度的支付信息分流装置，包括存储器和处理器，所述存储器用于存储一条或多条计算机指令；所述处理器用于调用并执行所述一条或多条计算机指令从而实现前述任一项的基于商户维度的支付信息分流方法。

本发明还提供了一种计算机存储介质，存储有一条或多条计算机程序，所述一条或多条计算机程序在执行时实现前述任一项的基于商户维度的支付信息分流方法。

本发明的实施例通过按商户维度对支付信息进行分流处理，保证了支付平台的高性能和高可用性，且对交易量不同的商户采取不同的交易分流策略，在保证交易量大的重点商户能有充足的系统资源应对交易高峰的同时，也保证了普通商户的稳定运行，使其不会受可能出现的系统波动的影响。

附图说明

为了便于理解本发明，以下通过具体实施方式并结合附图对本发明进行具体说明。

图1是根据本发明实施方式的一种基于商户维度的支付信息分流方法的流程示意图；

图2是根据本发明实施方式的一种基于商户维度的支付信息分流系统的框图；

图3是图2中基于商户维度的支付信息分流系统的识别模块的框图；

图4是图2中基于商户维度的支付信息分流系统的转接模块的框图；

图5是根据本发明实施方式的商户客户端的框图。

具体实施方式

以下结合附图和具体实施方式对本发明的各个方面进行详细阐述。其中，众所周知的模块、单元及其相互之间的连接、链接、通信或操作没有示出或未作详细说明。并且，所描述的特征、架构或功能可在一个或一个以上实施方式中以任何方式组合。本领域技术人员应当理解，下述的各种实施方式只用于举例说明，而非用于限制本发明的保护范围。还可以容易理解，本文所述和附图所示的各实施方式中的模块或单元或处理方式可以按各种不同配置进行组合和设计。

首先，对本发明涉及的专业名词进行解释：

网上支付：网上支付指的是客户、商户、支付平台(包括银行和第三方支付机构)之间使用安全电子手段，利用电子现金、银行卡、电子支票等支付工具通过互联网传送到银行或相应的处理机构，从而完成支付的整个过程；

通道：在本申请中，指的是支付平台中包含独立的应用服务器和数据库的一个系统群组；

分流：将交易请求按照一定规则分发到多个操作单元上进行执行，主要包括应用服务器和数据库服务器，从而共同完成工作任务。

流水：客户交易请求的相关数据库记录，比如客户对一笔订单进行了支付，则会在数据库中记录一笔订单信息，也称为支付流水。

订单判重：一笔订单只能支付成功一次，如果客户重新从商户系统发起了该订单的支付请求，支付平台需进行判断，防止客户重复付款。订单判重是所有支付平台必须实现的功能。

商户号：一家支付平台会有多家商户接入，支付平台会给每家商户分配一个唯一的商户号(一般是包含数字或字母的字符串)作为该商户的标识。

servlet：是Java Servlet的简称，称为小服务程序或服务连接器，用Java编写的服务器端程序，主要功能在于交互式地浏览和修改数据，生成动态Web内容。在本申请中，servlet担当客户交易请求(Web浏览器或其他HTTP客户程序)与服务器响应(应用服务器和数据库)的中间层。即servlet将客户的支付请求提交至支付平台对应的应用服务器和数据库进行交易处理。

图1是根据本发明实施方式的一种基于商户维度的支付信息分流方法的流程示意图，在本发明的实施方式中，参照图1，该方法包括：

100：商户客户端将交易请求提交至服务器；

102：所述服务器识别所述交易请求中的商户号，并根据所述商户号和分流策略确定所述商户号对应的支付通道的通道号，以将所述通道号返回至所述商户客户端；

104：所述商户客户端根据所述通道号将所述交易请求提交至所述通道号对应的支付通道进行交易处理。

在本发明的实施方式中，支付通道具有独立的数据库以存储该支付通道中的支付流水，同时，各支付通道还可以将支付流水记录在公用的备份数据库中，备份数据库的记录为异步操作，不会影响支付通道的交易处理。

可选的，在本发明的实施方式中，商户客户端通过统一的URL入口接入服务器，URL一般格式为：

https://支付平台域名/servlet名称？商户号＝xxxxxx&订单号＝xxxxxx&支付金额＝xxx......，举例如下：

https://ibsbjstar.ccb.com.cn/app/ccbMain？MERCHANTID＝105320148140002&POSID＝100001135&BRANCHID＝320000000&ORDERID＝59615&PAYMENT＝0.01&CURCODE＝01&TXCODE＝520100&REMARK1＝&REMARK2＝&TYPE＝1&GATEWAY＝&CLIENTIP＝128.128.80.125&REGINFO＝xiaofeixia&PROINFO＝digital&REFERER＝&MAC＝62f8acb7230b1e80ce7133f2bf689f70，其中MERCHANTID＝105320148140002代表唯一标识商户的商户号。

由于网上支付的请求负载数量在不同客户间差异不大，但在不同商户间差异巨大。比如对于银行的支付平台来说，支付宝商户的支付请求数量可能超过了所有其他商户的支付请求数量，或者在某些特殊的时间段，某些商户的交易负载会出现爆炸性增长，比如在双十一、抢票、秒杀抢购活动期间，这就需求一种合理的分流策略以均衡重点商户和普通商户负载，使系统处于稳定状态。

在本发明的实施方式中，通过分配一个或几个支付通道供重点商户专用，这样既保证了这些重点商户能分配到更充足的资源，也保证了重点商户如果出现了系统波动，也不会影响其他普通商户的支付交易。

可选的，在本发明的实施方式中，分流策略包括：若所述商户号对应的商户的平均交易量大于预设的阈值，单独为所述商户分配支付通道；否则，通过对所述商户号取模确定所述商户号对应的支付通道的通道号。

具体的，在服务器中会保存一张分流策略对应表，里面记录了分流策略以及对应的商户。例如，支付平台共有有9个通道，假设对接了3个体量巨大的商户，则可给这3个体量巨大的商户分别分配1个通道，剩下的商户通过取模运算分散到剩余的6个中通道，表1为上例的策略对应表：

表1：

独占通道的商户，特点是商户数量少，交易量巨大，比如支付宝、财付通、铁道部等等，因此配置对应的商户号到独占的通道号列。例如上表所示，可以把支付宝对应的商户号配置到通道7，财付通商户号配置到通道8，铁道部商户号配置到通道9，也可以多个商户公用一个固定通道，根据每个商户的交易量灵活配置。

其他商户通过商户号取模运算的方式均分到其他各个通道。商户号一般为字母或数字的字符串，可以通过对商户号的哈希值取模即可。因为哈希值的随机性，从而保证商户号的哈希值取模后能随机分散到各个通道中，使每个支付通道的交易负载达到均衡。例如，上述例子中，支付平台剩余6个通道，则通过对商户号的hashcode(哈希码)值模6后，将各个商户的交易分散到6个通道。

取模的语义代码如下：

int hashCode＝merchant_code.hashCode()；

if(hashCode<0)hashCode＝0-hashCode；

int channel_no＝hashCode％6+1；

其中，merchant_code为每个商户的唯一标识商户号。

可选的，在本发明的实施方式中，为了应对在某些特殊的时间段，某些商户的交易负载会出现爆炸性增长的情况，分流策略可以通过参数的动态加载实现动态调整。

具体的，当分流策略需要调整时，修改分流策略对应表，例如某个商户要举行大规模秒杀促销活动，则可以临时将该商户调整至资源更为充沛的通道，活动结束后再将该商户恢复原通道。这种情况往往涉及物理通道的调整，因此需提前将该商户对应的流水从备份数据库拷贝到调整后的通道数据库。

分流策略表一般数据量较小，在应用启动时，可将表中数据加载至内存中，以减少对数据库的操作。系统上配置一个超时时间，比如五分钟，超过五分钟则从数据库的分流策略表重新加载最新数据到内存中，这样在不中断应用的条件下，可以动态调整分流策略。

可选的，在本发明的实施方式中，支付通道包含逻辑通道和物理通道两层含义，上述策略对应表中指的是逻辑通道。具体来说一个逻辑通道对应一个servlet，物理通道指的是应用服务器和数据库组成的实际通道。之所以区分出逻辑和物理两层概念，主要是当需要增加或减少通道时，商户根据分流策略得到的逻辑通道号可能会发生变化。例如采用取模策略的商户，取模数会发生变化，商户号的哈希值取模后得到的逻辑通道会跟着发生变化，为屏蔽该差异，可以在web服务器层面配置逻辑通道和物理通道的对应关系，这样当通道数发生变化时，只需调整逻辑通道和物理通道的配置关系即可，虽然逻辑通道发生了改变，但商户对应的物理通道没有改变，因此不需要进行流水记录的迁移。在本实施方式中，支付通道发生增加或减少，反应为分流策略的调整。

可选的，在本发明的实施方式中，处理104可以通过以下方式实现：

商户客户端根据所述通道号生成servlet，并通过所述servlet将所述交易请求提交至所述支付通道。

具体的，商户客户端将通道号保存在cookie中，当需要提交交易请求时，读取cookie中的通道号，生成对应的servlet，一个servlet对应一个支付通道，例如，通道1对应https://ibsbjstar.ccb.com.cn/app/ccbMain_1，通道2对应https://ibsbjstar.ccb.com.cn/app/ccbMain_2等等，将交易请求提交至对应的serlvet，转入该支付通道的应用服务器进行交易处理。

在本发明的实施方式中，之所以要将通道号记录下来，是因为要完成一个支付流程往往需要好几个步骤(例如，第一步输入账号，第二步输入密码等等)，从而需要向支付平台提交几次交易请求，记录下通道号，不但简化了处理，且保证后续步骤的交易请求都发往同一个支付通道。

本发明的方法基于商户维度对支付信息进行分流处理，保证了支付平台的高性能和高可用性，且对交易量不同的商户采取不同的交易分流策略，在保证交易量大的重点商户能有充足的系统资源应对交易高峰的同时，也保证了普通商户的稳定运行，使其不会受可能出现的系统波动的影响。

图2是根据本发明实施方式的一种基于商户维度的支付信息分流系统的框图，参照图2，基于商户维度的支付信息分流系统1至少包括多个支付通道11、商户客户端12和服务器13。

其中，支付通道11用于根据交易请求进行交易处理；商户客户端12包括：第一通讯模块121，用于将交易请求提交至服务器13，并接收服务器13返回的通道号，转接模块122，用于根据通道号将交易请求提交至通道号对应的支付通道11进行交易处理；服务器13包括：识别模块131，用于识别交易请求中的商户号，并根据商户号和分流策略确定商户号对应的支付通道11的通道号，第二通讯模块132，用于将通道号返回至商户客户端12。

可选的，在本发明的实施方式的一种实现方式中，分流策略可以通过参数的动态加载实现动态调整。

可选的，在本发明的实施方式的一种实现方式中，支付通道具有独立的数据库以存储该支付通道中的支付流水，同时，基于商户维度的支付信息分流系统1还包括备份数据库以备份各支付通道11的支付流水，备份数据库的记录为异步操作，不会影响支付通道的交易处理。

可选的，参照图3，在本发明的实施方式的一种实现方式中，识别模块131包括：分流单元133，用于在商户号对应的商户的平均交易量大于预设的阈值的情况下，单独为所述商户分配支付通道11；否则，通过对商户号取模确定所述商户号对应的支付通道11的通道号。

可选的，参照图4，在本发明的实施方式的一种实现方式中，转接模块122包括：servlet生成单元123，用于根据通道号生成servlet，并通过servlet将所述交易请求提交至支付通道11。

可选的，参照图5，在本发明的实施方式的一种实现方式中，商户客户端12还可以包括：存储模块124，用于将通道号保存在cookie中。

可选的，本发明实施方式提供了一种基于商户维度的支付信息分流装置，该基于商户维度的支付信息分流装置包括存储器，用于存储一条或多条计算机指令；处理器，用于调用并执行所述一条或多条计算机指令从而实现本发明前述实施方式或实现方式所提供的基于商户维度的支付信息分流方法。可选地，在本发明实施方式的一种实现方式中，所述基于商户维度的支付信息分流装置还可以包括用于进行数据通信的输入输出接口。例如，所述处理装置可以是计算机、智能终端、服务器等。

本发明实施方式还提供了一种计算机存储介质，存储有一条或多条计算机指令，用于在执行时实现本发明前述实施方式或实现方式提供的基于商户维度的支付信息分流方法。例如，所述存储介质可以包括硬盘、软盘、光盘等。

虽然本文举例描述了一些实施方式，但是，在不脱离本发明实质的前提下，可以对这些实施方式进行各种变形，所有这些变形仍属于本发明的构思，并且落入本发明权利要求所限定的保护范围。

本文所公开的具体实施方式仅用于举例说明本发明，对于本领域技术人员而言，显然可以根据本文的教导进行各种修改，可以采用各种等同的方式实施本发明，因此，本发明上述公开的特定的实施方式仅仅是示例性的，其保护范围不受在此公开的结构或设计的细节所限，除非在权利要求中另有说明。因此，上述公开的特定的示例性的实施方式可进行各种替换、组合或修改，其所有的变形都落入本文公开的范围内。在缺少本文没有具体公开的任何元件或缺少本文公开的任选的部件的情况下，本文示例性公开的基于商户维度的支付信息分流方法、系统、装置及存储介质仍可适当地实施。上述公开的所有的数值和范围也可进行一定变化。每当公开了具有下限和上限的数值范围，落入此范围内的任何数值及任何被包含的范围都被具体地公开了。具体而言，本文公开的数值的任一范围均可理解为列举了包含在较宽数值范围内的任一数值和范围。同样，除非申请人明确且清楚地另有定义，权利要求中的术语具有它们的清楚、通常的含义。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到本发明可借助软件结合硬件平台的方式来实现。基于这样的理解，本发明的技术方案对背景技术做出贡献的全部或者部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本发明各个实施方式或者实施方式的某些部分所述的方法。

此外，权利要求书中的部件的数量包括一个或至少一个，除非另有说明。如果本发明中的用词或术语与其它文献中的用法或含义存在不一致，则应当以与本发明所定义的为准。

Claims (8)

1.一种基于商户维度的支付信息分流方法，其特征在于，所述方法包括：

商户客户端将交易请求提交至服务器；

所述服务器识别所述交易请求中的商户号，并根据所述商户号和分流策略确定所述商户号对应的逻辑通道号，以将所述逻辑通道号返回至所述商户客户端；其中，所述分流策略包括：若所述商户号对应的商户的平均交易量大于预设的阈值，单独为所述商户分配逻辑通道；否则，通过对所述商户号取模确定所述商户号对应的逻辑通道的逻辑通道号；其中，采用取模策略的商户，取模数会发生变化，对所述商户号取模确定的所述商户号对应的逻辑通道的逻辑通道号也会发生变化；

所述商户客户端根据所述逻辑通道号将所述交易请求提交至所述逻辑通道号对应的逻辑通道，由所述逻辑通道将所述交易请求转到所述逻辑通道对应的物理通道进行交易处理；

其中，所述物理通道是应用服务器和数据库组成的实际通道，所述物理通道具有独立的数据库以存储该物理通道中的支付流水；

当所述商户号对应的逻辑通道发生改变时，通过调整所述逻辑通道与物理通道的对应关系，使所述商户号对应的物理通道不发生改变，以将同一商户的支付请求发送给同一物理通道进行处理。

2.如权利要求1所述的方法，其特征在于，

所述分流策略通过参数的动态加载实现动态调整。

3.如权利要求1所述的方法，其特征在于，所述商户客户端根据所述逻辑通道号将所述交易请求提交至所述逻辑通道号对应的逻辑通道包括：

所述商户客户端根据所述逻辑通道号生成servlet，将所述交易请求提交至所述逻辑通道号对应的servlet。

4.一种基于商户维度的支付信息分流系统，其特征在于，所述系统至少包括多个支付通道、商户客户端和服务器；

其中，支付通道用于根据交易请求进行交易处理；

其中，商户客户端包括：

第一通讯模块，用于将所述交易请求提交至所述服务器，并接受所述服务器返回的逻辑通道号；

转接模块，用于根据所述逻辑通道号将所述交易请求提交至所述逻辑通道号对应的逻辑通道，由所述逻辑通道将所述交易请求转到所述逻辑通道对应的物理通道进行交易处理；

其中，服务器包括：

识别模块，用于识别所述交易请求中的商户号，并根据所述商户号和分流策略确定所述商户号对应的逻辑通道的逻辑通道号；其中，识别模块包括：分流单元，用于在所述商户号对应的商户的平均交易量大于预设的阈值的情况下，单独为所述商户分配逻辑通道；否则，通过对所述商户号取模确定所述商户号对应的逻辑通道的逻辑通道号；其中，采用取模策略的商户，取模数会发生变化，对所述商户号取模确定的所述商户号对应的逻辑通道的逻辑通道号也会发生变化；

第二通讯模块，用于将所述逻辑通道号返回至所述商户客户端；

其中，所述物理通道是应用服务器和数据库组成的实际通道，所述物理通道具有独立的数据库以存储该物理通道中的支付流水；

当所述商户号对应的逻辑通道发生改变时，通过调整所述逻辑通道与物理通道的对应关系，使所述商户号对应的物理通道不发生改变，以将同一商户的支付请求发送给同一物理通道进行处理。

5.如权利要求4所述的系统，其特征在于，

所述分流策略通过参数的动态加载实现动态调整。

6.如权利要求4所述的系统，其特征在于，所述转接模块包括：

servlet生成单元，用于根据所述逻辑通道号生成servlet，将所述交易请求提交至所述逻辑通道号对应的servlet。

7.一种基于商户维度的支付信息分流装置，包括存储器和处理器，其特征在于，

所述存储器用于存储一条或多条计算机指令；

所述处理器用于调用并执行所述一条或多条计算机指令从而实现如权利要求1-3中任一项所述的方法。

8.一种计算机存储介质，存储有一条或多条计算机程序，其特征在于，所述一条或多条计算机程序在执行时实现如权利要求1-3中任一项所述的方法。

Images