CN114119241A

CN114119241A - Channel transaction system

Info

Publication number: CN114119241A
Application number: CN202210096879.9A
Authority: CN
Inventors: 于丰冉; 陈文成; 王晓韡; 廖有军
Original assignee: All In Pay Network Services Co ltd
Current assignee: All In Pay Network Services Co ltd
Priority date: 2022-01-27
Filing date: 2022-01-27
Publication date: 2022-03-01

Abstract

Embodiments of the present disclosure relate to a channel trading system, comprising a management subsystem and a plurality of trading cluster subsystems, the management subsystem being configured to configure and manage each of the plurality of trading cluster subsystems; each transaction cluster subsystem includes: a plurality of transaction service nodes configured to provide transaction services for a plurality of product dimensions; a plurality of service registration nodes configured to register transaction services registered by the transaction service node with the service registration node based on a transaction service list; a plurality of transaction invoking client nodes configured to obtain an up-to-date list of transaction services from the service registration node and, in response to receiving a transaction request from the business system, to invoke a transaction service associated with the transaction request from one of the transaction service nodes; and a plurality of transaction repositories. Therefore, the stability of the whole system can be improved, and the influence on the operation of the whole system due to the problem of any part can be avoided.

Description

Channel transaction system

Technical Field

Embodiments of the present disclosure relate generally to the field of electronic commerce and, more particularly, to a channel trading system.

Background

The channel transaction system is a system for accessing a business system of a third-party payment service mechanism such as a cash register, a communication and the like to an access party platform (such as a unionpay system and an internet system) of a banking mechanism so as to complete transaction processing such as payment or refund.

The current channel trading system is usually very complex and large, the configuration is very troublesome, and the operation of the whole system can be affected by the occurrence of any one component, even the whole system is paralyzed, and related trading can be affected.

Therefore, there is a need for a channel trading system, which can simplify the configuration of the system, increase the stability of the whole system, avoid the influence on the operation of the whole channel trading system due to any problem, and further effectively ensure the successful completion of the trading.

Disclosure of Invention

In view of the above problems, the present disclosure provides a channel trading system, which can increase the stability of the whole system, avoid the influence on the operation of the whole channel trading system due to any part of problems, and further effectively ensure the successful completion of trading.

According to a first aspect of the present disclosure, there is provided a channel trading system comprising a plurality of trading cluster subsystems and a management subsystem, the management subsystem being configured to configure and manage each of the plurality of trading cluster subsystems; the plurality of transaction cluster subsystems are deployed at different locations and are communicatively isolated from each other, each transaction cluster subsystem comprising: a plurality of transaction service nodes configured to provide transaction services for a plurality of product dimensions; a plurality of service registration nodes configured to register transaction services registered by the transaction service node with the service registration node based on a transaction service list; a plurality of transaction invoking client nodes configured to obtain an up-to-date list of transaction services from the service registration node and, in response to receiving a transaction request from a business system, to invoke a transaction service associated with the transaction request from one of the transaction service nodes in the up-to-date list of transaction services; and a plurality of transaction libraries, each transaction library being communicatively connected to the transaction invoking client node and the transaction service node, and each transaction library storing a plurality of record tables and being configured to determine in which record table information of a transaction is stored according to a time at which the transaction occurred, each record table being for recording information of transactions that occurred within one time interval, and different record tables being associated with different time intervals.

In some embodiments, the plurality of transactional service nodes are deployed on one or more different hosts, and the number of hosts for deploying the plurality of transactional service nodes is less than or equal to the number of the plurality of transactional service nodes.

In some embodiments, in each transaction cluster subsystem, each transaction invoking client node is communicatively connected with each of the transaction service nodes, each transaction invoking client node is further communicatively connected with each of the service registration nodes, and each transaction service node is communicatively connected with each of the service registration nodes.

In some embodiments, the configuration and management of each of the plurality of transaction cluster subsystems by the management subsystem comprises: the management subsystem is configured to periodically detect availability information for each transaction clustering subsystem and, in response to detecting unavailability of one of the transaction clustering subsystems, transfer a transaction on that transaction clustering subsystem to another transaction clustering subsystem of the transaction clustering subsystems.

In some embodiments, the configuring and managing each of the plurality of transaction cluster subsystems by the management subsystem further comprises: the management subsystem is configured to detect availability information for each transaction vault in each transaction cluster subsystem, and is further configured to periodically send availability information for each transaction cluster subsystem and availability information for the associated transaction repository to the business system, wherein the transaction request from the business system comprises a transaction request serial number comprising available system parameter bits and time parameter bits, the available system parameter bits are determined by the business system based on availability information for each transaction cluster subsystem and availability information for the associated transaction library, and the available system parameter bit indicates to which transaction cluster subsystem the transaction request should be sent and in which transaction repository of that transaction cluster subsystem the associated transaction record should be stored, and the time parameter bit indicates the time at which the transaction request originated.

