Disaster recovery method for futures trading

Abstract

The invention provides a disaster recovery method for futures trading, which comprises the following steps that: a main end and a standby end perform handshake, and whether a communication link is valid or not is verified; and carrying out file header size negotiation on the created and read file. And before the file is backed up, the host end sends a file clearing command to the standby machine, and the standby machine end executes clearing operation. And the host side synchronizes the MD5 value of each file to be backed up to the standby machine, and the host determines whether to carry out initial backup or not according to the value. And starting file updating monitoring logic by the host end, and recording the changed file in the to-be-backed-up file queue Qu. And the host traverses the Qu, reads the to-be-updated file from the Qu, packs the to-be-updated file and sends the to-be-updated file to the standby machine end, and the standby machine end executes unpacking logic after receiving the to-be-updated file and releases the file to a related path. According to the invention, the dynamic real-time backup of the data file generated by the futures trading counter can be realized, and when the futures trading counter is down, the futures company can quickly complete the main-standby switching, so that the loss caused by the down is greatly reduced.

Description

Technical Field

[0001] The present invention belongs to the field of financial futures trading and relates to a disaster recovery method for futures trading. Background Art

[0002] In financial futures trading systems, futures companies' trading counters are typically deployed in exchange computer rooms. When a trading counter experiences downtime, the traditional method is to dump all data from the trading counter to a backup server through SSH online copying and external media dumping for system recovery. However, these methods are time-consuming, inconvenient, and carry certain risks. Therefore, an efficient and reliable disaster recovery system for futures trading is needed to perform real-time dynamic data backup. This ensures that the backup server can be quickly switched to when the trading counter fails, thereby minimizing losses. Summary of the Invention

[0003] 1. Technical problems to be solved: In futures trading systems, traditional file transfer methods such as SSH online copying and external media dumping are time-consuming and inconvenient, leading to increased trading risks.

[0004] 2. Technical solution: In order to solve the above problems, the present invention provides a disaster recovery method for futures trading, comprising the following steps: Step S01: The master and backup ends perform a handshake process and verify whether the current communication link KEY is valid.

[0005] Step S02: Negotiate the file header size between the master and backup parties for the file created and read using the mmap method.

[0006] Step S03: Before backing up the files, the host sends a file clearing command to the standby machine, and the standby machine executes the file clearing operation under the corresponding path.

[0007] Step S04: The host synchronizes the MD5 value of each file to be backed up to the standby machine according to the path file in the configured backup file list, and the host decides whether to perform an initial backup based on the value.

[0008] Step S05: The host starts the file update monitoring logic and records the changed files in the queue Qu of files to be backed up in the form of messages.

[0009] Step S06: The host traverses Qu and reads the file to be updated therefrom, packages it, and sends it to the backup machine for backup. After receiving the data packet, the backup machine executes the unpacking logic and releases the file to the relevant path.

[0010] In step S01, the specific method is: the web sends the combination of the user name, random number and timestamp to the primary and backup ends respectively, and the primary and backup ends generate corresponding KEY values according to the default Hash algorithm. Each time the backup link handshake occurs, the primary and backup ends will perform a validity check based on the transmitted KEY value, user and random number.

[0011] In step S02, targeted dynamic backup is performed according to the file writing characteristics recorded in the file writing header.

[0012] In step S03, the format of the file storage path on the standby machine is fixed to the backup date plus the IP address.

[0013] In step S04, the specific method is: the host locally configures the files to be backed up, calculates the MD5 values of the files to be backed up one by one, and synchronizes them to the standby machine. The standby machine checks and compares the MD5 of the corresponding files in the local backed up file path, and determines which files need to be backed up in the initial stage by comparing the MD5 of the files to be backed up.

[0014] In step S05, real-time monitoring of static files and dynamic files written in append mode is implemented based on the kernel inotify underlying component to see if there are any changes. When file F0 changes, it is inserted into Qu. Specifically, when the static file SF0 changes, the system packages SF0 as a whole and sends it to the backup machine. For the dynamic file DF0, the read pointer RP0 before the record change and the read pointer RP1 after the file change are used to calculate the number of bytes that the file DF0 needs to transmit using RP1-RP0, and the parameter information of the file change is input into the queue Qu.

[0015] In step S06, the queue Qu is traversed to read the changed file F0, which is packaged according to the custom transmission protocol DefProto and sent to the standby machine. The standby machine also parses the file according to the protocol and releases the file to the corresponding path.

[0016] The DefProto protocol format consists of a 1-byte message header identifier, an 8-byte message total length, a 4-byte operation code, a 4-byte KEY value, a 4-byte reserved field, and data content.

