Transaction front-end processor failover method and device

Abstract

The invention relates to the technical field of financial transactions, in particular to a transaction front-end processor failover method and device, and the method comprises the following steps: a cluster management service monitors the state of a front node on a ZK cluster; when the front-end node session is in a free state, the cluster management service changes the state of the session in the online transaction front-end processor through message driving; the transaction API is reconnected to the online transaction front-end processor, and a subscription instruction a is sent; the online transaction front-end processor refreshes the push stream file according to the subscription instruction a; when the front-end node session is in a failure state, the transaction API is connected to an online transaction front-end processor, and a subscription instruction b is sent; and recovering the transaction of the context, and performing data refreshing of the transaction private stream. According to the method, the transaction API is used for registering a plurality of front-end processors, and a complete session state is maintained, so that the consistency of transaction contexts and subscription instructions of the transaction API are ensured, the transaction contexts are quickly recovered, and the average fault-free time and the reliability of a transaction system are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of financial transaction, in particular to a method and device for transaction front-end processor failover. BACKGROUND

[0002] A financial transaction system is generally composed of a transaction terminal, an access module, an authentication module, a core module, and a bid module. The access module generally includes a transaction API and a transaction front-end processor. The transaction API provides a set of SDK interfaces for transaction and inquiry to the transaction terminal, facilitating customers to enter instructions through the transaction terminal. The transaction front-end processor serves as a channel for the customers to perform financial transaction operations, receives terminal transaction instructions, checks the legality of basic business, converts protocols, forwards instructions to the core or other systems, and pushes the returns and response messages of the transaction market to the transaction API for display on the transaction terminal. Therefore, providing a highly available transaction front-end processor is a necessary condition for ensuring the normal operation of the transaction system. In the prior art, when the transaction front-end processor fails, it cannot quickly perform failover and system recovery, and when switching to an available front-end processor, it is difficult to quickly restore the context before the transaction, resulting in disconnection of the transaction terminal connected to the front-end processor and failure to enter transaction instructions. In view of the above problems, the present application provides a method and device for transaction front-end processor failover to solve the above problems. SUMMARY

[0003] The main purpose of the present application is to provide a method and device for transaction front-end processor failover to solve the problems in the related art.

[0004] In order to achieve the above purpose, according to one aspect of the present application, a method for transaction front-end processor failover is provided, comprising the following steps: S1: the transaction front-end processor registers a node on a ZK cluster, and a cluster management service monitors the state of the front-end node on the ZK cluster; S2: when the session of the front-end node is in a free state, the cluster management service changes the state of the session in the online transaction front-end processor through message driving; S3: the transaction API reconnects to the online transaction front-end processor and sends a subscription instruction a; S4: the online transaction front-end processor refreshes the push stream file according to the subscription instruction a; S5: when the session of the front-end node is invalid, the cluster management service sets the front-end node to an invalid state; S6: the transaction API connects to the online transaction front-end processor and sends a subscription instruction b; S7: the online transaction front-end processor recovers the transaction context and performs data refresh of the transaction private stream according to the subscription instruction b.

[0005] Further, the specific steps of S1 are as follows: S11: The transaction front-end machine connects the ZK cluster when starting, and registers the node; S12: The cluster management service obtains the front-end node and updates the front-end node list state; S13: The transaction front-end machine updates the front-end session table in real time.

[0006] Further, the state of the front-end node includes an online state, a free state, and an invalid state, the online state can be changed to the online state by partial disconnection or new connection binding, the online state becomes the free state by full disconnection, the free state becomes the online state by new connection binding, the free state becomes the invalid state by timeout expiration, and the online state becomes the invalid state by automatic exit.

[0007] Further, the steps of judging that the front-end node session is in the free state in S2 are as follows: S21: The transaction front-end machine reports the instruction of invalidation of the session channel to the cluster management service; S22: The cluster management service deletes the current session channel record; S23: The session state of the front-end node is updated to the free state.