In some embodiments, the management subsystem detects availability information for each transaction cluster subsystem by: periodically sending a probe signal to a load balancing device associated with the transaction cluster subsystem; determining that the transaction cluster subsystem is unavailable if the management subsystem does not receive a response signal returned by the load balancing device for each of a predetermined number of consecutively transmitted probe signals.

In some embodiments, the channel trading system further comprises a central database communicatively coupled to the management subsystem and storing configuration parameters associated with each of the plurality of trading cluster subsystems; and, the managing subsystem being configured to configure and manage each of the plurality of transaction cluster subsystems further comprises: the management subsystem is configured to configure the respective transaction cluster subsystem based on configuration parameters stored in the central database.

In some embodiments, each transaction cluster subsystem is associated with a load balancing device and a plurality of web servers, the load balancing device configured to share transaction information received from the business system evenly across the plurality of web servers; each web server is configured to forward transaction information received from the load balancing device to one of the transaction invoking client nodes in the transaction cluster subsystem or to send a response message from one of the transaction invoking client nodes to the load balancing device for sending to the traffic system through the load balancing device.

In some embodiments, each trading service provided by the trading service node comprises a plurality of trading channels, each trading channel being implemented by configuring an associated interface pre-established in a channel trading system using respective production parameters, the interface being associated with an access party platform upstream of the trading channel, and each trading channel comprising a plurality of trading resources.

In some embodiments, the transaction invoking client node being configured to, in response to receiving a transaction request from a business system, invoke a transaction service associated with the transaction request from one of the transaction service nodes in the up-to-date list of transaction services comprises the transaction invoking client node being configured to: parsing the transaction request to determine whether the transaction request specifies a transaction channel included in a transaction service in the up-to-date list of transaction services; in response to the transaction request specifying a transaction service but not specifying a transaction channel, selecting from the up-to-date list of transaction services one of the transaction service specified by the transaction request and the transaction channel included by the transaction service; in response to determining that the transaction request specifies a transaction service and an associated transaction channel, selecting the transaction service specified by the transaction request from the up-to-date list of transaction services and selecting the associated transaction channel from the transaction service; sending an application request for the selected transaction channel to a corresponding transaction service node; invoking one of the available trading resources if a feedback message is received from the corresponding trading service node that the trading channel has greater than or equal to one available trading resource; and if a feedback message that the transaction channel has no available transaction resources is received from the corresponding transaction service node, sending a warning that the transaction resources of the transaction channel are insufficient to the business system.

In some embodiments, the upstream access platform comprises at least one of an internet payment clearing platform, an internet code scanning payment platform, a unionpay cardless payment platform, and a unionpay full channel payment platform.

In some embodiments, the transaction services include a general payment service, an agreement payment service, a gateway payment service, a merchant payment service.

It should be understood that the statements in this section do not necessarily identify key or critical features of the embodiments of the present disclosure, nor do they limit the scope of the present disclosure. Other features of the present disclosure will become apparent from the following description.

Drawings

The above and other features, advantages and aspects of various embodiments of the present disclosure will become more apparent by referring to the following detailed description when taken in conjunction with the accompanying drawings. In the drawings, like or similar reference characters designate like or similar elements.

FIG. 1 shows an exemplary schematic diagram of a channel trading system 100 according to an embodiment of the present invention.

Fig. 2 shows a schematic diagram of a transaction clustering subsystem 200 according to an embodiment of the present disclosure.

Fig. 3 shows a schematic diagram of a portion of a transaction clustering subsystem 300 according to an embodiment of the present disclosure.

Fig. 4 illustrates an exemplary diagram of a transaction request serial number 400 according to an embodiment of the disclosure.

FIG. 5 illustrates an exemplary diagram of a transaction invoking client node invoking a transaction channel provided by a transaction service node according to an embodiment of the disclosure.

Fig. 6 illustrates an exemplary schematic diagram of an interface configuration based on an upstream access platform, according to an embodiment of the disclosure.

Detailed Description

Exemplary embodiments of the present disclosure are described below with reference to the accompanying drawings, in which various details of the embodiments of the disclosure are included to assist understanding, and which are to be considered as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the present disclosure. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.

The term "include" and variations thereof as used herein is meant to be inclusive in an open-ended manner, i.e., "including but not limited to". Unless specifically stated otherwise, the term "or" means "and/or". The term "based on" means "based at least in part on". The terms "one example embodiment" and "one embodiment" mean "at least one example embodiment". The term "another embodiment" means "at least one additional embodiment". The terms "first," "second," and the like may refer to different or the same object. Other explicit and implicit definitions are also possible below.

