Transaction request processing method and device, equipment, storage medium and product

Abstract

The invention discloses a transaction request processing method and device, equipment, a storage medium and a product, and relates to the technical field of routing, and the transaction request processing method comprises the steps: obtaining the attribute information of a transaction card corresponding to a transaction request in response to the transaction request; determining a mode type of a main database in a data sub-database corresponding to the attribute information; judging a transaction type corresponding to the transaction request; and based on the mode type and the transaction type, determining a target database from the data sub-libraries, and routing the transaction request to the target database. According to the method, after the transaction request is responded, the attribute information of the transaction card is obtained, the mode type of the corresponding main database is determined according to the attribute information, the transaction request can be routed to the corresponding database according to the mode type and the transaction type of the transaction request, the transaction request routing can be realized only through one-time calling, and the routing efficiency is improved. The problem that the overall response time is increased due to two times of calling can be avoided.

Description

TECHNICAL FIELD

[0001] The present application relates to the routing technical field, and in particular to a transaction request processing method and device, equipment, storage medium and product. BACKGROUND

[0002] In a bank transaction system, in order to guarantee the high availability and consistency of customer fund transaction, a multi-live architecture is adopted for the database, and the split-database consistency control of transaction link is realized through a first application flow and a routing mechanism. However, the above mechanism needs two calls, the first call is to apply the flow (to obtain the split-database information), and the second call is to initiate the transaction (to carry the flow number and execute the transaction according to the specified split-database). That is, two network requests are needed for each transaction, which increases the overall response time. SUMMARY

[0003] The main purpose of the present application is to provide a transaction request processing method, device, equipment, storage medium and product, which aims to solve the technical problem of two network requests for each transaction and increase the overall response time.

[0004] To achieve the above purpose, the present application provides a transaction request processing method, device, equipment, storage medium and product, the transaction request processing method comprising:

[0005] In response to a transaction request, attribute information of a transaction card corresponding to the transaction request is obtained;

[0006] The mode type of the master database in the data split-database corresponding to the attribute information is determined;

[0007] The transaction type corresponding to the transaction request is determined;

[0008] Based on the mode type and the transaction type, a target database is determined from the data split-database, and the transaction request is routed to the target database.

[0009] In an embodiment, the data split-database includes the master database and a standby database, and the step of determining the target database from the data split-database based on the mode type and the transaction type, and routing the transaction request to the target database comprises:

[0010] If the mode type is a normal routing mode, the transaction request is directly routed to the master database;

[0011] If the mode type is a standby database switching mode, the transaction request is forwarded to the standby database, and the mapping relationship between the transaction request and the standby database is recorded in an abnormal routing table;

[0012] If the mode type is any one of the switch-back mode and the data migration mode, the transaction request is routed to a corresponding database based on the transaction type.

[0013] In an embodiment, the mode types are converted based on preset rules.

[0014] In an embodiment, the step of, if the mode type is any one of the switch-back mode and the data migration mode, routing the transaction request to a corresponding database based on the transaction type, comprises:

[0015] If the mode type is the switch-back mode and the transaction type is the original type transaction, the transaction request is directly routed to the master database;

[0016] If the mode type is the switch-back mode and the transaction type is the subsequent type transaction, the transaction request is forwarded to a database corresponding to an original type transaction request of the transaction request.

[0017] In an embodiment, the step of, if the mode type is any one of the switch-back mode and the data migration mode, routing the transaction request to a corresponding database based on the transaction type, further comprises:

[0018] If the mode type is the data migration mode and the transaction type is the original type transaction, the transaction request is directly routed to the master database;

[0019] If the mode type is the data migration mode and the transaction type is the subsequent type transaction, it is determined whether an original type transaction request of the transaction request is recorded in the abnormal routing table, and if recorded in the abnormal routing table, the transaction request is intercepted.

[0020] In an embodiment, when the mode type is the data migration mode, the abnormal routing data in the standby database is migrated to the master database; the master database after migration is checked, and if the checking result is that the migration is successful, the abnormal routing data in the standby database is deleted, and the data migration mode is changed to a normal routing mode.

[0021] In addition, to achieve the above object, the application further provides a transaction request routing device, which comprises:

[0022] A response module is configured to acquire attribute information of a transaction card corresponding to a transaction request in response to the transaction request.

[0023] A determination module is configured to determine a mode type of a master database in a data sub-database corresponding to the attribute information.

[0024] determining a transaction type corresponding to the transaction request;