[0008] Further, the steps of changing the state of the session in the online front-end machine by the cluster management service through message driving in S2 are as follows: S24: Whether the free state of the session is expired by timeout is checked; S25: If the session is not expired by timeout, the transaction API reconnects, and the state of the front-end node is changed from the free state to the online state; S26: If the session is expired by timeout, the session is invalid, and the state of the front-end node is changed from the free state to the invalid state.

[0009] Further, the transaction API includes two channels, one channel is used for transaction instructions, and the other channel is used for user query instructions.

[0010] Further, the specific steps of S5 are as follows: S51: The transaction front-end machine crashes, and is disconnected with the ZK cluster and the transaction API; S52: The ZK cluster monitors that the front-end node is invalid, and sends to the cluster management service; S53: The cluster management service deletes all session channel records of the front-end node; S54: The session of the front-end node is set to the free state; S55: The session keep-alive monitoring is expired, the free state is expired by timeout, and the session of the front-end node is set to the invalid state.

[0011] Further, the step of recovering the context of the transaction in S7 is as follows: S71: The cluster management service sends a session invalidation notification to the business core; S72: The business core updates the session table and sends the session table to other online transaction front-end machines; S73: Other online transaction front-end machines update the session table related records.

[0012] Further, the step of updating the session table related records by other online transaction front-end machines in S73 is based on the access of the transaction front-end machines to the distributed bus in a multi-active manner, and the distributed bus guarantees the synchronization and consistency of the downlink messages of multiple front-end machines.

[0013] The application provides a transaction front-end machine failover device, which comprises a transaction front-end machine, a cluster management service and a business core.

[0014] Compared with the prior art, the application has the following beneficial effects: The application registers multiple front-end machines by using a transaction API, and when a fault occurs, the complete session state is maintained through the driving of messages between the cluster management service and online front-end machines, so that the consistency of the transaction context is guaranteed. BRIEF DESCRIPTION OF DRAWINGS

[0015] Fig. 1 The application provides a method flowchart.

[0016] Fig. 2 The application provides an overall framework diagram.

[0017] Fig. 3 The application provides a session state transition diagram. DETAILED DESCRIPTION

[0018] In order to further illustrate the technical means and effects taken by the present application to achieve the predetermined object, the specific embodiments, structures, features and effects according to the present application are described in detail below in conjunction with the drawings and preferred embodiments.

[0019] With reference to Figs. 1-3 , a transaction front-end machine failover method is provided, comprising the following steps: S1: the transaction front-end machine registers a node on a ZK cluster, and a cluster management service monitors the state of the front-end node on the ZK cluster; S2: when the front-end node session is in a free state, the cluster management service changes the state of the session in the online transaction front-end machine through message driving; S3: the transaction API reconnects to the online transaction front-end machine and sends a subscription instruction a; S4: the online transaction front-end machine refreshes the push stream file according to the subscription instruction a; S5: when the front-end node session is invalid, the cluster management service sets the front-end node to an invalid state; S6: the transaction API connects to the online transaction front-end machine and sends a subscription instruction b; S7: the online transaction front-end machine recovers the context transaction and performs data refresh of the transaction private stream according to the subscription instruction b.

[0020] The specific steps of S1 are as follows: S11: the transaction front-end machine connects the ZK cluster and registers a node when starting; S12: the cluster management service obtains the front-end node and updates the front-end node list state; S13: the transaction front-end machine updates the front-end session table in real time.

[0021] The state of the front-end node includes an online state, a free state and an invalid state, the online state can be changed to the online state by partial disconnection or new connection binding, the online state becomes the free state by complete disconnection, the free state becomes the online state by new connection binding, the free state becomes the invalid state by timeout expiration, and the online state becomes the invalid state by automatic exit.

[0022] The step of judging that the front-end node session is in the free state in S2 is as follows: S21: the transaction front-end machine reports a session channel invalidity instruction to the cluster management service; S22: the cluster management service deletes the current session channel record; S23: the session state of the front-end node is updated to the free state.

[0023] The step of changing the state of the session in the online front-end machine by the cluster management service through message driving in S2 is as follows: S24: Check whether the free state of the session is expired; S25: If the session is not expired, the transaction API reconnects, and the state of the front-end node changes from the free state to the online state. S26: If the session is expired, the session is invalidated, and the front-end node changes from the free state to the invalid state.