As mentioned above, the current channel transaction system is usually very complex and large, and is very troublesome to configure, and a problem occurring in any one of the components may affect the operation of the whole system, even lead to the breakdown of the whole system, and thus affect the related transaction.

To address at least in part one or more of the above issues and other potential issues, an example embodiment of the present disclosure proposes a channel trading system, including a management subsystem and a plurality of trading cluster subsystems, the management subsystem configured to configure and manage each of the plurality of trading cluster subsystems; the plurality of transaction cluster subsystems are deployed at different locations and are communicatively isolated from each other, each transaction cluster subsystem comprising: a plurality of identical transaction service nodes configured to provide transaction services for a plurality of product dimensions; a plurality of service registration nodes configured to register transaction services registered by the transaction service node with the service registration node based on a transaction service list; a plurality of identical transaction invoking client nodes configured to obtain an up-to-date list of transaction services from the service registration node and, in response to receiving a transaction request from a business system to conduct a transaction, to invoke a transaction service associated with the transaction from the up-to-date list of transaction services from one of the transaction service nodes; and a plurality of transaction libraries, each transaction library being communicatively connected to the transaction invoking client node and the transaction service node, and each transaction library storing a plurality of record tables and being configured to determine in which record table information of a transaction is stored according to a time at which the transaction occurred, each record table being for recording information of transactions that occurred within one time interval, and different record tables being associated with different time intervals. In this way, the stability of the whole system can be increased, the influence on the operation of the whole channel trading system due to the problem of any part is avoided, and the successful completion of the trading can be effectively ensured.

FIG. 1 shows an exemplary schematic diagram of a channel trading system 100 according to an embodiment of the present invention. As shown in FIG. 1, the channel trading system 100 may include a management subsystem 110 and a plurality of trading cluster subsystems 120-1 and 120-2 (hereinafter collectively referred to as 120). Although the channel trading system 100 is shown in FIG. 1 to include only two trading cluster subsystems, in actual practice the channel trading system 100 may include more trading cluster subsystems as desired. In the present disclosure, by using a plurality of transaction clustering subsystems, clustered deployment of various transaction services can be realized, thereby contributing to increase of Transaction Per Second (TPS) of a channel transaction system, and further increasing daily transaction amount. On the other hand, the transaction cluster subsystems may be deployed at different locations and the transaction cluster subsystems are communicatively isolated from each other. That is, different transaction cluster subsystems are deployed at different locations and there is no network access relationship between the different transaction cluster subsystems (i.e., the network access relationship between the transaction cluster subsystems are isolated). For example only, transaction cluster subsystem 120-1 may be deployed in a certain machine room in a certain city, while transaction cluster subsystem 120-2 may be deployed in a different machine room in the same city, or in a different machine room in a different city. By deploying different transaction clustering subsystems 120 at different locations, in case of a power failure or a long-term failure of a machine room associated with a certain transaction clustering subsystem, the corresponding transaction can be switched to another transaction clustering subsystem for proceeding without causing the transaction to be interrupted, thereby ensuring high availability and high concurrency of related transaction services. In the present disclosure, each transaction cluster subsystem 120 may have the same functionality, and may have alternatives. The transaction clustering subsystem 120 is described in further detail below in conjunction with fig. 2 and 3.

The management subsystem 110 is configured to configure and manage each of the plurality of transaction clustering subsystems 120. In particular, the management subsystem 110 may be configured to periodically detect availability information for each transaction clustering subsystem 120 and, in response to detecting that one of the transaction clustering subsystems 120 is unavailable, transfer transactions on the unavailable transaction clustering subsystem 120 to another transaction clustering subsystem 120. The management subsystem 110 may also be configured to detect availability information for each transaction library (described in more detail further below) in each transaction clustering subsystem 120, and may also be configured to periodically send the availability information for each transaction clustering subsystem 120 and the availability information for the associated transaction library to the business system 160. In the present disclosure, the business system 160 may be a business system of a third party payment service, such as a UNICOM system, a cash register system, a wealth system, a cross-border payment system, and the like. In the present disclosure, the transaction request from the business system may include a transaction request serial number such that the transaction request may be accurately located to the specific transaction clustering subsystem 120 in the channel trading system 100 and the transaction database and record table therein. Specifically, as shown in FIG. 4, the transaction request serial number 400 may include a time parameter number of a predetermined length (e.g., 8 bits) for indicating the time at which the transaction request originated (i.e., the time at which the transaction associated with the transaction request occurred), which may include the year, month, date, and hour at which the transaction request originated. The transaction request serial number 400 may also include serial number parameter bits of a predetermined length (e.g., 14 bits) to uniquely identify the transaction request serial number 400 for distinguishing from other transaction request serial numbers. In particular, the transaction request serial number 400 may also include available system parameter bits of a predetermined length (e.g., 6 bits). The available system parameters are determined by the business system 160 based on the availability information of each transaction cluster subsystem and the availability information of the associated transaction repository, and thus may indicate to which transaction cluster the transaction request should be sent and in which transaction repository the associated transaction record should be stored. For example, the business system 160 may periodically query and cache availability information of the channel trading system 100 and availability information of the associated trading banks, and may then determine corresponding available system parameter bits based on the availability information when conducting a trade, and then generate a trade request serial number to be sent to the channel trading system 100 for sending to the designated trade cluster subsystem based on the available system parameter bits and the time at which the trade request originated. Therefore, after receiving the transaction request, the channel transaction system 100 can accurately locate the specific transaction cluster subsystem, the transaction library and the record table according to the serial number of the transaction request, thereby reducing the operation of mapping the specific transaction library and the record table through the transaction serial number, further reducing the interaction times of the database and improving the transaction efficiency.