[0025] determining a target database from the data sub-database based on the schema type and the transaction type, and routing the transaction request to the target database

[0026] In addition, to achieve the above object, the present application further provides a transaction request routing device, which comprises a memory, a processor and a computer program stored in the memory and executable on the processor, and the computer program is configured to implement the steps of the transaction request processing method as described above.

[0027] In addition, to achieve the above object, the present application further provides a storage medium, which is a computer readable storage medium, and the storage medium stores a computer program, and the computer program is executed by a processor to implement the steps of the transaction request processing method as described above.

[0028] In addition, to achieve the above object, the present application further provides a computer program product, which comprises a computer program, and the computer program is executed by a processor to implement the steps of the transaction request processing method as described above.

[0029] The one or more technical solutions provided by the present application have at least the following technical effects:

[0030] In a bank transaction system, in order to guarantee the high availability and consistency of customer fund transactions, a multi-live architecture is adopted for the database, and a first application flow and then a routing mechanism is used to realize the consistency control of the transaction link in the sub-database, but the above mechanism needs two calls, the first call is to apply the flow (to obtain the sub-database information), and the second call is to initiate the transaction (to carry the flow number and execute the transaction according to the specified sub-database), that is, each transaction needs two network requests, which increases the overall response time. In response to the transaction request, the present application obtains the attribute information of the transaction card corresponding to the transaction request; determines the schema type of the master database in the data sub-database corresponding to the attribute information; determines the transaction type corresponding to the transaction request; determines the target database from the data sub-database based on the schema type and the transaction type, and routes the transaction request to the target database. After responding to the transaction request, the present application obtains the attribute information of the transaction card, determines the schema type of the corresponding master database according to the attribute information, and routes the transaction request to the corresponding database according to the schema type and the transaction type of the transaction request. Only one call is needed to realize the transaction request routing, which can avoid the problem of increasing the overall response time caused by two calls. BRIEF DESCRIPTION OF DRAWINGS

[0031] The accompanying drawings, which are incorporated herein and constitute part of the specification, illustrate embodiments consistent with the application and, together with the description, function to explain the principles of the application.

[0032] In order to more clearly illustrate the technical solutions in the embodiments of the present application or the prior art, the accompanying drawings needed to be used in the embodiments or prior art description will be briefly introduced as follows. Obviously, for those of ordinary skill in the art, the other drawings can be obtained based on these drawings without any creative work.

[0033] Figure 1 A flowchart provided for the transaction request processing method embodiment one of the present application;

[0034] Figure 2 A general architecture diagram of the multi-active routing scheme of the transaction request processing method of the present application;

[0035] Figure 3 A routing flowchart of mode A of the transaction request processing method of the present application;

[0036] Figure 4 A routing flowchart of mode B of the transaction request processing method of the present application;

[0037] Figure 5 A routing flowchart of mode C of the transaction request processing method of the present application;

[0038] Figure 6 A routing application processing logic diagram of the transaction request processing method of the present application;

[0039] Figure 7 An abnormal routing data migration diagram of the transaction request processing method of the present application;

[0040] Figure 8 A service gateway processing logic diagram of the transaction request processing method of the present application;

[0041] Figure 9 A routing mode flowchart of the transaction request processing method of the present application;

[0042] Figure 10 A module structure diagram of the transaction request routing device of the embodiment of the present application;

[0043] Figure 11 A device structure diagram of the hardware running environment involved in the transaction request processing method in the embodiment of the present application.

[0044] The purpose implementation, functional features and advantages of the present application will be further explained with reference to the embodiments and the accompanying drawings. DETAILED DESCRIPTION

[0045] It should be understood that the specific embodiments described herein are merely intended to explain the technical solutions of the present application, and are not intended to limit the present application.

[0046] In order to better understand the technical solutions of the present application, the following will be described in detail in combination with the drawings of the specification and specific embodiments.

[0047] The main solution of the embodiment of the present application is: in response to a transaction request, obtaining attribute information of a transaction card corresponding to the transaction request; determining a mode type of a master database in a data sub-library corresponding to the attribute information; judging a transaction type corresponding to the transaction request; determining a target database from the data sub-library based on the mode type and the transaction type, and routing the transaction request to the target database.

