An inter-cluster data synchronization method, device and electronic equipment

Abstract

The application discloses an inter-cluster data synchronization method and device and electronic equipment, and the method comprises the following steps: sending service data carrying a version number generated by a service activity to a master cluster, and generating a service message corresponding to the service data, and then sending the service message to a message queue; taking the service message from the message queue, and checking whether the service message is a target service message corresponding to current to-be-received service data of a backup cluster based on the version number of the service message; if the checking is passed, analyzing the service data from the service message, and sending the service data to the backup cluster for storage. The technical scheme provided by the application solves the problem of data inconsistency caused by message disordering in the transmission process, and guarantees the data consistency between clusters.

Description

Technical Field

[0001] This invention relates to the field of data processing, and more specifically to a method, apparatus, and electronic device for data synchronization between clusters. Background Technology

[0002] In industries such as finance, data security requirements are extremely high. Disaster recovery infrastructure is generally crucial to ensuring data security, with common solutions including "two-site three-center" and "active-active" architectures. The core of disaster recovery is data backup, which inevitably involves data synchronization. Therefore, data synchronization is widely used in disaster recovery to ensure consistency of backup data across two or more clusters. Currently, a widely adopted data synchronization solution is an eventual consistency solution based on local message tables, such as... Figure 1 As shown, the process first generates business messages for the executed business logic, and stores both the business data and the business messages in a primary cluster. Then, a message management program periodically retrieves messages from the primary cluster and stores them in a message queue. The message queue then sends the messages that need to be synchronized to other backup clusters. However, existing synchronization schemes are prone to message loss or other unforeseen circumstances during transmission, leading to message out-of-order delivery and inconsistencies between the backup and primary clusters. Therefore, ensuring data consistency between clusters is a critical issue that needs to be addressed when message out-of-order delivery is unavoidable. Summary of the Invention

[0003] In view of this, embodiments of the present invention provide a data synchronization method, apparatus, and electronic device for inter-cluster data, thereby solving the data inconsistency problem caused by out-of-order messages during transmission and ensuring data consistency between clusters.

[0004] According to a first aspect, the present invention provides a data synchronization method between clusters, the method comprising: sending business data carrying a version number generated by a business activity to a primary cluster, generating a corresponding business message for the business data, and then sending the business message to a message queue, wherein the version number is a value extracted from a preset version number sequence, and the business activity, the generation of the business data, the storage of the business data in the primary cluster, the creation of the business message, and the sending of the business message constitute a local transaction; retrieving the business message from the message queue, and verifying whether the business message is a target business message corresponding to the business data currently to be received by a backup cluster based on the version number of the business message; if the verification passes, parsing the business data from the business message, and sending the business data to the backup cluster for storage.

[0005] Optionally, after verifying whether the business message is the target business message to be received by the backup cluster based on the version number of the business message, the method further includes: if the verification fails, and when the version number indicates that the version of the business message is ahead of the time, notifying the message queue to redeploy the business message.

[0006] Optionally, while sending the business message to the message queue, the business message is also sent to the main cluster. After verifying whether the business message is the target business message corresponding to the business data to be received by the backup cluster based on the version number of the business message, the method further includes: deleting the business messages that pass the verification and those that are verified as outdated from the main cluster through the message deletion module.

[0007] Optionally, the method further includes: sending a first business message in the main cluster that has existed for a duration exceeding a preset time length to the message queue through an independent retransmission module to redeploy the business message; resetting the existence duration of the first business message through the independent retransmission module, and updating the number of times the first business message has been sent.

[0008] Optionally, the version number is generated in a preset order. The step of verifying whether the business message is the target business message corresponding to the currently received business data in the backup cluster based on the version number of the business message includes: determining whether there is business data in the backup cluster that corresponds to the same execution object as the business message; if not, the verification passes, and the business message is used as the target business message, where the execution object is the external user performing the business activity; if it exists, determining whether the version number of the business message and the version number of the business data corresponding to the same execution object in the backup cluster conform to the preset order, where the preset order is the order of the version number sequence; if they conform to the preset order, the verification passes, and the business message is used as the target business message; if they do not conform to the preset order, the verification fails.