[0024] The transaction API includes two channels, one for transaction instructions and the other for user query instructions.

[0025] The specific steps of S5 are as follows: S51: The transaction front-end crashes and is disconnected from the ZK cluster and the transaction API. S52: The ZK cluster monitors the invalidation of the front-end node and sends it to the cluster management service. S53: The cluster management service deletes all session channel records of the front-end node. S54: The session of the front-end node is set to the free state. S55: The session keep-alive monitoring period expires, the free state is expired, and the session of the front-end node is set to the invalid state.

[0026] The steps of the transaction of recovering the context in S7 are as follows: S71: The cluster management service sends a notification of session invalidation to the business core. S72: The business core updates the session table and sends the session table to other online transaction front-ends. S73: Other online transaction front-ends update the session table related records.

[0027] The other online transaction front-ends update the session table related records in S73 based on the access of the transaction front-ends to the distributed bus in a multi-active manner, and the distributed bus guarantees the synchronization and consistency of the downlink messages of multiple front-ends.

[0028] The device for failover of a transaction front-end includes a transaction front-end, a cluster management service, and a business core. The transaction front-end is used to synchronize a session table, provide static data and dynamic data of a transaction, and the cluster management service is used to acquire the switching of the online and offline states of the transaction front-ends in real time and maintain the state of a unified session on the transaction front-end cluster. The business core is used to manage the login and logout processes, process session related data, update the session state, and then synchronize messages to each transaction front-end.

[0029] In the embodiment, mainly includes transaction front-end machine, cluster management service, ZK cluster, transaction API and business core, wherein the transaction front-end machine accesses to the distributed bus in the multi-active manner, the distributed bus is a message middleware interface library based on reliable multicast, which can guarantee the reliability and order of messages, and can guarantee the consistency of messages accessing the same group on the bus. For example, front-end machine 1 and front-end machine 2 access the bus in the same group, so that the message sent by the transaction core to the front-end can be received by all nodes in the front-end group, and the message is consistent. The message on the bus can be set to be persistent, so that the message receiver can retrieve the message from the hard disk in case of failure. The bus guarantees the synchronization and consistency of the downlink messages of multiple front-end machines, and the front-end machine constructs the business data cache of the front-end machine according to the received bus message. The business data can be abstracted as multiple business tables and table associations. In order to meet the real-time characteristics of the transaction system, the data is generally cached in the memory of the front-end machine in the form of memory data. In addition, from the perspective of the transaction terminal, these data are divided by customers, and the channels for different customers to interact with the transaction front-end machine can be abstracted as sessions. In this way, the transaction context corresponding to the current customer can be associated by indexing the session. The multi-active front-end machine needs to maintain the data consistency of the session and the transaction context.

[0030] The cluster management service can obtain the switching of the online and offline states of the front-end machine in real time, and maintain the state of the unified session on the front-end machine cluster. Here, the front-end cluster unified session information is notified to the cluster management service through event driving and message driving, and the cluster management service synchronizes the session state to the authentication module through the bus message. When a front-end machine fails, the transaction terminal connected to the front-end machine can quickly switch to other available front-end machine, and reuse the previous session and the transaction context associated with the session. This mechanism can effectively reduce the probability of re-login of the transaction terminal, optimize the transaction experience of the transaction terminal, and on the other hand, ensure the quick recovery of the transaction context in case of failure, and improve the average failure-free time of the system.

[0031] The ZK cluster is a distributed coordinator, and the transaction front-end machine registers a node on the ZK cluster when starting. The cluster management service monitors the online and offline states of the front-end node on the ZK, which is used to quickly recover the unexpired session and transaction context when the front-end fails.

[0032] The transaction API runs on the client, and interacts with the transaction front-end through the network. Generally, the transaction API establishes two channels, reuses a session, one channel is used for transaction instructions, and the other channel is used for user query instructions.