[0048] In a bank transaction system, in order to guarantee the high availability and consistency of customer fund transactions, a multi-live architecture is adopted for the database, and the consistency control of transaction link is realized through a first application flow and a routing mechanism, but the above mechanism needs two calls, the first call is to apply the flow (obtain the sub-library information), and the second call is to initiate the transaction (carry the flow number and execute the transaction according to the specified sub-library), that is, each transaction needs two network requests, which increases the overall response time.

[0049] After responding to the transaction request, the attribute information of the transaction card is obtained, the mode type of the corresponding master database is determined according to the attribute information, and the transaction request can be routed to the corresponding database according to the mode type and the transaction type of the transaction request, so that the transaction request routing can be realized only by one call, and the problem of increasing the overall response time caused by two calls can be avoided.

[0050] It should be noted that the execution subject of the embodiment can be a computing service device with data processing, network communication and program running functions, such as a tablet computer, a personal computer, a mobile phone, etc., or an electronic device capable of realizing the above functions, a transaction request routing device, etc. The following will take the transaction request routing device as an example to describe the embodiment and each of the following embodiments.

[0051] Based on this, the embodiment of the present application provides a transaction request processing method, which refers to Figure 1 , Figure 1 The flowchart of the first embodiment of the transaction request processing method of the present application is shown in the figure.

[0052] In the embodiment, the transaction request processing method includes steps S10-S40:

[0053] Step S10, in response to a transaction request, obtaining attribute information of a transaction card corresponding to the transaction request;

[0054] It should be noted that the execution subject of the embodiment is a transaction request routing device. The transaction request routing device is provided with a transaction access gateway Gateway App, which is responsible for receiving transaction requests of a business system and forwarding according to routing rules, and is hereinafter referred to as a gateway. The attribute information can include a customer number or a bank card number, and the transaction request routing device interfaces with a business system. When the business system initiates a transaction request, the attribute information of the transaction card related to the transaction is first extracted from the transaction request body.

[0055] Step S20, determine the mode type of the master database in the data sub-database corresponding to the attribute information;

[0056] It can be understood that the transaction request routing device determines whether the sub-database (master database) is alive by periodically sending heartbeat messages and listening to responses, and automatically switches the mode type according to the survival state of the sub-database. Since each attribute information has a corresponding database, the transaction request routing device can determine the master database corresponding to the attribute information through the attribute information, and obtain the mode type currently in the master database.

[0057] Step S30, determine the transaction type corresponding to the transaction request;

[0058] It should be noted that the transaction type includes original class transactions and subsequent class transactions, the original class transactions include business needs such as consumption and cashing, and the subsequent class transactions include business needs such as consumption return and cashing correction. In order to guarantee data consistency and transaction integrity, it is very important to ensure that the subsequent transaction and the original transaction are routed to the same sub-database in the multi-live database architecture, so the transaction request routing device needs to determine the transaction type of the transaction request, and accurately forward the routing request to the sub-database consistent with the original class transaction type when the subsequent class transaction type.

[0059] Specifically, referring to Figure 2 , Figure 2 A multi-live routing scheme overall architecture diagram is provided, wherein Aut App is a transaction system responsible for bank card online transaction processing, and is hereinafter referred to as a transaction application; sub-database exception: the transaction authorization application uses a multi-sub-database architecture, and when a certain sub-database or a connected database instance cannot provide normal service, we call that the sub-database is abnormal; Router App is a routing flow application, which is used to register and query routing information when Aut App sub-database is abnormal, and is hereinafter referred to as a routing application.

[0060] Step S40, based on the mode type and the transaction type, determine a target database from the data sub-database, and route the transaction request to the target database.

[0061] It can be understood that the transaction request routing device can realize intelligent routing of the transaction request based on the mode type of the database and the transaction type in combination with the dynamic routing state machine mechanism, and give consideration to high availability, consistency, performance and optimal configuration of resources.

[0062] In a possible implementation, the step of determining a target database from the data sub-databases based on the mode type and the transaction type and routing the transaction request to the target database comprises:

[0063] If the mode type is a normal routing mode, the transaction request is directly routed to the master database;

[0064] It should be noted that the transaction request routing device takes the sub-database routed according to the attribute information as the master database, and uses a pairing mode when the master database is abnormal, i.e., the DB_DIV1 database and the DB_DIV2 database are mutually reserved, and the pairing database is also allowed to be adjusted.