In some embodiments, the management subsystem 110 may detect availability information for each transaction cluster subsystem by: periodically send a probe signal to the load balancing device 130 associated with the transaction cluster subsystem 120; if the management subsystem 110 does not receive a response signal returned by the load balancing device for a predetermined number of consecutively transmitted probe signals, it determines that the transaction clustering subsystem 120 is unavailable.

As shown in fig. 1, the channel trading system 100 may include a central database 150 in addition to the management subsystem 110 and the trading cluster subsystem 120. The central database 150 is communicatively coupled to the management subsystem 110, and the central database 150 stores configuration parameters associated with each of the plurality of transaction cluster subsystems 120. In the present disclosure, the configuration and management of the management subsystem 110 to each of the plurality of transaction clustering subsystems 120 may further include: the management subsystem 110 is configured to configure the respective transaction cluster subsystem based on configuration parameters stored in the central database 150.

Further, as shown in FIG. 1, each transaction cluster subsystem 120 may be associated with one load balancing device 130-1 or 130-2 (hereinafter collectively 130) and a plurality of web servers (140-1, 140-2 or 140-3, 140-4, hereinafter collectively 140). The load balancing device 130 is configured to evenly distribute transaction information (including transaction requests) received from the business system 160 to the respective plurality of web servers 140. Each web server 140 is configured to forward transaction information received from the load balancing device 130 to one of the transaction invoking client nodes in the transaction cluster subsystem 120 or to send a response message from one of the transaction invoking client nodes to the load balancing device 130 for transmission to the business system 160 through the load balancing device 130. Although two web servers 140 are shown in fig. 1 as being associated with each transaction clustering subsystem 120, in actual practice, more web servers 140 may be associated with each transaction clustering subsystem 120 as needed and still be within the scope of the present disclosure. In some embodiments, the web server 140 may be an HTTP service and a reverse proxy web server, such as a Nginx, which has the characteristics of light weight, small memory usage, and strong concurrency capability, and can provide a high-performance HTTP service.

Additionally, the transaction clustering subsystem 120 may be communicatively coupled with an upstream accessor platform 170, for example, via a transaction service node, which will be further described later in conjunction with fig. 3, to interface a business system of a third party payment service organization with the upstream accessor platform 170 in order to complete a transaction process such as payment or refund requested by the business system. The upstream access platform 170 may include, but is not limited to, an internet payment clearing platform, an internet code scanning payment platform, a unionpay cardless payment platform, a unionpay full channel payment platform, and the like.

Fig. 2 shows a schematic diagram of a transaction clustering subsystem 200 according to an embodiment of the present disclosure. As shown in fig. 2, each transaction clustering subsystem 200 (i.e., transaction clustering subsystem 120 shown in fig. 1) may include a transaction server 210, a service registry 230, a transaction invocation client 230, and a transaction library 240. The transaction server 210, the service registry 230, the transaction invocation client 230 and the transaction library 240 are communicatively connected (wired or wireless) to each other via communication lines, thereby enabling communication with each other. As will be further explained below in conjunction with fig. 3, the plurality of transaction service nodes in the transaction server 210 may be deployed on one or more hosts (i.e., computing devices), and the number of hosts for deploying the plurality of transaction service nodes may be less than or equal to the number of transaction service nodes. When the number of hosts for deploying the plurality of transaction service nodes is equal to the number of transaction service nodes, it can be considered that only one transaction service node is deployed on each host; when the number of hosts for deploying the plurality of transaction service nodes is less than the number of transaction service nodes, it may be considered that a plurality of transaction service nodes are deployed on each host. Service registry nodes in the service registry 230 and transaction invocation client nodes in the transaction invocation client 230 may also be deployed in a similar manner.