[0009] Optionally, the step of sending the business data carrying a version number generated by the business activity to the main cluster, generating a corresponding business message for the business data, and then sending the business message to a message queue includes: if the business activity fails to execute, exiting the current data synchronization process and notifying the external user to re-initiate the instruction to execute the business activity; if the business activity executes successfully, sending the business data carrying a version number generated by the business activity to the main cluster; if the business data fails to be stored in the main cluster, exiting the current data synchronization process and notifying the external user to re-initiate the instruction to execute the business activity; if the business data is successfully stored in the main cluster, creating a business message corresponding to the business data; if the creation of the business message fails, canceling the execution of the business activity, exiting the current data synchronization process, and notifying the external user to re-initiate the instruction to execute the business activity; if the creation of the business message succeeds, sending the business message to a message queue; if the sending of the business message fails, canceling the business data from the main cluster, exiting the current data synchronization process, and notifying the external user to re-initiate the instruction to execute the business activity.

[0010] According to a second aspect, the present invention provides a data synchronization device between clusters, the device comprising: a local transaction module, configured to send business data carrying a version number generated by a business activity to a primary cluster, generate a corresponding business message for the business data, and then send the business message to a message queue, wherein the version number is a value extracted from a preset version number sequence, and the business activity, the generation of the business data, the storage of the business data in the primary cluster, the creation of the business message, and the sending of the business message constitute a local transaction; a version verification module, configured to retrieve the business message from the message queue and verify whether the business message is a target business message corresponding to the business data currently to be received by the backup cluster based on the version number of the business message; and a request sending module, configured to parse the business data from the business message if the verification passes, and send the business data to the backup cluster for storage.

[0011] Optionally, the apparatus further includes a message redeployment module, configured to notify the message queue to redeploy the business message when the verification fails and when the version number indicates that the business message version is ahead of its time.

[0012] According to a third aspect, embodiments of the present invention provide an electronic device, including: a memory and a processor, wherein the memory and the processor are communicatively connected to each other, the memory stores computer instructions, and the processor executes the computer instructions to perform the method described in the first aspect, or any optional embodiment of the first aspect.

[0013] According to a fourth aspect, embodiments of the present invention provide a computer-readable storage medium storing computer instructions for causing the computer to perform the method described in the first aspect, or any alternative embodiment of the first aspect.

[0014] The technical solution provided in this application has the following advantages:

[0015] The technical solution provided in this application, after a business activity, sends the business data generated by the activity to the main cluster. Based on the business data carrying a version number, a corresponding business message is generated and sent to a message queue. A consumer program then retrieves the business message from the message queue and verifies its version number to determine if it is a business message to be received by the backup cluster. Only after the version verification passes is the corresponding business data parsed from the message and synchronized to the backup cluster to complete business synchronization. This version verification mechanism ensures that business messages are synchronized only when the version number verification passes, solving the data inconsistency problem caused by out-of-order messages during transmission, improving the accuracy of data in the backup cluster, and saving redundant time by sending each generated business message directly to the message queue without retrieving it from the main cluster.

[0016] Furthermore, to facilitate the verification of business messages, the existing configuration of storing business messages in the main cluster was retained. However, a message deletion module was added to the devices performing data synchronization. Based on the feedback results of each successful synchronization and version lag, the corresponding business messages in the main cluster were deleted, avoiding message redundancy and improving the business message management capabilities of the main cluster. Subsequently, an independent retransmission module was added to the devices performing data synchronization. This allows business messages to be retransmitted even when the message queue lacks a retransmission mechanism, expanding the selection range of message queue components and reducing the technical difficulty for developers implementing this solution. Attached Figure Description

