CN117675443A

CN117675443A - Method, device, equipment, medium and product for erecting FIX gateway cluster

Info

Publication number: CN117675443A
Application number: CN202211046372.9A
Authority: CN
Inventors: 王安全; 杨昊
Original assignee: Hunan Weibu Information Technology Co ltd
Current assignee: Hunan Weibu Information Technology Co ltd
Priority date: 2022-08-30
Filing date: 2022-08-30
Publication date: 2024-03-08

Abstract

The disclosure relates to a method, a device, equipment, a medium and a product for erecting a FIX gateway cluster, comprising: selecting a Leader node from a plurality of Raft nodes of the FIX gateway cluster based on a Raft protocol, wherein the Raft node comprises three node states of a Leader node, a follow node and a Candidate node; and establishing FIX Session connection between the Leader node and the opposite terminal, sending or receiving messages to the opposite terminal through the Leader node and the FIX Session, and storing the FIX Session state change after the messages are sent or received to the opposite terminal by the Leader node in a plurality of Raft nodes based on a Raft protocol. The distributed consensus mechanism based on the Raft protocol solves the problems of selection of Leader nodes and reliable storage of FIX Session states in the FIX gateway cluster.

Description

Method, device, equipment, medium and product for erecting FIX gateway cluster

Technical Field

The disclosure relates to the technical field of gateway clusters, and in particular relates to a method, a device, equipment, a medium and a product for erecting a FIX gateway cluster.

Background

In financial transactions, the FIX protocol is often used to exchange financial information with upstream and downstream external systems, so how to build a high-availability FIX gateway cluster supporting FIX message transmission is a problem encountered by many internet financial companies.

In the prior art, due to the limitation of the FIX protocol, all information transmission must depend on a stateful long connection, and at least 2 types of middleware are needed to be relied on in the process of a common FIX gateway cluster, wherein one is used for selecting a Leader node, and the other is used for storing the FIX long connection state. However, this causes a new problem, and the reliability of FIX gateway clusters inevitably depends on the reliability of the dependent middleware, resulting in a barrel effect.

Disclosure of Invention

In order to overcome the problems in the related art, the present disclosure provides a method, an apparatus, a device, a medium, and a product for erecting a FIX gateway cluster.

According to a first aspect of an embodiment of the present disclosure, there is provided a method for erecting a FIX gateway cluster, including:

selecting a Leader node from a plurality of Raft nodes of the FIX gateway cluster based on a Raft protocol, wherein the Raft node comprises three node states of a Leader node, a follow node and a Candidate node;

and establishing FIX Session connection between the Leader node and the opposite terminal, sending or receiving information to the opposite terminal through the Leader node and the FIX Session, and storing the FIX Session state change after the information is sent or received to the opposite terminal by the Leader node in a plurality of Raft nodes based on a Raft protocol.

In some embodiments, a Leader node is elected from multiple Raft nodes in the FIX gateway cluster based on a Raft protocol, where the Raft node includes three node states including a Leader node, a follow node, and a Candidate node, including:

sending requests which become Leader nodes to other Raft nodes in the cluster through the Raft nodes with the Candida node state, and changing the Raft nodes with the Candida node state into the Leader node state when the other Raft nodes in the cluster recognize that the number of the requests exceeds a first preset value;

if the Candidate node is not successfully changed into a Leader node and a Leader node exists in the cluster, changing the Candidate node state into a follow node state;

if the Leader node is not found, the Candidate node continuously sends a request for becoming the Leader node until the Leader node becomes a Leader state or the Leader node state existing in the cluster is found.

In some embodiments, a FIX Session connection is established between the Leader node and the opposite terminal, a message is sent or received to the opposite terminal through the Leader node and the FIX Session, and a FIX Session state change after the message is sent or received to the opposite terminal by the Leader node is saved in a plurality of Raft nodes based on a Raft protocol, including:

the messages sent to the opposite terminal through the Leader node and the FIX Session comprise ordering and removing single user request messages;

and the messages received to the opposite terminal through the Leader node and the FIX Session comprise order confirmation and transaction type messages.

Further, the messages sent to the opposite terminal through the header node and the FIX Session include a list ordering and list removing user request message, including:

s1, the Leader node receives a request for sending a FIX message, converts the request on a service into the FIX message and locks the inside of the Leader node to generate an incremental FIX message sequence number;

s2, the Leader node sends a FIX message sending request to the rest of the Lift nodes with the Follower node state;

s3, after receiving the FIX message sending request, the Raft node with the Follower node state processes the information in the Raft node, stores the latest state of the FIX Session to the local disk of each Raft node after the processing is finished, and sends a confirmation message to the Leader node;