[0033] The business core is used to manage the login and logout process, process the session related data, update the session state, and then synchronize the message to each transaction front-end machine.

[0034] The specific method is as follows: First, after the user successfully logs in, the transaction front-end machine starts, which will connect to the ZK cluster, register the node, and the cluster management service monitors and updates the state of the front-end node on the ZK cluster. The transaction front-end machine also updates the front-end session table in real time. The state of the front-end node includes an online state, a free state, and an invalid state. The online state is that after the user successfully logs in, the authentication core creates a session and a corresponding session token, and synchronizes them to the front-end machine. The free state is that there are multiple channels in a session between the user and the front-end machine, and all channels are closed on the physical connection. The session enters the free state. The invalid state includes that the user logs out of the front-end machine, which will make the session invalid, and the user is in the free state and reaches the timeout expiration. Further, the online state part is disconnected or newly connected and bound, which can become the online state. The online state is all disconnected and becomes the free state. The free state is newly connected and bound, which becomes the online state. The free state is expired and becomes the invalid state. The online state automatically exits and becomes the invalid state.

[0035] The failure of the front-end node is divided into two cases. The first case is that the node is in the free state, and the second case is that the node is in the invalid state. The invalid state is also divided into two cases. The first case is that the free state is automatically determined to be invalid due to timeout expiration, and the second case is that the transaction front-end machine crashes directly into the invalid state.

[0036] When the front-end node session is in the free state, the transaction front-end machine reports the session channel invalidation instruction to the cluster management service. The cluster management service deletes the current session channel record. The session state of the front-end node is updated to the free state. The free state of the session is checked for timeout expiration. If the session is not expired, the transaction API will reconnect, and the state of the front-end node will change from the free state to the online state. The transaction API reconnects to the online transaction front-end machine and sends a subscription instruction a. The online transaction front-end machine refreshes the push stream file according to the subscription instruction a. If the session is expired, the session is invalid, and the front-end node changes from the free state to the invalid state. The cluster management service sends a session expiration notification to the business core. The business core updates the session table and synchronizes the session table to all online front-end machines for reconnection.

[0037] When the current pre-node session is invalid, the transaction pre-machine crashes, and is disconnected from the ZK cluster and the transaction API; the ZK cluster monitors the pre-node invalidity and sends it to the cluster management service; the cluster management service deletes all session channel records of the pre-node; the session of the pre-node is set to a free state; the session keep-alive monitoring expires, the free state times out, and the session of the pre-node is set to an invalid state; the cluster management service sends a session invalidity notification to the business core; the business core updates the session table and sends the session table to other online transaction pre-machines; the other online transaction pre-machines update the session table related records, and the online pre-machines naturally retain the transaction information consistent with the fault pre-machine before the failure. When the transaction terminal reconnects to the online pre-machine, such transaction memory data information is self-consistent and does not need additional recovery, and the state information of the session actually needs to be recovered. The transaction API is connected to the online transaction pre-machine, and a subscription instruction b is sent; the online transaction pre-machine recovers the context transaction according to the subscription instruction b, and performs data refreshing of the transaction private stream. The transaction private stream information is that, for a transaction terminal, after a certain investor logs in, a series of transaction operations are performed, and private messages such as self-entrustment returns and transaction returns are received. The order of these messages is ordered, and when the transaction terminal is used by the current transaction day to log in to another machine or network, the same transaction private stream before is expected to be received, and it is required that no data is lost and no out-of-order occurs. When a pre-machine fails and the transaction API is connected to the online pre-machine, the subscription instruction is sent, at this time, the online pre-machine drives the refreshing of the data of the transaction private stream according to the bus message stream, and finally ensures the consistency of the serial number of the private stream data.

[0038] The above is only a preferred embodiment of the present application, and does not limit the present application in any form. Although the present application has been disclosed as above, it is not intended to limit the present application. Any person skilled in the art can make slight changes or modifications to the above disclosed technical content to obtain equivalent embodiments with equivalent changes, without departing from the technical solution of the present application. Any modification, change, equivalent change and modification of the above embodiments, which does not depart from the technical solution of the present application, is still within the scope of the present application.