[0017] The features and advantages of the invention will be more clearly understood by referring to the accompanying drawings, which are schematic and should not be construed as limiting the invention in any way. In the drawings:

[0018] Figure 1 A schematic diagram illustrating the data synchronization process between clusters in the prior art is shown;

[0019] Figure 2 The diagram illustrates the steps of a data synchronization method between clusters according to one embodiment of the present invention.

[0020] Figure 3A flowchart illustrating a data synchronization method between clusters according to one embodiment of the present invention is shown.

[0021] Figure 4 The figure shows an application example of out-of-order insertion requests in one embodiment of the present invention;

[0022] Figure 5 The figure shows an application example of out-of-order update requests in one embodiment of the present invention;

[0023] Figure 6 A schematic diagram of the structure of a data synchronization device between clusters according to one embodiment of the present invention is shown;

[0024] Figure 7 A schematic diagram of an electronic device according to one embodiment of the present invention is shown. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of the present invention, and not all of them. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0026] Please see Figure 2 and Figure 3 In one embodiment, the data synchronization method between clusters provided by this invention is applied to an intermediate device for data synchronization between a primary cluster and a backup cluster, and specifically includes the following steps:

[0027] Step S101: Send the business data with version number generated by the business activity to the main cluster, generate a corresponding business message for the business data, and then send the business message to the message queue. The version number is a value taken from a preset version number sequence. The business activity, the generation of business data, the storage of business data in the main cluster, the creation of business messages, and the sending of business messages constitute a local transaction.

[0028] Step S102: Retrieve the business message from the message queue and verify whether the business message is the target business message corresponding to the business data to be received by the backup cluster based on the version number of the business message.

[0029] Step S103: If the verification passes, the business data is parsed from the business message and sent to the backup cluster for storage.

[0030] Specifically, when existing technologies synchronize data between clusters, data inconsistency issues often arise due to message out-of-order delivery. Message out-of-order delivery mainly includes the following scenarios:

[0031] 1. Insertion request out of order

[0032] like Figure 4 As shown, after the main cluster processed one insert and one update request consecutively, the value in the database was B. However, when sending messages, a message was sent repeatedly. Figure 4 The third message in the sequence. After these three messages are consumed, the data in the backup cluster is A. At this point, the data in the primary backup cluster is inconsistent.

[0033] 2. Update requests are out of order.

[0034] like Figure 5 As shown, three requests were processed sequentially on the primary cluster side: "Insert A", "Update to B", and "Update to C". The final data on the primary cluster side should be C. However, during the synchronization of the requests to the backup cluster side, the messages became out of order for some reason, and the "Update to B" request became the last request. After synchronization was complete, the data on the backup cluster side was B. Thus, the data on the two systems became inconsistent.