and S4, after receiving the confirmation message exceeding the first preset value, the Leader node sends the FIX message to the opposite terminal through the FIX Session.

In some embodiments, the message received to the opposite end through the Leader node and the FIX Session includes an order confirmation, a transaction type message, including:

s1, the Leader node receives a FIX message sent by an opposite terminal from a FIX Session;

s2, converting the received FIX message format which cannot be identified into a message format identified by a service party, and delivering the message format to internal business services in a HTTP or message queue mode;

s3, after the header node completes the delivery of the message, the header node sends a FIX Incoming message processing request to a Raft node with a Follower node state.

S4, after the Lift node with the Follower node state receives the FIX Incoming message processing request, processing is carried out inside the lift node, after the processing is finished, the latest state of the FIX Session is stored in the local disk of each lift node, and a confirmation message is sent to the Leader node.

And S5, after receiving the confirmation message exceeding the first preset value, the Leader node confirms that the FIX Session state change is successful, and the processing is ended.

In some embodiments, the plurality of Raft nodes includes at least 3, and the plurality of Raft nodes are interconnected.

According to a second aspect of the embodiments of the present disclosure, there is provided an erection device of a FIX gateway cluster, including:

the selection module is used for selecting a Leader node from a plurality of Raft nodes of the FIX gateway cluster based on a Raft protocol, wherein the Raft node comprises three node states of a Leader node, a follow node and a Candidate node;

and the storage module is used for establishing FIX Session connection with the opposite terminal based on the Leader node, sending or receiving messages to the opposite terminal through the Leader node and the FIX Session, and storing the FIX Session state change after the messages are sent or received to the opposite terminal by the Leader node in a plurality of Raft nodes based on a Raft protocol.

An embodiment of the third aspect of the present application provides an electronic device, including a processor and a memory, where the memory stores at least one instruction, at least one section of program, a code set, or an instruction set, where the instruction, the program, the code set, or the instruction set is loaded and executed by the processor to implement the steps of the method for erecting a FIX gateway cluster provided by the embodiment of the first aspect of the present application.

Embodiments of the fourth aspect of the present application provide a non-transitory computer readable storage medium, which when executed by a processor of a mobile terminal, causes the mobile terminal to perform the steps of the method for erecting a FIX gateway cluster provided by the embodiments of the first aspect of the present application.

Embodiments of the fifth aspect of the present application provide a computer program product, which when executed by a processor of a mobile terminal, enables the mobile terminal to perform steps implementing the method for erecting a FIX gateway cluster provided by the embodiments of the first aspect of the present application.

The technical scheme provided by the embodiment of the disclosure can comprise the following beneficial effects:

1. and the cluster stability is improved. The stability of the FIX gateway cluster is only dependent on whether the nodes in the cluster are available or not, and the cluster can work normally as more than half of the nodes survive the cluster because the cluster is built based on the Raft protocol.

The fix Session state is managed by Raft, and persists on local disks of cluster nodes, so that network delay and delay caused by processing delay of an external system during external call are reduced.

3. The implementation cost is reduced. Because the external middleware is removed, the implementation cost is reduced.

4. And the cost of operation and maintenance monitoring is reduced. The running state of the gateway can be completely known only by monitoring the state of the cluster, such as CPU utilization rate, disk utilization rate and the like, and no external dependence is needed to be concerned.

It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.

Drawings

The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the invention and together with the description, serve to explain the principles of the invention.

Fig. 1 is a flowchart illustrating a method of erecting a FIX gateway cluster according to an exemplary embodiment.

Fig. 2 is a block diagram illustrating an erection device of a FIX gateway cluster according to an exemplary embodiment.

FIG. 3 is an architectural state diagram illustrating a FIX gateway cluster and peer connection according to an exemplary embodiment.

FIG. 4 is a flowchart illustrating a process after a Leader election is completed, according to an example embodiment.

Fig. 5 is a message processing flow diagram of an outbound direction, according to an exemplary embodiment.

Fig. 6 is a message processing flow diagram of an Incoming direction, according to an exemplary embodiment.

Fig. 7 is an internal structural diagram of an electronic device, which is shown according to an exemplary embodiment.

Detailed Description

Reference will now be made in detail to exemplary embodiments, examples of which are illustrated in the accompanying drawings. When the following description refers to the accompanying drawings, the same numbers in different drawings refer to the same or similar elements, unless otherwise indicated. The implementations described in the following exemplary examples do not represent all implementations consistent with the invention. Rather, they are merely examples of apparatus and methods consistent with aspects of the invention as detailed in the accompanying claims.