[0065] It can be understood that the normal routing mode is a mode when the master database corresponding to the attribute information is in an active state. When the mode of the master database is the normal routing mode, whether it is an original transaction such as consumption or a subsequent transaction such as return, the gateway of the transaction request routing device will directly route the transaction request to the master database (master database) according to the key attribute information (such as customer number or bank card number) of the transaction card through the hash fragmentation, without the need to pass through the routing workflow application, thereby realizing an efficient and simplified transaction processing flow, so that online transactions can be normally accepted regardless of whether the routing workflow application is abnormal.

[0066] Specifically, assuming that the sub-database corresponding to the attribute information of customer A is DB_DIV1, the standby database of which is set as DB_DIV2, and the routing result in the normal routing mode (mode A) is as follows:

[0067] Mode A: When the DB_DIV1 database is normal, it is in mode A, at this time, the customer A consumption and subsequent transactions are directly routed to DB_DIV1 according to the customer number, and the routing result is as shown in Figure 3 , Figure 3 A routing flowchart of mode A is provided.

[0068] If the mode type is a standby database switching mode, the transaction request is forwarded to the standby database, and a mapping relationship between the transaction request and the standby database is recorded in an abnormal routing table;

[0069] It should be noted that the standby database mode is a mode applied when the active mode of the master database jumps to the fault or exception mode, and when in this mode, in order to ensure the continuity and high availability of transactions, the transaction request is forwarded to the standby database. When the current mode of the master database is the standby database mode, that is, the master database is abnormal, the gateway of the transaction request routing device automatically routes the transaction request to the pre-configured standby database, and calls the "register abnormal routing" interface provided by the router application (Router App) to record the mapping relationship between the current transaction request and the standby database (including the unique key of the original transaction and the corresponding standby database ID) in the abnormal routing table. In the standby database mode, through the intelligent routing mechanism, it is ensured that even if the master database has a problem, the transaction request can be seamlessly transferred to the standby database for processing. At the same time, by recording the detailed mapping relationship in the routing flow application, not only the consistency and traceability of the data are ensured, but also important basis is provided for future possible data migration and recovery.

[0070] Specifically, when the master DB_DIV1 is abnormal, it will be switched to mode B (standby database mode), at this time all consumption transactions for customer A will be routed to the standby database DB_DIV2, the gateway App calls the "register abnormal routing" interface provided by the router App, and records the unique key of the original transaction and the information of the standby database DB_DIV2 in the abnormal routing table of the router App for subsequent query and management, refer to Figure 4 , Figure 4 A routing flowchart of mode B is provided.

[0071] If the mode type is any one of the switch-back mode and the data migration mode, the transaction request is routed to the corresponding database based on the transaction type.

[0072] It can be understood that the switch-back mode (C mode) and the data migration mode (D mode) are two important abnormal recovery stages in the routing state machine. In these two modes, the state of the master database has changed (such as the master database has been restored or is migrating data), so the gateway of the transaction request routing device needs to dynamically determine which database the transaction request should be routed to according to the transaction type.

[0073] In a possible implementation, if the mode type is any one of the switch-back mode and the data migration mode, the step of routing the transaction request to the corresponding database based on the transaction type includes:

[0074] If the mode type is the switch-back mode and the transaction type is the original transaction, the transaction request is directly routed to the master database;

[0075] It should be noted that the switch-back mode is the mode of the main database after the main database recovers from the abnormal state to the active state. If the mode type is the switch-back mode (C mode) and the transaction type is the original transaction, the transaction request routing device directs and routes the transaction request to the main database (main database DB_DIV1), so that the main database resource after recovery can be used to process the new transaction request as soon as possible, and meanwhile, it is ensured that the subsequent operation involving the historical transaction can correctly find the corresponding sub-database for processing, thereby maintaining the data consistency and business continuity of the entire system.

[0076] If the mode type is the switch-back mode and the transaction type is the subsequent transaction, the transaction request is forwarded to the database corresponding to the original transaction request of the transaction request.

[0077] It can be understood that in the switch-back mode (C mode), the main database (DB_DIV1) has recovered from the failure, but part of the historical transaction record can still exist in the standby database (standby database, DB_DIV2). In order to ensure the data consistency and business continuity, that is, the subsequent transaction and the original transaction are routed to the same sub-database, when the transaction request is the subsequent transaction, it is necessary to judge whether the original transaction corresponding to the subsequent transaction exists in the standby database. If it exists in the standby database, the subsequent transaction also needs to be forwarded to the standby database. If it does not exist in the standby database, the subsequent transaction can be directly routed to the main database according to the customer number.