Fig. 3 shows a schematic diagram of a portion of a transaction clustering subsystem 300 (i.e., the transaction clustering subsystem 120 shown in fig. 1 and a portion of the transaction clustering subsystem 200 shown in fig. 2) according to an embodiment of the present disclosure. The transaction server 210 of the channel transaction system 300 may include a plurality of transaction service nodes 310-1 to 310-4 (hereinafter, referred to as 310), and each transaction service node 310 may have the same service capability. In the present disclosure, the transaction service nodes are configured to provide transaction services for multiple product dimensions. The transaction services may include, but are not limited to, ordinary payment services, agreement payment services, gateway payment services, merchant payment services, and the like.

The transaction invoking client 230 of the channel trading system 300 may comprise a plurality of transaction invoking client nodes 330-1 through 330-3 (hereinafter generally 330), each transaction invoking client node 330 may have the same capabilities. In the present disclosure, the transaction invoking client nodes 330 are configured to obtain the latest transaction service list from the service registration node 320, and in response to receiving a transaction request from the business system 160, invoke a transaction service associated with the transaction request in the latest transaction service list from one of the transaction service nodes 310. In some embodiments, the service registration node actively pushes the latest transaction service list to each transaction invoking client node 330 whenever there is an update in the transaction service list (e.g., there is an addition or deletion of transaction services).

The service registry 220 of the channel trading system may include a plurality of service registration nodes 320-1 to 320-3 (hereinafter generally 320), the service registration nodes 320 being configured to register trading services with which the respective trading service node 310 is registered based on a list of trading services. In some embodiments, one of the service registration nodes 320 is a master service registration node, and the other service registration nodes are slave service registration nodes. The main service registration node is responsible for communicating with the transaction invoking client node and the transaction service node to register transaction services registered by the transaction service node in the transaction service list and inform the client node of various updates of the transaction service list, including addition and deletion of the transaction services in the transaction service list. For example, the primary service registration node may actively push the latest list of transaction services to the client node. The slave service registration node is for assisting the master service registration node to register transaction services with which the transaction service node is registered. In the present disclosure, each service registration node 320 may have a distributed scheduling service plug-in (i.e., middleware) installed thereon for service registration and discovery, such as a ZooKeeper, and thus be implemented as a distributed application node. Transaction service node 310 may register the transaction services it provides with service registration node 320 (e.g., a master service registration node) at startup. Transaction services may include, but are not limited to, ordinary payment services, agreement payment services, gateway payment services, and merchant payment services, among others. When a transaction invoking client node 330 needs to invoke a certain transaction service, this transaction service in the up-to-date list of transaction services may be invoked from one of the transaction service nodes. In the present disclosure, the transaction calling client node 330 calls the desired transaction service from one of the transaction service nodes by way of a Remote Procedure Call (RPC). In the present disclosure, when the transaction service node 310 shuts down (i.e., no longer provides) a transaction service, the transaction service node 310 notifies the service registration node 320 (e.g., the main service registration node) of the shutdown of the transaction service, so that the service registration node deletes the transaction service from the transaction service list, and then the service registration node notifies each transaction invoking client node of the update of the transaction service list, thereby implementing a secure shutdown of the transaction service.

It should be appreciated that although the channel trading system is shown in fig. 3 as including four trading service nodes 310, three service registration nodes 320, and three trading invocation client nodes, a channel trading system may include more or fewer trading service nodes 310, service registration nodes 320, and trading invocation client nodes while remaining within the scope of the present disclosure.

In addition, although four transaction service nodes 310 are respectively deployed on four different hosts in fig. 3, the four transaction service nodes 310 may also be respectively deployed on two hosts, wherein, for example, two transaction service nodes 310 are deployed on each host. Similarly, although three service registration nodes 320 are deployed on three different hosts in fig. 3, the three service registration nodes 310 may be deployed on two hosts, for example, two service registration nodes 320 deployed on one host and one service registration node 320 deployed on the other host. Three transaction invoking client nodes may also be deployed in a similar manner.

That is, two or more transaction service nodes 320 may be deployed simultaneously with a single host. For example, in fig. 3, one or more transaction service nodes 320 may be respectively augmented and deployed, e.g., on each host, such that, e.g., 8 or more transaction service nodes may be implemented with, e.g., four hosts. Thus, in this way, an extension in the vertical dimension of the transaction service node may be achieved. The transaction invoking client node and the service registration node may also be deployed on separate hosts or on different hosts in a similar manner. In this way, the TPS of the channel trading system can be quickly enhanced by starting service applications on each trading service node 320 in a short time. After vertical expansion, multiple application services with a single transaction service node 320 have the same function, in this way, a network access relation is not opened specially, and multiple service ports (for example, 10 service ports) are reserved for being called by the transaction calling client node 330 when the network access relation is opened for the first time. The expansion mode has the fastest and most flexible expansion because the network service relation does not need to be opened.