Claims

1. A method for failover of a transaction front-end server, characterized in that, Includes the following steps: S1: The transaction front-end machine registers nodes on the ZK cluster, and the cluster management service monitors the status of the front-end nodes on the ZK cluster; S2: When the front-end node session is in a detached state, the cluster management service changes the state of the session in the online transaction front-end machine through message-driven mechanisms. S3: The trading API reconnects to the online trading front-end and sends subscription instruction a; S4: The online transaction front-end refreshes the push stream file according to the subscription instruction a; S5: When the session of the front-end node fails, the cluster management service sets the front-end node to an invalid state; S6: The trading API connects to the online trading front-end and sends subscription instruction b; S7: The online transaction front-end machine restores the context of the transaction according to the subscription instruction b and refreshes the data of the private transaction stream.

2. The method for failover of the transaction front-end server according to claim 1, characterized in that, The specific steps of S1 are as follows: S11: When the transaction front-end machine starts up, it connects to the ZK cluster and registers nodes; S12: The cluster management service will obtain the front node and update the status of the front node list; S13: The transaction front-end server updates the front-end session table in real time.

3. The method for failover of the transaction front-end server according to claim 1, characterized in that, The states of the front-end nodes include online state, detached state, and invalid state. The online state can be changed to online state if some disconnection occurs or a new connection is bound. The online state can be changed to detached state if all disconnection occurs. The detached state can be changed to online state if a new connection is bound. The detached state can be changed to invalid state if it times out. The online state can be changed to invalid state if it automatically exits.

4. The method for failover of the transaction front-end server according to claim 1, characterized in that, The steps in S2 to determine whether the preceding node session is in a detached state are as follows: S21: The instruction from the transaction front-end machine to report the session channel failure to the cluster management service; S22: The cluster management service deletes the current session channel record; S23: Update the session state of the preceding node to a detached state.

5. The method for failover of the transaction front-end server according to claim 1, characterized in that, The cluster management service in S2 changes the state of sessions in the online front-end machine via message-driven mechanisms as follows: S24: Check if the detached state of the session has timed out; S25: If the session has not expired, the transaction API will reconnect and change the status of the front node from detached to online. S26: If the session expires, the session becomes invalid, and the preceding node changes from a detached state to an invalid state.

6. The method for failover of the transaction front-end server according to claim 5, characterized in that, The transaction API includes two channels: one for transaction instructions and the other for user query instructions.

7. The method for failover of the transaction front-end server according to claim 1, characterized in that, The specific steps of S5 are as follows: S51: The transaction front-end server crashed, losing connection with the ZK cluster and transaction API; S52: The ZK cluster detects the failure of the front-end node and sends the information to the cluster management service; S53: The cluster management service deletes all session channel records of the front-end node; S54: Set the session of the preceding node to a detached state; S55: Session keep-alive monitoring expired, detached state timed out, set the previous node session to invalid state.

8. The method for failover of the transaction front-end server according to claim 1, characterized in that, The steps for restoring the context of a transaction in S7 are as follows: S71: The cluster management service sends a session expiration notification to the business core; S72: The business core updates the session table and sends the session table to other online transaction front-end machines; S73: Update session table related records for other online transaction front-end machines.

9. The method for failover of the transaction front-end server according to claim 7, characterized in that, In S73, other online transaction front-end machines update session table records based on the transaction front-end machines accessing the distributed bus in a multi-active manner. The distributed bus ensures the synchronization and consistency of downlink messages from multiple front-end machines.

10. An apparatus for failover of a transaction front-end server, comprising a transaction front-end server, a cluster management service, and a business core, and a method for failover of a transaction front-end server based on any one of claims 1-9, characterized in that: The transaction front-end server is used to synchronize the session table, providing static and dynamic data for transactions; the cluster management service is used to obtain the online / offline status switching of the transaction front-end server in real time, and maintain the status of the unified session on the transaction front-end server cluster; the business core is used to manage the login / logout process, process session-related data, update the session status, and then synchronize the messages to each transaction front-end server.

Images