[0078] Specifically, when the DB_DIV1 database recovers to normal, the C mode is switched, the customer A consumption transaction is routed to the main database, and there is no need to register the routing information in the Router_App; the subsequent transaction needs to be routed and judged by the Router_App, and reference is made to Figure 5 , Figure 5 A routing flowchart of the mode C is provided.

[0079] Further, the Router_App routing sequence application is responsible for providing the routing information processing function of the transaction application in the abnormal state, and provides two interfaces:

[0080] 1) Abnormal routing information registration interface: when the sub-database of the transaction application Aut_App exists in the abnormal state, the gateway application Gateway_App cuts the original transaction to the standby database for processing, at this time, the interface needs to be called to register the abnormal routing sequence information.

[0081] 2) Priority customer sub-database routing interface: provided for the subsequent transaction (such as return). In order to ensure that the sub-database of the subsequent transaction routing is consistent with the original transaction when the original transaction is routed abnormally, the subsequent transaction needs to query whether the original transaction exists in the abnormal routing. If yes, the subsequent transaction is routed according to the original transaction sub-database, otherwise, the subsequent transaction is routed according to the default customer sub-database, reference is made to Figure 6 , Figure 6A routing application processing logic diagram is provided.

[0082] In one possible implementation, if the mode type is any one of the fallback mode and the data migration mode, the step of routing the transaction request to the corresponding database based on the transaction type further comprises:

[0083] If the mode type is the data migration mode and the transaction type is the original transaction, the transaction request is directly routed to the primary database;

[0084] It should be noted that after the stable operation of mode C, the abnormal data needs to be migrated, and mode D is switched at this time. In the data migration mode, the primary database (DB_DIV1) has been restored and is in a stable operation state, so the transaction request routing device can directly route all original transactions to the primary database.

[0085] If the mode type is the data migration mode and the transaction type is the subsequent transaction, it is determined whether the original transaction request of the transaction request is recorded in the abnormal routing table, and if it is recorded in the abnormal routing table, the transaction request is intercepted.

[0086] It can be understood that in the data migration mode (D mode), the transaction request routing device is performing data migration from the backup database (backup database DB_DIV2) to the primary database (primary database DB_DIV1), and in order to ensure data consistency and the integrity of the migration process, the subsequent transaction involving the migrated data must be intercepted or limited, that is, if the original transaction corresponding to the subsequent transaction is in the migrated data, the subsequent transaction is intercepted, and if the original transaction corresponding to the subsequent transaction is not in the migrated data, the subsequent transaction can be directly routed to the primary database according to the customer number, referring to Figure 7 , Figure 7 An abnormal routing data migration diagram is provided.

[0087] Further, in the switching of the above different modes, the transaction system does not need to involve the routing of the transaction system in most cases, does not need to store the routing information, and only needs to record the routing information when the transaction application database is abnormal.

[0088] The above steps provide the entire processing logic of the service gateway, referring to Figure 8 , Figure 8 A service gateway processing logic diagram is provided.

[0089] Further, although the above steps ensure data consistency and the integrity of the migration process, in a high-concurrency scenario, the customer experience is impaired, so a log capture tool is deployed on the gateway to only capture the data changes related to migration.

[0090] In this embodiment, by combining the database mode type and the transaction type, intelligent dynamic routing is realized, the high availability and data consistency guarantee capability of the system are improved, the transaction is flexibly routed or intercepted in different modes, the seamless switching and data migration in the case of abnormal master database are ensured, the data inconsistency problem caused by concurrent modification is avoided, the mapping relationship is recorded through the abnormal routing table, the routing traceability and recovery capability are enhanced, and the system stability and business continuity are improved as a whole.

[0091] Based on the first embodiment of the application, the same or similar contents as the above embodiment one can be referred to the above introduction, and will not be described in detail hereinafter. On this basis, when the mode type is the data migration mode, the abnormal routing data in the standby database is migrated to the master database; the data of the migrated master database is checked, if the checking result is migration success, the abnormal routing data in the standby database is deleted, and the data migration mode is changed to the normal routing mode.

[0092] It should be noted that in the data migration mode, the transaction request routing device starts the data migration task, extracts all data records marked as “abnormal routing” from DB_DIV2, and synchronizes these records to DB_DIV1 through log transmission service or direct writing. The DB_DIV1 after migration is checked in detail, including but not limited to the number of data entries, the accuracy of field values, etc. It is confirmed that all abnormal routing data has been successfully migrated without any omission or error. If the data checking result is migration success, the abnormal routing data in DB_DIV2 that has been successfully migrated is deleted, the storage space is released and the redundant information is reduced, and the data migration mode (D mode) is switched back to the normal routing mode (A mode), ensuring the high availability and data consistency of the system during the data migration process.