[0017] Different processing logic is executed according to different operation codes. Specifically, when the operation code is file transfer, the file transmission format in the data part is composed of 8-byte file length, 1-byte operation flag, 1-byte compression flag, 2-byte file path length, and variable-length data part. For data exceeding 2MB, the compression flag is set to 1, otherwise it is 0 and no compression is required. The operation flag indicates the file writing method, 0 indicates overwrite writing, 1 indicates append writing, and 2 indicates random writing.

[0018] It also includes an error retransmission module ErrLgic. When a transmission error occurs, ErrLgic will be triggered to restart the transmission process, reinsert the error file into the Qu queue, and execute steps S05 and S06 again for retransmission.

[0019] 3.Beneficial effects: The present invention discloses a disaster recovery system for futures trading, which can realize dynamic real-time backup of data files generated by futures trading counters. When the futures trading counter goes down, the futures company can quickly complete the master-slave switch, greatly reducing the losses caused by the downtime. BRIEF DESCRIPTION OF THE DRAWINGS

[0020] Figure 1 This is a diagram of data backup interaction between the primary and backup ends. DETAILED DESCRIPTION

[0021] The present invention is described in detail below with reference to the accompanying drawings and embodiments.

[0022] like Figure 1 As shown, a disaster recovery method for futures trading includes the following steps: Step S01: The master and backup ends perform a handshake process and verify whether the current communication link KEY is valid.

[0023] Step S02: Negotiate the file header size between the master and backup parties for the file created and read using the mmap method.

[0024] Step S03: Before backing up the files, the host sends a file clearing command to the standby machine, and the standby machine executes the file clearing operation under the corresponding path.

[0025] Step S04: The host synchronizes the MD5 value of each file to be backed up to the standby machine according to the path file in the configured backup file list, and the host decides whether to perform an initial backup based on the value.

[0026] Step S05: The host starts the file update monitoring logic and records the changed files in the queue Qu of files to be backed up in the form of messages.

[0027] Step S06: The host traverses Qu and reads the file to be updated therefrom, packages it, and sends it to the backup machine for backup. After receiving the data packet, the backup machine executes the unpacking logic and releases the file to the relevant path.

[0028] In one embodiment, the specific method of step S01 is: the web sends a combination of the user name, random number and timestamp to the primary and backup ends respectively, and the primary and backup ends generate corresponding KEY values according to the default Hash algorithm. Each time the backup link handshake occurs, the primary and backup ends will perform a legitimacy check based on the transmitted KEY value, user and random number.

[0029] In one embodiment, in step S02, for files created and read / written using mmap, selective dynamic backup is required based on the file write characteristics recorded in the file write header. Static files are backed up using overwrite. For dynamically appended files, the number of bytes required to transfer for file DF0 is calculated by using the read pointer RP0 before the record change and the read pointer RP1 after the file change, using RP1-RP0, and the parameter information of the file change is entered into the queue Qu. In one embodiment, in step S03, the file storage path format on the backup machine is fixed to the backup date plus IP address. When the backup logic on both the primary and backup ends is started, all temporary files in the path in the above format on the backup machine must be cleared to prevent backup inconsistency problems caused by different writing methods.

[0030] In one embodiment, in step S04, the host locally configures the files to be backed up, calculates the MD5 values of the files to be backed up one by one, and synchronizes them to the standby machine. The standby machine checks and compares the MD5 of the corresponding files in the local backed-up file path, and determines which files need to be backed up in the initial stage by comparing the MD5 of the files to be backed up, thereby reducing unnecessary file backups.

[0031] In one embodiment, in step S05, real-time monitoring of whether static files and dynamic files written in appending mode have changed is implemented based on the kernel inotify underlying component. When file F0 changes, it is inserted into Qu; when static file SF0 changes, the system will package SF0 as a whole and send it to the backup machine. For dynamic file DF0, the read pointer RP0 before the record change and the read pointer RP1 after the file change are used to calculate the number of bytes that file DF0 needs to transmit using RP1-RP0, and the parameter information of the file change is input into queue Qu.

[0032] In one embodiment, in step S06, the queue Qu is traversed to read the changed file F0 therefrom, packaged according to the custom transmission protocol DefProto and sent to the standby machine, which also parses the file according to the protocol and releases the file to the corresponding path.

[0033] In one embodiment, the DefProto protocol format mainly consists of a 1-byte message header identifier, an 8-byte message total length, a 4-byte operation code, a 4-byte KEY value, a 4-byte reserved field, and data content.

[0034] In one embodiment, different processing logic is executed according to different operation codes. When the operation code is file transfer, the file transmission format in its data part is composed of an 8-byte file length, a 1-byte operation tag, a 1-byte compression tag, a 2-byte file path length, and a variable-length data part. For data exceeding 2MB, the compression tag is set to 1, otherwise it is 0 and no compression is required. The operation tag indicates the file writing method, 0 indicates overwrite writing, 1 indicates append writing, and 2 indicates random writing.