In the present disclosure, by introducing a service registration node 320 (e.g., a master service registration node) in each transaction cluster subsystem, and each transaction service node 310 in the transaction cluster subsystem registers transaction services provided by it with the service registration node 320, and the service registration node 320 notifies the transaction invoking client nodes of updates of the transaction service list, horizontal extension of the transaction service node 310 and the transaction invoking client node 330, that is, distributed deployment of the transaction service node 320 and the transaction invoking client node 330, is achieved. In particular, in the present disclosure, in each transaction cluster subsystem, each transaction invoking client node may be communicatively connected with each of the transaction service nodes, each transaction invoking client node may be further communicatively connected with each of the service registration nodes, and each transaction service node may be communicatively connected with each of the service registration nodes. For example, from the perspective of a transaction service node in each transaction cluster subsystem, the remaining transaction service nodes and corresponding resources are remote and only its own resources are local.

In the method, the distributed deployment and the clustered deployment are realized in the channel trading system, so that the channel trading system can realize high concurrency, high availability and high expansion of an application level, namely flexible expansion according to the transverse level of service nodes in a cluster and flexible expansion of the transverse level of the whole cluster, and further infinite support of the trading volume of a structural layer of the application system can be realized.

As shown in fig. 2, each transaction cluster subsystem 200 further includes a plurality of transaction libraries 240, each transaction library 240 is communicatively connected to a respective transaction invoking client node and a respective transaction service node in the transaction cluster subsystem 200, and each transaction library 240 has a plurality of record tables and is configured to determine in which record table information of the transaction is stored according to the time when the transaction occurs, each record table is used for recording information of transactions occurring within one time interval, and different record tables are associated with different time intervals. Although only two transaction repositories 240 are shown in FIG. 2 as comprising the transaction clustering subsystem 200, in actual use, more transaction repositories 240 may be included as desired. For example only, if the transaction clustering subsystem 200 includes two transaction repositories 240, each transaction repository 240 may store, for example, 24 record tables per day, each record table for recording transactions that occur within a particular hour of the day; each transaction repository 240 may also store, for example, 48 records per day, with every second record corresponding to transactions occurring within a particular current hour; and so on. By the method, the transaction can be stored in the record table corresponding to the time interval in which time interval the transaction occurs, so that the transactions occurring in different time intervals are stored in different record tables, the data volume recorded by each record table can be reduced, and the purpose of improving the data processing capacity of each record table is achieved. As can be seen from the above description, in the present disclosure, a manner of combining the vertical sub-table and the horizontal sub-table of the transaction library can be implemented, so that different transaction cluster subsystems can monopolize specific multiple transaction databases, that is, the transaction libraries between the transaction cluster subsystems are completely isolated.

FIG. 5 illustrates an exemplary diagram of a transaction invoking client node invoking a transaction channel provided by a transaction service node according to an embodiment of the disclosure. As shown in fig. 5, trading service node 510 (which may be any of trading service nodes 310 shown in fig. 3) may provide trading services (e.g., trading services 5101 and 5102) for multiple product dimensions, and each trading service may include multiple trading channels. For example, in fig. 5, trading service 5101 includes trading channel 1 and trading channel 2, while trading service 5102 includes trading channel 3 and trading channel 4. Although it is shown in fig. 5 that the transaction service node 510 includes only two transaction services associated with agreement payments and ordinary payments, and each transaction service includes only two associated transaction channels, in actual practice, the transaction service node 510 may include more different transaction services, and each transaction service may also include more transaction channels. The transaction services provided by the transaction service node 510 may be, for example, one or more of a general payment service, an agreement payment service, a gateway payment service, a merchant payment service, and so on. For example, if a transaction request received by transaction invoking client node 530 (which may be any of transaction invoking client nodes 330 shown in fig. 3) is associated with an agreed upon payment transaction 5301, transaction invoking client node 530 may invoke a transaction service provided by the corresponding transaction service node 510 that is associated with the agreed upon payment transaction 5301, such as transaction service 5101. As another example, if the transaction request received by transaction invoking client node 530 is related to a generic payment transaction 5302, transaction invoking client node 530 may invoke a transaction service provided by the corresponding transaction service node 510 that is associated with the generic payment transaction 5302, such as transaction service 5102. Of course, fig. 5 only shows a few examples, and other transactions are also possible in practical applications, and further description is omitted here for the sake of brevity.