[0093] In a feasible implementation, the different mode types are converted based on preset rules.

[0094] It should be noted that the current mode type of the master database is fixedly converted according to the preset rules, i.e. converted in the order of A, B, C, and D, and will not be switched from A to C\D directly, nor will it be switched from B back to A directly. This mode conversion mechanism strictly following the preset rules not only ensures that the transaction request routing device can quickly respond and resume normal operation when encountering a fault, but also ensures the safety and integrity during the data migration process, for reference Figure 9 , Figure 9 A routing mode flow chart is provided.

[0095] In this embodiment, through strict data checking and cleaning mechanism, the risk of data inconsistency is avoided, and finally the smooth transition from the fault recovery state to the normal running state is realized, and the stability and business continuity of the overall system are improved.

[0096] The application also provides a transaction request routing device, please refer to Figure 10 , the transaction request routing device comprises:

[0097] The response module 10 is configured to obtain attribute information of a transaction card corresponding to the transaction request in response to the transaction request.

[0098] The determination module 20 is configured to determine a mode type of a master database in a data sub-library corresponding to the attribute information.

[0099] The judgment module 30 is configured to determine a transaction type corresponding to the transaction request.

[0100] The routing module 40 is configured to determine a target database from the data sub-library based on the mode type and the transaction type, and route the transaction request to the target database.

[0101] Optionally, the routing module comprises:

[0102] The routing submodule is configured to, if the mode type is a normal routing mode, direct the transaction request to the master database; if the mode type is a backup library switching mode, forward the transaction request to the backup database, and record a mapping relationship between the transaction request and the backup database in an abnormal routing table; and if the mode type is any one of a back switching mode and a data migration mode, route the transaction request to a corresponding database based on the transaction type.

[0103] Optionally, different mode types are converted based on a preset rule.

[0104] Optionally, the routing submodule comprises:

[0105] The back switching mode routing unit is configured to, if the mode type is the back switching mode and the transaction type is an original transaction, direct the transaction request to the master database; and if the mode type is the back switching mode and the transaction type is a subsequent transaction, forward the transaction request to a database corresponding to an original transaction request of the transaction request.

[0106] The data migration mode routing unit is configured to, if the mode type is the data migration mode and the transaction type is the original type transaction, direct route the transaction request to the master database; if the mode type is the data migration mode and the transaction type is the subsequent type transaction, determine whether an original type transaction request of the transaction request is recorded in the abnormal routing table, and if recorded in the abnormal routing table, intercept the transaction request.

[0107] Optionally, when the mode type is the data migration mode, the abnormal routing data in the standby database is migrated to the master database; the master database after migration is checked, and if the checking result is that the migration is successful, the abnormal routing data in the standby database is deleted, and the data migration mode is changed to a normal routing mode.

[0108] The transaction request routing device provided by the present application adopts the transaction request processing method in the above embodiments, and can solve the technical problem of transaction request routing. Compared with the prior art, the transaction request routing device provided by the present application has the same beneficial effects as the transaction request processing method provided by the above embodiments, and other technical features in the transaction request routing device are the same as the features disclosed in the above embodiments, which will not be repeated here.

[0109] The present application provides a transaction request routing device, which comprises at least one processor and a memory connected with the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the transaction request processing method in the above embodiment one.

[0110] Reference will be made to the following description of the embodiments of the present application Figure 11 which shows a structural schematic diagram of a transaction request routing device suitable for implementing the embodiments of the present application. The transaction request routing device in the embodiments of the present application can include but is not limited to mobile terminals such as mobile phones, notebook computers, tablet computers, digital broadcast receivers, PDAs (Personal Digital Assistant), PMPs (Portable Media Player), vehicle-mounted terminals (such as vehicle-mounted navigation terminals), and the like, and fixed terminals such as digital TVs, desktop computers, and the like. Figure 11 The transaction request routing device shown is only an example, and should not bring any limitation to the functions and use range of the embodiments of the present application.