Fig. 1 is a flowchart illustrating a method for erecting a FIX gateway cluster according to an exemplary embodiment, including the steps of:

in step S101, a Leader node is selected from a plurality of Raft nodes in the FIX gateway cluster based on a Raft protocol, where the Raft node includes three node states of a Leader node, a follow node, and a Candidate node.

Specifically, the Raft protocol has a Leader selection characteristic, in a cluster erected based on the Raft protocol, each Raft node can establish long connection with all other Raft nodes to communicate, then the Raft nodes can elect a Leader node based on the Raft protocol, the Leader node can be responsible for writing all messages, and each Raft node has the following three node states.

Leader node state: only one Leader node exists in one cluster, and FIX connection needs to be initiated to the opposite terminal to be responsible for all service processing; when there is a data writing demand, a data synchronization request is sent to all other nodes.

Follower node state: and the system is responsible for receiving a data synchronization request sent from the Leader node and writing data carried in the request into a local disk.

Candidate node state: the role that can only appear in the Leader election process, the Candidate node sends a request for electing the own node as the Leader node to all other nodes, and if the request is accepted by most nodes, the Candidate node becomes the Leader node.

Specifically, in one case, in the initial state, all the Raft nodes are in a gateway node state, no Leader node exists at this time, when the opposite end needs to establish FIX Session connection, a connection timeout condition occurs due to the absence of a Leader node, when a connection timeout phenomenon occurs, if a certain gateway needs to establish FIX Session connection with the opposite end, the node state of the gateway is changed into a Candidate node state, a request for selecting a self node as a Leader node is sent to other gateway nodes, and when the number of nodes recognizing the request exceeds a preset value, the Candidate node is changed into the Leader node state, so that the FIX Session connection is subsequently established with the opposite end, and the overall architecture state of the FIX gateway cluster is shown in fig. 3.

Alternatively, if there is a Leader node in the Raft node, the Candidate node needs to be reconverted to the state of the Follower node.

In order to ensure that only one Leader node at a time point establishes a FIX Session, as shown in fig. 4, when a new node in the cluster is to be a Leader node of a shift, after the shift internal state processing is completed, a request for [ updating the FIX Leader ] is sent to all other nodes through a shift RPC (Remote Procedure Call) to expect the cluster to reach consensus, and the new shift Leader has been switched, and the FIX Session needs to be created by the new Leader node. The request needs to include the ID of the current Leader node.

When a node in the cluster receives the request of updating the FIX header, it needs to determine whether the header ID in the request is the current node, if not, and if the current node has already established a FIX Session, then it needs to actively disconnect the already established FIX Session. Otherwise, immediately replying to the confirmation.

When the majority of nodes in the cluster have confirmed that the [ update FIX header ] request processing is successful, the FIX header identity of the master node has been agreed in the cluster, and then an attempt to establish a new FIX Session may begin. It should be noted that most node acknowledgements (update FIX header) requests have been processed and do not necessarily represent that FIX Session of the previous header has been disconnected, so that a new header node may need to retry multiple times until after the previous Leader FIX Session is disconnected, the new FIX Session may not be re-established successfully.

Specifically, the number of the Raft nodes in the present application at least includes 3, if 1 Raft node having the Leader node state is down, the remaining 2 nodes are still available, so that the FIX gateway cluster can operate normally. The plurality of Raft nodes are connected to each other so that the received and transmitted data can be transmitted to each other at each node.

In step S102, a FIX Session connection is established between the Leader node and the opposite terminal, a message is sent or received to the opposite terminal through the Leader node and the FIX Session, and a FIX Session state change after the message is sent or received to the opposite terminal by the Leader node is stored in a plurality of Raft nodes based on a Raft protocol.

Specifically, after a Leader node is selected from multiple Raft nodes in step S101, a FIX Session connection is established between the Leader node and the opposite end through the Leader node and the FIX Session, and a message can be sent or received to the opposite end through the Leader node and the FIX Session. And the associated FIX Session state is also saved in multiple Follower nodes.

Specifically, FIX Session is a long connection with full duplex, so that the FIX Session sends and receives messages in both outbound and inbound directions, which results in a change in the state of FIX Session, requiring recording and multi-node replication in the cluster, and when a message is sent to the opposite end of the connection through FIX Session, it is called outbound direction. In an actual securities trading system, the out message is typically a user request message such as an order, a withdrawal, etc. When a message is received by FIX Session, it is called an Incoming-oriented message. In an actual stock exchange system, the message of Incoming is typically a type of order confirmation, bargain, or the like.