[0035] In one embodiment, the present invention further provides an error retransmission module ErrLgic. When a transmission error occurs, ErrLgic will be triggered to restart the transmission process, reinsert the erroneous file into the Qu queue, and execute steps S05 and S06 again for retransmission, thereby ensuring the transmission reliability of the DefProto protocol.

[0036] Although the present invention has been disclosed above in terms of preferred embodiments, they are not intended to limit the present invention. Anyone skilled in the art can make various changes or modifications without departing from the spirit and scope of the present invention. Therefore, the scope of protection of the present invention should be based on the scope of protection defined by the claims of this application.

Claims

1. A disaster recovery method for futures trading, comprising the following steps: Step S01: The master and backup terminals perform a handshake process and verify whether the current communication link KEY is valid; Step S02: Negotiating the file header size between the master and backup parties for the file created and read using mmap; Step S03: Before backing up the files, the host sends a file clearing command to the backup machine, and the backup machine executes the file clearing operation under the corresponding path; Step S04: The host synchronizes the MD5 values of each file to be backed up to the backup server according to the path file in the configured backup file list. The host decides whether to perform an initial backup based on the value. Step S05: The host starts the file update monitoring logic and records the changed files in the queue Qu of files to be backed up in the form of messages; Step S06: The host traverses Qu and reads the file to be updated therefrom, packages it, and sends it to the backup machine for backup. After receiving the data packet, the backup machine executes the unpacking logic and releases the file to the relevant path.

2. The disaster recovery method for futures trading according to claim 1, characterized in that: In step S01, the specific method is: the web sends the combination of the user name, random number and timestamp to the primary and backup ends respectively, and the primary and backup ends generate corresponding KEY values according to the default Hash algorithm. Each time the backup link handshake occurs, the primary and backup ends will perform a validity check based on the transmitted KEY value, user and random number.

3. The disaster recovery method for futures trading according to claim 1, characterized in that: In step S02, targeted dynamic backup is performed according to the file writing characteristics recorded in the file writing header.

4. The disaster recovery method for futures trading according to claim 1, characterized in that: In step S03, the format of the file storage path on the standby machine is fixed to the backup date plus the IP address.

5. The disaster recovery method for futures trading according to claim 1, characterized in that: In step S04, the specific method is: the host locally configures the files to be backed up, calculates the MD5 values of the files to be backed up one by one, and synchronizes them to the standby machine. The standby machine checks and compares the MD5 of the corresponding files in the local backed up file path, and determines which files need to be backed up in the initial stage by comparing the MD5 of the files to be backed up.

6. The disaster recovery method for futures trading according to claim 1, characterized in that: In step S05, real-time monitoring of static files and dynamic files written in append mode is implemented based on the kernel inotify underlying component to see if there are any changes. When file F0 changes, it is inserted into Qu. Specifically, when the static file SF0 changes, the system packages SF0 as a whole and sends it to the backup machine. For the dynamic file DF0, the read pointer RP0 before the record change and the read pointer RP1 after the file change are used to calculate the number of bytes that the file DF0 needs to transmit using RP1-RP0, and the parameter information of the file change is input into the queue Qu.

7. The disaster recovery method for futures trading according to claim 1, characterized in that: In step S06, the queue Qu is traversed to read the changed file F0, which is packaged according to the custom transmission protocol DefProto and sent to the standby machine. The standby machine also parses the file according to the protocol and releases the file to the corresponding path.

8. The disaster recovery method for futures trading according to claim 7, characterized in that: The DefProto protocol format consists of a 1-byte message header identifier, an 8-byte message total length, a 4-byte operation code, a 4-byte KEY value, a 4-byte reserved field, and data content.

9. The disaster recovery method for futures trading according to claim 8, characterized in that: Different processing logic is executed according to different operation codes. Specifically, when the operation code is file transfer, the file transmission format in the data part is composed of 8-byte file length, 1-byte operation flag, 1-byte compression flag, 2-byte file path length, and variable-length data part. For data exceeding 2MB, the compression flag is set to 1, otherwise it is 0 and no compression is required. The operation flag indicates the file writing method, 0 indicates overwrite writing, 1 indicates append writing, and 2 indicates random writing.

10. The disaster recovery method for futures trading according to claim 9, characterized in that: It also includes an error retransmission module ErrLgic. When a transmission error occurs, ErrLgic will be triggered to restart the transmission process, reinsert the error file into the Qu queue, and execute steps S05 and S06 again for retransmission.

Images