[0035] Therefore, to address the aforementioned scenarios, this embodiment of the invention uses a version number verification mechanism on the intermediate device (which can be various types of computer devices) performing data synchronization between the primary cluster and the backup cluster to solve the problems in these scenarios. Business activities refer to the daily work and life activities of departments, companies, organizations, etc., that require backup of daily activity data. When a business activity (e.g., a bank deposit activity, a mobile phone card application activity, a hotel consumption activity, etc., this invention is not limited to these) ends, corresponding business data is generated (e.g., a user makes a deposit operation, depositing a certain amount). The producer program generates business messages based on the business data carrying the version number and sends each generated business message to the message queue, thereby sequentially synchronizing each piece of business data to the backup cluster. In this embodiment, the business activity, the generation of business data, the storage of business data, the creation of business messages, and the sending of business messages constitute a local transaction. No step can fail; if an error occurs, a rollback will occur, undoing the relevant state data, restoring the original data, and re-executing the business activity from the beginning, thus ensuring the accuracy of data synchronization between clusters. Version numbers can be numerical sequences or text assigned in a preset order, forming a version number sequence. For example, version numbers can be 1, 2, 3, ... or 100, 500, 2500, ... or 1, 0, 3, 2, 5, 4, etc., and this invention is not limited to these. In the implementation of this invention, the version number is a value taken from a preset version number sequence. Assume the preset version number sequence is 1, 2, 3, 4, ... starting from 1 and incrementing in order. If the version number of a certain business data in the current main cluster is 2, and two users update this business data simultaneously, both users carry the current version number 2 when updating. When one user (e.g., user A) completes the business activity first, generates a new version number 3, and the business data is successfully saved, the version number in the main cluster is updated to 3. The other user (e.g., user B) executes the business activity more slowly because user A has already updated the business data and version number. Therefore, the version number 2 carried by user B is outdated, and user B's business activity will inevitably fail. User B needs to retrieve the current business data version number of the primary cluster and attempt to update again with version number 3. Afterward, the consumer program retrieves the business message from the message queue and compares the version number of the message to be received by the backup cluster with the version number of the retrieved business message. If the comparison matches or conforms to a preset change pattern, the message is parsed to obtain the corresponding business data, which is then sent to the backup cluster. If the version number comparison does not match or does not conform to the preset change pattern, the business message is not parsed, and the backup cluster does not receive the corresponding business data, thus preventing the overwriting of the corresponding business data and avoiding synchronization errors, thereby improving the accuracy of data synchronization between clusters.Furthermore, compared with existing technologies, business data and business messages are generated after the business activity ends. The business messages are not stored in the main cluster first, and there is no need for the producer program to retrieve the business messages from the main cluster periodically and send them to the message queue. Instead, the producer program directly sends the generated business messages to the message queue, avoiding redundant steps and improving message transmission efficiency.

[0036] Specifically, in one embodiment, step S101 above includes the following steps:

[0037] Step 1: If the business activity fails, exit the current data synchronization process and notify external users to re-initiate the business activity execution command; if the business activity succeeds, send the business data with version number generated by the business activity to the main cluster.

[0038] Step 2: If the business data fails to be stored in the main cluster, exit the current data synchronization process and notify external users to re-initiate the command to execute the business activity; if the business data is successfully stored in the main cluster, create the business message corresponding to the business data.

[0039] Step 3: If the creation of the business message fails, the execution of the business activity will be cancelled, the current data synchronization process will be exited, and the external user will be notified to re-initiate the instruction to execute the business activity.

[0040] Step 4: If the business message is created successfully, send the business message to the message queue.

[0041] Step 5: If the business message fails to be sent, the business data will be revoked from the main cluster, the current data synchronization process will be exited, and the external user will be notified to re-initiate the command to execute the business activity.

[0042] Specifically, business activities and the generation of business messages based on business data are an inseparable whole as a transaction. An error in any step will cause inconsistencies in the synchronized data between clusters. Therefore, if a business activity fails, data synchronization is not performed, and external users are notified of the failure, prompting them to re-initiate the business activity execution command. If a business activity succeeds, but business message creation fails, to ensure data consistency between clusters, the executed business activity must also be rolled back, thus guaranteeing the atomicity of the business activity execution and business message creation operations. External users are also notified of the failure, prompting them to re-initiate the business activity execution command. If a business activity succeeds, but the step of sending business data to the main cluster fails, a business rollback is also performed. If a business message is successfully created, but a problem occurs during the message queue transmission process, a business rollback is also required to undo the execution result, and the version number is also rolled back along with the business data. If any step encounters a problem, the process must return to the first step and be re-executed. Only when all the above steps are executed correctly can subsequent data synchronization steps be performed, further ensuring the accuracy and reliability of the inter-cluster data synchronization method provided by this invention.

[0043] Specifically, in one embodiment, after step S102 above, the data synchronization method between clusters provided by this embodiment of the invention further includes the following steps:

[0044] Step 12: If the verification fails and the version number indicates that the business message version is outdated, notify the message queue to redeploy the business message. Specifically, when the version verification of a business message fails, if the message version is outdated, it means that the business message has not been successfully synchronized. Therefore, the message queue needs to redeploy the business message so that the consumer program can retrieve the business message again, ensuring that the data in the backup cluster is consistent with that in the primary cluster. For example, if a business message version number is updated in the order of v1, v2, v3, v4, and the backup cluster is currently waiting to receive message v2, while the current message queue needs to send message v3, then the version verification module will find that the version is outdated by comparison and notify the message queue to redeploy the message.

[0045] Specifically, in one embodiment, while sending the business message to the message queue, the business message is also sent to the main cluster. After step S102, the data synchronization method between clusters provided in this embodiment of the invention further includes the following steps:

[0046] Step Thirteen: Delete business messages that have passed verification and those that are found to be outdated from the main cluster using the message deletion module. Specifically, to ensure accurate verification of business messages in the main cluster, the existing mechanism of sending business messages to the main cluster for storage is retained. However, to improve message management efficiency and eliminate message redundancy, a message deletion module is installed on the intermediate device performing data synchronization. The message deletion module deletes redundant business messages in the main cluster based on the business message synchronization results fed back by the verification module. When a business message is successfully synchronized, or when the verified version is outdated (for example, if the backup cluster is waiting to receive a message of version v2, but the message queue needs to send a message of version v1, the backend cluster's waiting to receive a v2 message indicates that the backup cluster has already received a v1 message, so the v1 message is essentially also successfully synchronized), the intermediate device performing data synchronization will send a command through the message deletion module to notify the main cluster to delete the corresponding business message, reducing message redundancy and improving the main cluster's storage capacity.

[0047] Specifically, in one embodiment, when the message queue lacks a redeployment mechanism, the data synchronization method between clusters provided by this embodiment of the invention further includes the following steps:

[0048] Step 6: Send the first business message in the main cluster that has a duration exceeding the preset time length to the message queue through the independent retransmission module to redeploy the business message.

[0049] Step 7: Reset the duration of the first business message through the independent retransmission module and update the number of times the first business message has been sent.

[0050] Specifically, in existing technologies, message redeployment is typically performed through message queue components. Message queue components come in various types, but most message queues lack a message redeployment mechanism. This leads to excessive limitations on message queues in existing technologies. Message queue technologies with redeployment mechanisms are only held by a few technical departments and are not publicly available, making them difficult to acquire due to their confidentiality. Therefore, this embodiment proposes setting up an independent retransmission module outside the message queue to retransmit business messages, reducing the development difficulty for developers. Business messages typically complete synchronization within a preset time, without taking a long time. Therefore, based on the message deletion module's function, if a message has not been deleted for a long time, it is assumed that its synchronization has not been successful, and thus the message needs to be retransmitted. For example, if messages typically synchronize successfully within one minute, then the retransmission time is set to one minute. The independent retransmission module reads the existence time of each business message in the main cluster. If the time exceeds one minute, it is assumed that the business message has likely not synchronized successfully, and thus the business message is retransmitted, resetting its existence time to 0, and accumulating the number of retransmissions for that business message. When business messages are resent too frequently, administrators need to monitor the message and check for any anomalies in the synchronization system. Therefore, in addition to reducing development complexity, setting up a separate resend module also improves the overall reliability of business data synchronization.

[0051] Specifically, in one embodiment, step S102 above includes the following steps:

[0052] Step 8: Determine whether there is business data in the backup cluster that corresponds to the same execution object as the business message. If not, the verification passes, and the business message is used as the target business message. The execution object is the external user who performs the business activity.

[0053] Step 9: If it exists, determine whether the version number of the business message and the version number of the business data corresponding to the same execution object in the backup cluster conform to the preset order. The preset order is the order of the version number sequence.

[0054] Step 10: If the preset order is met, the verification passes and the business message is used as the target business message.

[0055] Step 11: If the order does not conform to the preset sequence, the verification will fail.

[0056] Specifically, when verifying business messages, the verification module first searches the backup cluster for business data corresponding to the same execution object as the business message. For example, in a deposit business activity, different people or different units (as external users) deposit money, and their business activities and the execution objects corresponding to their business data are different. Therefore, the same type of business activity may be performed by different objects. Thus, the execution object corresponding to the business message is verified first. If there is no business data representing the same execution object in the backup cluster, it indicates that the currently sent business message is the first business activity of that execution object. The consumer program directly parses the business message and sends the parsed business data to the backup cluster. If there is business data representing the same execution object in the backup cluster, it indicates that the execution object to which the business message belongs is not performing this type of business activity for the first time. Therefore, the version number needs to be verified. In this embodiment, the version number is generated in a preset order, including but not limited to v1, v2, v3…, v1, v3, v5…, v2, v4, v6… and other numerical patterns. The consumer program determines whether the currently retrieved business message is a business message that the backup cluster is waiting to receive in a preset order. If it matches the preset order, the verification passes, thereby updating the corresponding business data in the backup cluster. This solves the data inconsistency problem caused by out-of-order messages during transmission and improves the accuracy of data synchronization between clusters. For example: There are three messages: message one inserts A, message two updates B, and message three also inserts A. The order of the business messages in the message queue is: message one, message two, message three. The consumer program consumes the first message (message one) from the message queue. The data in the backup cluster becomes A, version number v1, and the backup cluster is waiting to receive a message with version number v2. Then, it consumes the second message (message two), which carries version number v2. Matching the preset order, the verification passes, and the data in the backup cluster becomes B, version number v2. The backup cluster is waiting to receive a message with version number v3. Then, it consumes the third message (message three). For the insertion request A, the version verification module checks whether the data already exists. Since the data already exists, the message is rejected. Similarly, if the third message updates to C with version number v4, the verification will find that the version number is outdated and the verification will fail. After these three messages are consumed, the data in the primary and backup clusters will remain consistent.

[0057] Through the above steps, this application provides a data synchronization method between clusters. After a business activity, the business data generated by the activity, carrying a version number, is sent to the primary cluster. A business message is generated based on the business data and sent to a message queue. A consumer program then retrieves the business message from the message queue. The consumer program verifies the version number of the business message to determine if it is a business message to be received by the backup cluster. Only after the version verification passes is the corresponding business data parsed from the business message and synchronized to the backup cluster to complete the business synchronization. This version verification mechanism ensures that business messages are synchronized only when the version number verification passes, solving the data inconsistency problem caused by out-of-order messages during transmission, improving the accuracy of data in the backup cluster, and saving redundant time by sending each generated business message directly to the message queue without retrieving it from the primary cluster.

[0058] Furthermore, to facilitate the verification of business messages, the existing configuration of storing business messages in the main cluster was retained. However, a message deletion module was added to the devices performing data synchronization. Based on the feedback results of each successful synchronization and version lag, the corresponding business messages in the main cluster were deleted, avoiding message redundancy and improving the business message management capabilities of the main cluster. Subsequently, an independent retransmission module was added to the devices performing data synchronization. This allows business messages to be retransmitted even when the message queue lacks a retransmission mechanism, expanding the selection range of message queue components and reducing the technical difficulty for developers implementing this solution.

[0059] like Figure 6 As shown, this embodiment also provides a data synchronization device between clusters, the device comprising:

[0060] The local transaction module 101 is used to send business data carrying version numbers generated by business activities to the main cluster, generate corresponding business messages for the business data, and then send the business messages to the message queue. The version number is a value extracted from a preset version number sequence. The business activity, the generation of business data, the storage of business data in the main cluster, the creation of business messages, and the sending of business messages constitute a local transaction. For details, please refer to the relevant description of step S101 in the above method embodiment, which will not be repeated here.

[0061] The version verification module 102 is used to retrieve the business message from the message queue and verify whether the business message is the target business message corresponding to the business data to be received by the backup cluster based on the version number of the business message. For details, please refer to the relevant description of step S102 in the above method embodiment, which will not be repeated here.

[0062] The request sending module 103 is used to parse the business data from the business message if the verification passes, and then send the business data to the backup cluster for storage. For details, please refer to the relevant description of step S103 in the above method embodiment, which will not be repeated here.

[0063] Specifically, in one embodiment, a data synchronization device for inter-cluster operations further includes:

[0064] The message redeployment module is used to notify the message queue to redeploy business messages when verification fails or when the version number indicates that the business message version is outdated.

[0065] This invention provides a data synchronization device for inter-cluster operations, used to execute the data synchronization method for inter-cluster operations provided in the above embodiments. Its implementation and principle are the same, and detailed descriptions can be found in the relevant descriptions of the above method embodiments, which will not be repeated here.

[0066] Through the coordinated operation of the aforementioned components, this application provides a data synchronization device for inter-cluster operations.

[0067] After a business activity, the generated business data is sent to the primary cluster. A business message is generated based on this data, carrying a version number, and sent to a message queue. A consumer program then retrieves the message from the queue and verifies its version number to determine if it's a message the backup cluster needs to receive. Only after successful version verification is the corresponding business data parsed and synchronized to the backup cluster, completing the business synchronization. This version verification mechanism ensures that synchronization is only completed when the version number verification is successful, resolving data inconsistency issues caused by out-of-order message transmission, improving the accuracy of data in the backup cluster, and saving time by sending each generated business message directly to the message queue without retrieving it from the primary cluster.

[0068] Furthermore, to facilitate the verification of business messages, the existing configuration of storing business messages in the main cluster was retained. However, a message deletion module was added to the devices performing data synchronization. Based on the feedback results of each successful synchronization and version lag, the corresponding business messages in the main cluster were deleted, avoiding message redundancy and improving the business message management capabilities of the main cluster. Subsequently, an independent retransmission module was added to the devices performing data synchronization. This allows business messages to be retransmitted even when the message queue lacks a retransmission mechanism, expanding the selection range of message queue components and reducing the technical difficulty for developers implementing this solution.

[0069] Figure 7An electronic device according to an embodiment of the present invention is shown. The device includes a processor 901 and a memory 902, which can be connected via a bus or other means. Figure 7 Taking the example of a connection between China and Israel via a bus.

[0070] Processor 901 can be a Central Processing Unit (CPU). Processor 901 can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0071] The memory 902, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the methods in the above method embodiments. The processor 901 executes various functional applications and data processing of the processor by running the non-transitory software programs, instructions, and modules stored in the memory 902, thereby implementing the methods in the above method embodiments.