In some embodiments, the message sent to the opposite terminal through the Leader node and the FIX Session includes a list-ordering and list-removing user request message, including:

Specifically, as shown in fig. 5, after the Leader node of the cluster receives a request for sending a FIX message, the request on the service is first converted into the FIX message, and then a lock is locked inside the node to generate an incremental FIX message sequence number. The Leader node then sends a [ FIX message send ] request to all the Follower nodes in the cluster. After the nodes in the cluster receive the request of FIX message sending, the latest state of FIX Session is stored in the local disk after the internal processing of the Raft is finished. After the processing is finished, the acknowledgement message is sent, and after the acknowledgement messages of a plurality of Follower nodes are received by the Leader node, the FIX message is sent to the opposite terminal through the FIX Session.

Specifically, as shown in fig. 6, the Leader node receives an Incoming message sent by the opposite end from the FIX Session, converts a FIX message format that cannot be generally identified by the service party into a message format identified by the service party, and first delivers the message to the outside (sends the message to the internal service in a manner of HTTP or a message queue, etc.). The action of delivering the message is preceded in order to avoid the problem that the status of FIX Session has been updated, but for some reason, the message is not delivered normally. The mode of firstly delivering the message successfully and then updating the FIX Session state can lead the external delivery of the FIX message to be At Least one on, so that the business service needs to carry out idempotent processing on the message delivered by the FIX gateway. After the header node completes the external delivery of the message, the header node sends a [ FIX including message processing ] request to all the rest of the Follower nodes in the cluster. After receiving the request, the Follower node in the cluster confirms the message and writes the disk, and stores the latest state of the FIX Session to the local disk. After the Leader node receives the confirmation requests of a plurality of nodes in the cluster, the successful change of the FIX Session state is confirmed, and the processing is finished.

Based on the above flow, the method and the device realize multi-node real-time replication of the Leader election and the FIX Session state inside the FIX gateway by means of the Leader election and the Log replication mechanism of the Raft under the condition of not using any external middleware.

Fig. 2 is an erection device of a FIX gateway cluster according to an exemplary embodiment. Referring to fig. 2, the apparatus includes an election module 201, a save module 202.

The election module 201 is used for electing a Leader node from a plurality of Raft nodes of the FIX gateway cluster based on a Raft protocol, wherein the Raft node comprises three node states of a Leader node, a follow node and a Candidate node;

the saving module 202 establishes FIX Session connection with the opposite terminal based on the Leader node, sends or receives a message to the opposite terminal through the Leader node and the FIX Session, and saves the FIX Session state change after the message is sent or received to the opposite terminal by the Leader node in a plurality of Raft nodes based on a Raft protocol.

The specific manner in which the various modules perform the operations in the apparatus of the above embodiments have been described in detail in connection with the embodiments of the method, and will not be described in detail herein.

In one embodiment, an electronic device is provided, which may be a terminal, and an internal structure diagram thereof may be as shown in fig. 7. The electronic device includes a processor, a memory, a communication interface, a display screen, and an input device connected by a system bus. Wherein the processor of the electronic device is configured to provide computing and control capabilities. The memory of the electronic device includes a nonvolatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The communication interface of the computer device is used for carrying out wired or wireless communication with an external terminal, and the wireless mode can be realized through WIFI, an operator network, near Field Communication (NFC) or other technologies. The computer program, when executed by a processor, implements a method of erecting a FIX gateway cluster. The display screen of the computer equipment can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer equipment can be a touch layer covered on the display screen, can also be keys, a track ball or a touch pad arranged on the shell of the computer equipment, and can also be an external keyboard, a touch pad or a mouse and the like.

It will be appreciated by those skilled in the art that the structure shown in fig. 7 is merely a block diagram of some of the structures associated with the present application and is not limiting of the computer device to which the present application may be applied, and that a particular computer device may include more or fewer components than shown, or may combine certain components, or have a different arrangement of components.

In one embodiment, the erection device of the FIX gateway cluster provided in the present application may be implemented as a form of a computer program, and the computer program may be run on an electronic device as shown in fig. 7. The memory of the electronic device may store program modules of the erection device constituting the FIX gateway cluster.

At least one instruction, at least one section of program, code set or instruction set is stored in a memory in the electronic device, and the instruction, the program, the code set or the instruction set is loaded and executed by the processor to implement the FIX gateway cluster erection method according to any one of the above embodiments. For example, the method for implementing the erection of the FIX gateway cluster comprises the following steps: selecting a Leader node from a plurality of Raft nodes of the FIX gateway cluster based on a Raft protocol, wherein the Raft node comprises three node states of a Leader node, a follow node and a Candidate node; and establishing FIX Session connection between the Leader node and the opposite terminal, sending or receiving information to the opposite terminal through the Leader node and the FIX Session, and storing the FIX Session state change after the information is sent or received to the opposite terminal by the Leader node in a plurality of Raft nodes based on a Raft protocol.