[0111] As Figure 11As shown, the transaction request routing device can include a processing apparatus 1001 (e.g., a central processing unit, a graphics processing unit, etc.) that can perform various appropriate actions and processes according to programs stored in a read only memory (ROM) 1002 or loaded from a storage apparatus 1003 into a random access memory (RAM) 1004. Various programs and data required for operation of the transaction request routing device are also stored in the RAM 1004. The processing apparatus 1001, the ROM 1002, and the RAM 1004 are connected to each other through a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Generally, the following systems can be connected to the I / O interface 1006: input apparatuses 1007 including, for example, a touch screen, a touch pad, a keyboard, a mouse, an image sensor, a microphone, an accelerometer, a gyroscope, etc.; output apparatuses 1008 including, for example, a liquid crystal display (LCD), a speaker, a vibrator, etc.; the storage apparatus 1003 including, for example, a magnetic tape, a hard disk, etc.; and a communication apparatus 1009. The communication apparatus 1009 can allow the transaction request routing device to communicate with other devices wirelessly or by wire to exchange data. Although the transaction request routing device with various systems is shown in the figure, it should be understood that all the shown systems are not required to be implemented or possessed. More or less systems can be alternatively implemented or possessed.

[0112] In particular, according to embodiments of the present disclosure, the processes described above with reference to the flowcharts can be implemented as a computer software program. For example, embodiments of the present disclosure include a computer program product comprising a computer program carried on a computer readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network by the communication apparatus, or installed from the storage apparatus 1003, or installed from the ROM 1002. When the computer program is executed by the processing apparatus 1001, the above-mentioned functions defined in the methods of embodiments of the present disclosure are performed.

[0113] The transaction request routing device provided by the present disclosure adopts the transaction request processing method in the above-mentioned embodiments, and can solve the technical problem of transaction request routing. Compared with the prior art, the transaction request routing device provided by the present disclosure has the same beneficial effects as the transaction request processing method provided by the above-mentioned embodiments, and other technical features in the transaction request routing device are the same as the features disclosed in the previous embodiment method, which will not be repeated here.

[0114] It should be understood that various aspects of the disclosure can be implemented in hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials or characteristics can be combined in any appropriate manner in any one or more embodiments or examples.

[0115] The above description is merely illustrative of the application and is not intended to limit the scope of the application. Any variations and modifications that can be made by any person skilled in the art within the spirit and scope of the application are intended to be encompassed by the application. Therefore, the scope of the application should be determined by the appended claims.

[0116] The application provides a computer readable storage medium having stored thereon computer readable program instructions (i.e., a computer program) for performing the transaction request processing method in the above embodiments.

[0117] The computer readable storage medium provided by the application may, for example, be a U disk, but is not limited to an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, system, or device, or any combination thereof. More specific examples of the computer readable storage medium can include, but are not limited to, an electrical connection having one or more conductive wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any appropriate combination of the above. In the present embodiment, the computer readable storage medium can be any tangible medium that contains or stores a program that can be used by or in conjunction with an instruction execution system, system, or device. The program code contained on the computer readable storage medium can be transmitted in any appropriate medium, including but not limited to an electrical wire, an optical cable, an RF (Radio Frequency) cable, etc., or any appropriate combination thereof.

[0118] The above computer readable storage medium can be included in the transaction request routing device; or can exist separately and not be assembled into the transaction request routing device.

[0119] The computer readable storage medium carries one or more programs, when the one or more programs are executed by the transaction request routing device, the transaction request routing device is caused to: acquire attribute information of a transaction card corresponding to a transaction request in response to the transaction request; determine a mode type of a master database in a data sub-library corresponding to the attribute information; determine a transaction type corresponding to the transaction request; determine a target database from the data sub-library based on the mode type and the transaction type, and route the transaction request to the target database.

[0120] Computer program code for carrying out operations of the present application can be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (for example, through the Internet using an Internet Service Provider).

[0121] The flow diagrams and the block diagrams in the drawings are illustrations of architectures, functionalities, and operations of possible implementations of systems, methods, and computer program products according to various embodiments of present application. In this regard, each block in the flow diagrams or block diagrams can represent a module, a procedure, or a part of code, which comprises one or more executable instructions for implementing the specified functions. It should also be noted that, in some alternative implementations, the functions noted in the blocks can occur in a different order than that noted in the figures. For example, two blocks noted in succession can in fact be executed substantially concurrently or in the opposite order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flow diagrams, and combinations of blocks in the block diagrams and / or flow diagrams, can be implemented by dedicated hardware-based systems that perform the specified functions or operations, or can be implemented by a combination of dedicated hardware-based systems and computer instructions.