[0072] The memory 902 may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor 901, etc. Furthermore, the memory 902 may include high-speed random access memory and may also include non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory 902 may optionally include memory remotely located relative to the processor 901, and these remote memories may be connected to the processor 901 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0073] One or more modules are stored in memory 902, and when executed by processor 901, they perform the methods described in the above method embodiments.

[0074] The specific details of the aforementioned electronic device can be understood by referring to the relevant descriptions and effects in the above method embodiments, and will not be repeated here.

[0075] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The implemented program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. The storage medium can be a magnetic disk, optical disk, read-only memory (ROM), random access memory (RAM), flash memory, hard disk drive (HDD), or solid-state drive (SSD), etc.; the storage medium can also include combinations of the above types of memory.

[0076] Although embodiments of the invention have been described in conjunction with the accompanying drawings, those skilled in the art can make various modifications and variations without departing from the spirit and scope of the invention, and such modifications and variations all fall within the scope defined by the appended claims.

Claims

1. A data synchronization method between clusters, characterized in that, The method includes: The business activity generates business data carrying a version number, which is then sent to the main cluster. A corresponding business message for the business data is generated, and the business message is then sent to a message queue. The version number is a value taken from a preset version number sequence. The business activity, the generation of the business data, the storage of the business data in the main cluster, the creation of the business message, and the sending of the business message constitute a local transaction. Simultaneously with sending the business message to the message queue, the business message is also sent to the main cluster. The service message is retrieved from the message queue, and its version number is used to verify whether it is the target service message corresponding to the service data currently to be received by the backup cluster. This verification includes: determining whether there is service data in the backup cluster that corresponds to the same execution object as the service message; if not, the verification passes, and the service message is used as the target service message, where the execution object is the external user performing the service activity; if so, determining whether the version number of the service message and the version number of the service data corresponding to the same execution object in the backup cluster conform to a preset order, where the preset order is the order of the version number sequence; if they conform to the preset order, the verification passes, and the service message is used as the target service message; if they do not conform to the preset order, the verification fails. If the verification passes, the business data is parsed from the business message and sent to the backup cluster for storage. If the verification fails, and the version number indicates that the service message version is ahead of the time, the message queue is notified to redeploy the service message. The message deletion module deletes business messages that have passed verification and those that have been verified as outdated from the main cluster.