In the present disclosure, each transaction channel may be implemented by configuring a pre-established associated interface in the channel trading system, associated with an access party platform upstream of the trading channel, with the corresponding production parameters. In the present disclosure, each interface may have an interface specification corresponding to the associated upstream accessor platform. Specifically, each interface may be pre-established based on a corresponding interface specification, wherein corresponding interface configuration rules, transaction communication address sets, supported issuer and account types, a format of a service type code, a format of a return code, etc. may be specified. For example, as shown in fig. 6, respective interfaces 610 may be established, for example, based on a full channel payment platform and a new cardless payment platform with the unionpay 620, a payment clearing platform and a scanning payment platform with the internetwork 630, and so on, respectively. In the method, the corresponding interfaces are pre-established for each upstream access party platform, so that when a new transaction channel needs to be put into production, the transaction channel can be put into production only by finding the corresponding interface and configuring the corresponding interface with the parameters related to the transaction channel, and the channel transaction system does not need to be restarted. Therefore, repeated configuration items are reduced, configuration work is simplified, risks caused by restarting a channel transaction system for multiple times can be avoided, and meanwhile operation and maintenance complexity is reduced.

Furthermore, interfaces associated with the same upstream accessor platform may have different production parameters, depending on the particular accessor, and thus be implemented as different channels of transactions. For example, taking the unionpay channel-wide payment platform as an example, for the interface associated with the platform, since the access party is, for example, the shanghai branch company and the zhejiang branch company, two different sets of production parameters may be provided, and thus two different transaction channels, namely, the unionpay channel-shanghai transaction channel and the unionpay channel-wide zhejiang transaction channel, may be implemented in the production system accordingly.

In the present disclosure, each trading channel may include a plurality of trading resources. For example, if a transaction channel has 10 transaction resources, it means that the transaction channel can be called by 10 threads at the same time, and when more than 10 threads need to be called at the same time, it means that the transaction resources of the transaction channel are insufficient. The amount of trading resources included in each trading channel can be configured as desired. And different transaction channels may include different amounts of transaction resources. Thus, in the present disclosure, a transaction invoking client node may respond to receiving a transaction request from a business system by invoking from one of the transaction service nodes a transaction service associated with the transaction request in the up-to-date list of transaction services. First, a transaction request is parsed to determine whether the transaction request specifies a transaction channel included in the transaction services in the up-to-date list of transaction services. Then, in response to the transaction request specifying a transaction service but not specifying a transaction channel, one of the transaction service specified by the transaction request and the transaction channel included by the transaction service is selected from the latest list of transaction services. Then, in response to determining that the transaction request specifies a transaction service and an associated transaction channel, the transaction service specified by the transaction request is selected from the latest list of transaction services and the associated transaction channel is selected from the transaction services. And then sending an application request for the selected transaction channel to the corresponding transaction service node. If a feedback message that the transaction channel has more than or equal to one available transaction resource is received from the corresponding transaction service node, one of the available transaction resources is invoked. And if a feedback message that the transaction channel has no available transaction resources is received from the corresponding transaction service node, sending a warning that the transaction resources of the transaction channel are insufficient to the business system.

By adopting the means, the stability of the whole channel trading system can be improved, the problem that the operation of the whole channel trading system is influenced by the problem of any part is avoided, and the successful completion of trading can be effectively ensured.

Having described embodiments of the present disclosure, the foregoing description is intended to be exemplary, not exhaustive, and not limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen in order to best explain the principles of the embodiments, the practical application, or improvements made to the technology in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

Claims

1. A channel transaction system comprises a management subsystem and a plurality of transaction cluster subsystems,

the management subsystem is configured to configure and manage each of the plurality of transaction cluster subsystems;

the plurality of transaction cluster subsystems are deployed at different locations and are communicatively isolated from each other, each transaction cluster subsystem comprising:

a plurality of transaction service nodes configured to provide transaction services for a plurality of product dimensions;

a plurality of service registration nodes configured to register transaction services registered by the transaction service node with the service registration node based on a transaction service list;

a plurality of transaction invoking client nodes configured to obtain an up-to-date list of transaction services from the service registration node and, in response to receiving a transaction request from a business system, to invoke a transaction service associated with the transaction request from one of the transaction service nodes in the up-to-date list of transaction services; and

a plurality of transaction repositories, each transaction repository communicatively connected to the transaction invoking client node and the transaction service node, and each transaction repository storing a plurality of record tables and configured to determine in which record table information for a transaction is stored depending on the time at which the transaction occurred, each record table for recording information for transactions occurring within one time interval, and different record tables associated with different time intervals.