In one embodiment, a computer readable storage medium is provided having a computer program stored thereon, which when executed by a processor, performs the steps of: selecting a Leader node from a plurality of Raft nodes of the FIX gateway cluster based on a Raft protocol, wherein the Raft node comprises three node states of a Leader node, a follow node and a Candidate node; and establishing FIX Session connection between the Leader node and the opposite terminal, sending or receiving information to the opposite terminal through the Leader node and the FIX Session, and storing the FIX Session state change after the information is sent or received to the opposite terminal by the Leader node in a plurality of Raft nodes based on a Raft protocol.

In one embodiment, a computer program product is provided, which when executed by a processor of a mobile terminal, causes the mobile terminal to perform the steps of: selecting a Leader node from a plurality of Raft nodes of the FIX gateway cluster based on a Raft protocol, wherein the Raft node comprises three node states of a Leader node, a follow node and a Candidate node; and establishing FIX Session connection between the Leader node and the opposite terminal, sending or receiving information to the opposite terminal through the Leader node and the FIX Session, and storing the FIX Session state change after the information is sent or received to the opposite terminal by the Leader node in a plurality of Raft nodes based on a Raft protocol.

Those skilled in the art will appreciate that implementing all or part of the above-described methods may be accomplished by way of a computer program, which may be stored on a non-transitory computer readable storage medium, that when executed may comprise the steps of the embodiments of the methods described above. Any reference to memory, database, or other medium used in the various embodiments provided herein may include at least one of non-volatile and volatile memory. The nonvolatile Memory may include Read-Only Memory (ROM), magnetic tape, floppy disk, flash Memory, optical Memory, or the like. Volatile memory can include random access memory (Random Access Memory, RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms, such as static random access memory (Static Random Access Memory, SRAM), dynamic random access memory (Dynamic Random Access Memory, DRAM), and the like.

The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features of each of the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

The foregoing examples represent only a few embodiments of the present application, which are described in more detail and are not to be construed as limiting the scope of the invention. It should be noted that it would be apparent to those skilled in the art that various modifications and improvements could be made without departing from the spirit of the present application, which would be within the scope of the present application. Accordingly, the scope of protection of the present application is to be determined by the claims appended hereto.

Claims

1. The method for erecting the FIX gateway cluster is characterized by comprising the following steps of:

2. The method for erecting a FIX gateway cluster according to claim 1, wherein a Leader node is selected from a plurality of Raft nodes of the FIX gateway cluster based on a Raft protocol, wherein the Raft node includes three node states of a Leader node, a follow node, and a Candidate node, and the method comprises:

3. The method for erecting a FIX gateway cluster according to claim 1, wherein a FIX Session connection is established between the Leader node and the opposite terminal, a message is sent or received to the opposite terminal through the Leader node and the FIX Session, and a change in FIX Session state after the message is sent or received to the opposite terminal by the Leader node is stored in a plurality of Raft nodes based on a Raft protocol, comprising:

4. The method for erecting a FIX gateway cluster according to claim 3, wherein the messages sent to the opposite terminal through the Leader node and the FIX Session include a request message for ordering and removing a single user, including:

5. The method for installing a FIX gateway cluster according to claim 3, wherein the messages received to the opposite end through the Leader node and the FIX Session include order confirmation and transaction type messages, comprising:

6. The method for installing a FIX gateway cluster according to claim 1, further comprising: the plurality of Raft nodes comprises at least 3, and the plurality of Raft nodes are connected with each other.

7. An erection device of a FIX gateway cluster, comprising:

8. An electronic device comprising a processor and a memory, wherein at least one instruction, at least one program, code set, or instruction set is stored in the memory, and wherein the instruction, the program, the code set, or the instruction set is loaded and executed by the processor to implement a method of erecting a FIX gateway cluster according to any of claims 1-6.

9. A non-transitory computer readable storage medium, characterized in that instructions in the storage medium, when executed by a processor of a mobile terminal, enable the mobile terminal to perform the method of erecting FIX gateway clusters according to any of claims 1-6.

10. Computer program product, characterized in that instructions in the computer program product, when executed by a processor of a mobile terminal, enable the mobile terminal to perform the method of erection of FIX gateway clusters according to any of claims 1-6.