[0122] The modules involved in the embodiments of the present application can be implemented in a software manner or in a hardware manner. In some cases, the name of the module does not constitute a limitation on the module itself.

[0123] The readable storage medium provided by the present application is a computer readable storage medium, which stores computer readable program instructions (i.e. computer program) for executing the transaction request processing method described above, and can solve the technical problem of transaction request routing. Compared with the prior art, the computer readable storage medium provided by the present application has the same beneficial effects as the transaction request processing method provided by the above-mentioned embodiments, which will not be repeated here.

[0124] The present application also provides a computer program product, comprising a computer program, which, when executed by a processor, implements the steps of the transaction request processing method as described above.

[0125] The computer program product provided by the present application can solve the technical problem of transaction request routing. Compared with the prior art, the computer program product provided by the present application has the same beneficial effects as the transaction request processing method provided by the above-mentioned embodiments, which will not be repeated here.

[0126] The above-mentioned is only part of the embodiments of the present application, and does not limit the patent scope of the present application. Any equivalent structural transformation, direct / indirect application in other related technical fields based on the technical concept of the present application, and the content of the specification and drawings are included in the patent protection scope of the present application.

Claims

1. A transaction request processing method, characterized in that: The transaction request processing method includes: In response to a transaction request, obtaining attribute information of a transaction card corresponding to the transaction request; Determining the schema type of the main database in the data sub-database corresponding to the attribute information; Determining a transaction type corresponding to the transaction request; Based on the schema type and the transaction type, a target database is determined from the data sub-database, and the transaction request is routed to the target database.

2. The transaction request processing method according to claim 1, wherein: The data sub-library includes the primary database and the standby database. The step of determining a target database from the data sub-library based on the schema type and the transaction type and routing the transaction request to the target database includes: If the mode type is a normal routing mode, the transaction request is directed and routed to the primary database; If the mode type is the standby database switching mode, forwarding the transaction request to the standby database, and recording the mapping relationship between the transaction request and the standby database in the abnormal routing table; If the mode type is any one of the switchback mode and the data migration mode, the transaction request is routed to the corresponding database based on the transaction type.

3. The transaction request processing method according to claim 1, wherein: The different mode types are converted based on preset rules.

4. The transaction request processing method according to claim 2, wherein: If the mode type is any one of the switchback mode and the data migration mode, the step of routing the transaction request to the corresponding database based on the transaction type includes: If the mode type is the switchback mode and the transaction type is the original transaction, the transaction request is directed and routed to the primary database; If the mode type is the switchback mode and the transaction type is a subsequent transaction, the transaction request is forwarded to a database corresponding to an original transaction request of the transaction request.

5. The transaction request processing method according to claim 4, wherein: If the mode type is any one of the switchback mode and the data migration mode, the step of routing the transaction request to the corresponding database based on the transaction type further includes: If the mode type is the data migration mode and the transaction type is the original transaction, the transaction request is directed and routed to the primary database; If the mode type is the data migration mode and the transaction type is the subsequent type transaction, it is determined whether the original type transaction request of the transaction request is recorded in the abnormal routing table. If it is recorded in the abnormal routing table, the transaction request is intercepted.

6. The transaction request processing method according to claim 5, wherein: When the mode type is the data migration mode, the abnormal routing data in the standby database is migrated to the primary database; data verification is performed on the transplanted primary database. If the verification result shows that the transplant is successful, the abnormal routing data in the standby database is deleted, and the data migration mode is changed to a normal routing mode.

7. A transaction request routing device, characterized in that: The device comprises: a response module, configured to respond to a transaction request and obtain attribute information of a transaction card corresponding to the transaction request; A determination module, configured to determine a schema type of a primary database in a data sub-database corresponding to the attribute information; A determination module, configured to determine a transaction type corresponding to the transaction request; A routing module is used to determine a target database from the data sub-database based on the mode type and the transaction type, and to route the transaction request to the target database.

8. A transaction request routing device, characterized in that: The device comprises: a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the computer program is configured to implement the steps of the transaction request processing method according to any one of claims 1 to 6.

9. A storage medium, characterized in that: The storage medium is a computer-readable storage medium, and a computer program is stored on the storage medium. When the computer program is executed by a processor, the steps of the transaction request processing method according to any one of claims 1 to 6 are implemented.

10. A computer program product, characterized in that The computer program product comprises a computer program, and when the computer program is executed by a processor, the steps of the transaction request processing method according to any one of claims 1 to 6 are implemented.

Images