2. The channel trading system of claim 1, wherein the plurality of trading service nodes are deployed on one or more different hosts and the number of hosts for deploying the plurality of trading service nodes is less than or equal to the number of the plurality of trading service nodes.

3. The channel trading system of claim 1, wherein in each trading cluster subsystem, each trading invocation client node is communicatively connected with each of the trading service nodes, each trading invocation client node is further communicatively connected with each of the service registration nodes, and each trading service node is communicatively connected with each of the service registration nodes.

4. The channel trading system of claim 1, wherein the management subsystem configured to configure and manage each of the plurality of trading cluster subsystems comprises:

the management subsystem is configured to periodically detect availability information for each transaction clustering subsystem and, in response to detecting unavailability of one of the transaction clustering subsystems, transfer a transaction on that transaction clustering subsystem to another transaction clustering subsystem of the transaction clustering subsystems.

5. The channel trading system of claim 4, wherein the management subsystem configured to configure and manage each of the plurality of trading cluster subsystems further comprises:

the management subsystem is configured to detect availability information for each transaction library in each transaction cluster subsystem and is further configured to periodically send the availability information for each transaction cluster subsystem and the availability information for the associated transaction library to the business system.

6. The channel trading system of claim 5, wherein the trade request from the business system comprises a trade request serial number, the trade request serial number comprises an available system parameter bit and a time parameter bit, the available system parameter bit is determined by the business system based on availability information of each trade cluster subsystem and availability information of an associated trade pool, and the available system parameter bit indicates to which trade cluster subsystem the trade request should be sent and in which trade pool of the trade cluster subsystem the associated trade record should be stored, and the time parameter bit indicates the time at which the trade request originated.

7. The channel trading system of claim 5, wherein the management subsystem detects availability information for each trading cluster subsystem by:

periodically sending a probe signal to a load balancing device associated with the transaction cluster subsystem; and

determining that the transaction cluster subsystem is unavailable if the management subsystem does not receive a response signal returned by the load balancing device for each of a predetermined number of consecutively transmitted probe signals.

8. The channel trading system of claim 4 or 5, further comprising a central database communicatively connected to the management subsystem and storing configuration parameters associated with each of the plurality of trading cluster subsystems;

the management subsystem being configured to configure and manage each of the plurality of transaction cluster subsystems further comprises: the management subsystem is configured to configure the respective transaction cluster subsystem based on configuration parameters stored in the central database.

9. The channel trading system of claim 1, wherein each trading cluster subsystem is associated with a load balancing device and a plurality of web servers,

the load balancing device is configured to evenly distribute transaction information received from the business system to the plurality of web servers;

each web server is configured to forward transaction information received from the load balancing device to one of the transaction invoking client nodes in the transaction cluster subsystem or to send a response message from one of the transaction invoking client nodes to the load balancing device for sending to the traffic system through the load balancing device.

10. The channel trading system of claim 1, wherein each trading service provided by the trading service node comprises a plurality of trading channels, each trading channel being implemented by configuring a pre-established associated interface in the channel trading system using respective production parameters, the interface being associated with an access party platform upstream of the trading channel, and each trading channel comprising a plurality of trading resources.

11. The channel trading system of claim 10, wherein the trade invocation client node being configured to invoke a trading service associated with the trading request from one of the trading service nodes in the up-to-date list of trading services in response to receiving the trading request from a business system comprises the trade invocation client node being configured to:

parsing the transaction request to determine whether the transaction request specifies a transaction channel included in a transaction service in the up-to-date list of transaction services;

in response to the transaction request specifying a transaction service but not specifying a transaction channel, selecting from the up-to-date list of transaction services one of the transaction service specified by the transaction request and the transaction channel included by the transaction service;

in response to determining that the transaction request specifies a transaction service and an associated transaction channel, selecting the transaction service specified by the transaction request from the up-to-date list of transaction services and selecting the associated transaction channel from the transaction service;

sending an application request for the selected transaction channel to a corresponding transaction service node;

invoking one of the available trading resources if a feedback message is received from the corresponding trading service node that the trading channel has greater than or equal to one available trading resource;

and if a feedback message that the transaction channel has no available transaction resources is received from the corresponding transaction service node, sending a warning that the transaction resources of the transaction channel are insufficient to the business system.

12. The channel transaction system of claim 10, wherein the upstream access platform comprises at least one of an internet payment clearing platform, an internet code scanning payment platform, a unionpay cardless payment platform, and a unionpay channel-wide payment platform.

13. The channel transaction system of claim 1, wherein the transaction services include a general payment service, an agreement payment service, a gateway payment service, a merchant payment service.