2. The method according to claim 1, characterized in that, The method further includes: The first business message in the main cluster that has a duration exceeding a preset time length is sent to the message queue through an independent retransmission module for redeployment of the business message; The independent retransmission module resets the duration of the first service message and updates the number of times the first service message has been sent.

3. The method according to claim 1, characterized in that, The step of sending business data carrying a version number generated by business activities to the main cluster, generating a corresponding business message for the business data, and then sending the business message to the message queue includes: If the business activity fails to execute, the current data synchronization process will be exited, and the external user will be notified to re-initiate the instruction to execute the business activity. If the business activity is executed successfully, the business data carrying the version number generated by the business activity will be sent to the main cluster; If the business data fails to be stored in the main cluster, the current data synchronization process will be exited, and the external user will be notified to re-initiate the instruction to execute the business activity. If the business data is successfully stored in the main cluster, then the business message corresponding to the business data is created; If the creation of the business message fails, the execution of the business activity is cancelled, the current data synchronization process is exited, and the external user is notified to re-initiate the instruction to execute the business activity. If the business message is created successfully, the business message will be sent to the message queue. If the business message fails to be sent, the business data will be withdrawn from the main cluster, the current data synchronization process will be exited, and the external user will be notified to re-initiate the instruction to execute the business activity.

4. A data synchronization device for inter-cluster data, characterized in that, The device includes: The local transaction module is used to send business data carrying a version number generated by a business activity to the main cluster, generate a corresponding business message for the business data, and then send the business message to a message queue. The version number is a value taken from a preset version number sequence. The business activity, the generation of the business data, the storage of the business data in the main cluster, the creation of the business message, and the sending of the business message constitute a local transaction. Simultaneously with sending the business message to the message queue, the module also sends the business message to the main cluster. The version verification module is used to retrieve the business message from the message queue and verify whether the business message is the target business message corresponding to the business data to be received by the backup cluster based on the version number of the business message. The verification based on the version number of the business message includes: determining whether there is business data in the backup cluster that corresponds to the same execution object as the business message; if not, the verification passes, and the business message is used as the target business message, where the execution object is the external user performing the business activity; if so, determining whether the version number of the business message and the version number of the business data corresponding to the same execution object in the backup cluster conform to a preset order, where the preset order is the order of the version number sequence; if they conform to the preset order, the verification passes, and the business message is used as the target business message; if they do not conform to the preset order, the verification fails. The request sending module is used to parse the business data from the business message if the verification passes, and send the business data to the backup cluster for storage; The message redeployment module is used to notify the message queue to redeploy the business message when the verification fails and when the version number indicates that the business message version is ahead of the time. The message deletion module is used to delete business messages that have passed verification and those that have been verified as outdated from the main cluster.

5. An electronic device, characterized in that, include: A memory and a processor, the memory and the processor being communicatively connected to each other, the memory storing computer instructions, the processor executing the computer instructions to perform the method as described in any one of claims 1-3.

6. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions for causing the computer to perform the method as described in any one of claims 1-3.

Images