Synchronization method, apparatus, device, medium, and program product in distributed system

Abstract

The application provides a synchronization method, device and equipment in a distributed system, a computer readable storage medium and a computer program product; the distributed system comprises at least one coordination server and at least two transfer servers; the method comprises the following steps: in response to a synchronization instruction for a target transaction, sending a synchronization request for the target transaction to each transfer server; receiving response information returned by each transfer server for the synchronization request, the response information being used for feeding back a pre-synchronization result of the corresponding transfer server for the target transaction; wherein the pre-synchronization result is used for indicating that the pre-synchronization for the target transaction is successful or failed; based on the pre-synchronization result of each transfer server fed back by the response information, determining the type of a synchronization processing request, and sending the synchronization processing request of the type to each transfer server, so that each transfer server performs a synchronization processing operation of a corresponding type for the target transaction based on the synchronization processing request of the type.

Description

Technical Field

[0001] This application relates to the fields of Internet and database technology, and in particular to a synchronization method, apparatus, device, computer-readable storage medium, and computer program product in a distributed system. Background Technology

[0002] In the fields of Internet and database technology, the synchronization processing methods in distributed systems (such as ZooKeeper, which includes at least one coordinating server and at least two relay servers) mostly utilize ZooKeeper's ephemeral nodes and watch notification mechanism. This approach works well in most scenarios, but it is highly dependent on ZooKeeper's watch notification mechanism. It needs to ensure that all relay servers can successfully receive the route update notification. Once a watch notification anomaly occurs, it will cause some relay servers to update the route while others do not, resulting in route inconsistency among the relay servers.

[0003] In practical applications, network instability, packet loss, and disconnection and reconnection may cause Watch notifications to fail to reach the relay server. Therefore, under some extreme network anomalies, there is a small probability of routing inconsistencies, which would be a major disaster for stateful backend services. Summary of the Invention

[0004] This application provides a synchronization method, apparatus, device, computer-readable storage medium, and computer program product in a distributed system, which can improve the consistency of synchronization in a distributed system.

[0005] The technical solution of this application embodiment is implemented as follows: This application provides a synchronization method in a distributed system, the distributed system including at least one coordinating server and at least two relay servers, the method comprising: In response to a synchronization instruction for a target transaction, the coordinating server sends a synchronization request for the target transaction to each of the relay servers; The system receives response information from each of the relay servers in response to the synchronization request. The response information is used to provide feedback on the pre-synchronization results of the corresponding relay server for the target transaction. The pre-synchronization result is used to indicate whether the pre-synchronization for the target transaction was successful or failed. Based on the pre-synchronization results of each of the relay servers in the response information feedback, the type of synchronization processing request is determined, and the type of synchronization processing request is sent to each of the relay servers, so that each of the relay servers performs the corresponding type of synchronization processing operation for the target transaction based on the type of synchronization processing request.

[0006] This application provides a synchronization device in a distributed system, the distributed system including at least one coordinating server and at least two relay servers, the device comprising: The first sending module is used to respond to a synchronization instruction for a target transaction, wherein the coordinating server sends a synchronization request for the target transaction to each of the relay servers; A response receiving module is used to receive response information returned by each of the relay servers in response to the synchronization request. The response information is used to provide feedback on the pre-synchronization result of the corresponding relay server for the target transaction. The pre-synchronization result is used to indicate whether the pre-synchronization for the target transaction was successful or failed. The second sending module is used to determine the type of synchronization processing request based on the pre-synchronization results of each of the relay servers fed back by the response information, and send the type of synchronization processing request to each of the relay servers, so that each of the relay servers performs the corresponding type of synchronization processing operation for the target transaction based on the type of synchronization processing request.

[0007] In the above scheme, the first sending module is further configured to have the coordination server generate a synchronization request for the target transaction indicated by the synchronization instruction, and send the synchronization request to each of the relay servers, so that each of the relay servers determines the pre-synchronization result corresponding to the synchronization request based on the synchronization request, and determines response information based on each of the pre-synchronization results, so as to return the response information to the coordination server.

[0008] In the above scheme, the device further includes a relay server execution module, which is used to perform the following operations when the synchronization instruction instructs to synchronize the target data in the target transaction: when the relay server obtains synchronized data by synchronizing the target data based on the synchronization request, it determines a pre-synchronization result indicating successful pre-synchronization of the target data and stores the synchronized data in temporary memory; when the relay server fails to obtain synchronized data by synchronizing the target data based on the synchronization request, it determines a pre-synchronization result indicating failed pre-synchronization of the target data.

[0009] In the above scheme, the relay server execution module is further configured to perform the following operations when the synchronization instruction indicates capacity synchronization of the resource capacity in the target transaction: when the relay server queries the updated capacity list based on the synchronization request, it determines a pre-synchronization result indicating successful pre-synchronization of the resource capacity and stores the updated capacity list in temporary memory; when the relay server cannot query the updated capacity list based on the synchronization request, it determines a pre-synchronization result indicating failed pre-synchronization of the resource capacity.

[0010] In the above scheme, the relay server execution module is further configured to, when the pre-synchronization result indicates that the pre-synchronization for the target transaction is successful, register a pre-synchronization node for indicating successful pre-synchronization on the corresponding relay server; each relay server selects a master relay server from the at least two relay servers; the master relay server detects the number of registered pre-synchronization nodes and compares the number of pre-synchronization nodes with the number of relay servers to determine the response information based on the comparison result, and returns the response information to the coordination server.

[0011] In the above scheme, the relay server execution module is further used to register a corresponding temporary sequence node for each relay server, obtain a number of temporary sequence nodes consistent with the number of relay servers, and the sequence number of the temporary sequence node is auto-incrementing; based on the sequence number of the temporary sequence node, select the first temporary sequence node with the smallest sequence number from the number of temporary sequence nodes, and determine the relay server corresponding to the selected first temporary sequence node as the main relay server.

[0012] In the above scheme, the relay server execution module is further configured to select a second temporary sequence node adjacent to the first temporary sequence node when the relay server corresponding to the selected first temporary sequence node fails; determine the relay server corresponding to the selected second temporary sequence node as the main relay server; and delete the failed relay server and the first temporary sequence node.

[0013] In the above scheme, the second sending module is further configured to determine the type of the synchronization processing request as synchronization submission when the response information feedback indicates that the pre-synchronization results of each of the relay servers are all successful; and to determine the type of the synchronization processing request as synchronization rollback when the response information feedback indicates that the pre-synchronization result of at least one of the at least two relay servers is a pre-synchronization failure.

[0014] In the above scheme, the second sending module is further configured to send a synchronous commit request to each of the relay servers when the type of the synchronous processing request is synchronous commit, so that each of the relay servers performs a synchronous commit operation on the target transaction based on the synchronous commit request; and to send a synchronous rollback request to each of the relay servers when the type of the synchronous processing request is synchronous rollback, so that each of the relay servers performs a synchronous rollback operation on the target transaction based on the synchronous rollback request.

[0015] In the above scheme, the second sending module is further configured to send a synchronization commit request to each of the relay servers when the synchronization instruction indicates data synchronization of the target data in the target transaction, so that each of the relay servers can obtain the synchronization data obtained by synchronizing the target data from the temporary memory based on the synchronization commit request, replace the target data with the synchronization data, and back up the target data; and send a synchronization commit request to each of the relay servers when the synchronization instruction indicates capacity synchronization of the resource capacity in the target transaction, so that each of the relay servers can obtain the updated capacity list from the temporary memory based on the synchronization commit request, replace the original capacity list with the updated capacity list, and back up the original capacity list.

[0016] In the above scheme, the second sending module is further configured to send a synchronization rollback request to the at least two relay servers when the synchronization instruction indicates data synchronization of the target data in the target transaction, so that the other relay servers among the at least two relay servers, except for the relay server whose synchronization result is synchronization failure, delete the synchronized data obtained by synchronizing the target data from the temporary memory based on the synchronization rollback request; and to send a synchronization rollback request to each of the relay servers when the synchronization instruction indicates capacity synchronization of the resource capacity in the target transaction, so that the other relay servers among the at least two relay servers, except for the relay server whose synchronization result is synchronization failure, delete the updated capacity list from the temporary memory based on the synchronization rollback request, and retain the original capacity list.

[0017] In the above scheme, after sending the synchronization commit request to each of the relay servers, the device further includes: a third sending module, used to update the synchronization status corresponding to the target transaction to a commit status; obtain the duration of the commit status, and within the duration, detect the feedback information of each of the relay servers in response to the synchronization commit request; wherein the feedback information is used to provide the synchronization commit result of the corresponding relay server for the target transaction, and the synchronization commit result is used to indicate whether the synchronization commit for the target transaction was successful or failed; when the duration exceeds the target duration and the feedback information indicates that the synchronization commit result of at least one of the at least two relay servers is a synchronization commit failure, a synchronization rollback request is sent to each of the relay servers, so that each of the relay servers performs a synchronization rollback operation for the target transaction based on the synchronization rollback request.

[0018] This application provides an electronic device, including: Memory, used to store executable instructions; The processor, when executing executable instructions stored in the memory, implements the synchronization method in the distributed system provided in the embodiments of this application.

[0019] This application provides a computer-readable storage medium storing executable instructions for inducing a processor to execute and implement the synchronization method in the distributed system provided in this application.

[0020] This application provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement the synchronization method in the distributed system provided in this application.

[0021] The embodiments of this application have the following beneficial effects: In the embodiments of this application, when synchronizing a target transaction, a coordination server in the distributed system sends a synchronization request for the target transaction to each relay server. Based on the pre-synchronization result in the response information returned by each relay server for the synchronization request, the type of synchronization processing request is determined, and a corresponding type of synchronization processing request is sent to each relay server, so that each relay server performs the corresponding type of synchronization processing operation for the target transaction. In this way, the synchronization processing operation performed by each relay server for the target transaction is always the same type of synchronization processing operation, ensuring the synchronization consistency of all relay servers for the target transaction. Attached Figure Description

[0022] Figure 1 A schematic diagram of the architecture of a synchronization system 100 in a distributed system provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of the electronic device 500 provided in the embodiments of this application; Figure 3 A flowchart illustrating a synchronization method in a distributed system provided in an embodiment of this application; Figure 4 This is a schematic diagram of the architecture of a synchronization system in a distributed system provided in an embodiment of this application; Figure 5 A schematic diagram of the architecture of the ZK routing data model provided in the embodiments of this application; Figure 6 This is a schematic diagram of the architecture of a synchronization system in a distributed system provided in an embodiment of this application; Figure 7 This is a schematic diagram of the data structure provided for an embodiment of this application; Figure 8 This is a schematic diagram of the data structure provided for an embodiment of this application; Figure 9 This is a schematic diagram of the data structure provided for an embodiment of this application; Figure 10 This is a schematic diagram of the state detection method provided in the embodiments of this application; Figure 11 A selection view of the main node provided in an embodiment of this application; Figure 12 This is a schematic diagram of the data structure provided for an embodiment of this application. Detailed Implementation

[0023] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0024] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0025] In the following description, the terms “first, second…” are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that “first, second…” may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application belongs. The terminology used herein is for the purpose of describing embodiments of this application only and is not intended to limit this application.

[0027] See Figure 1 , Figure 1 This is a schematic diagram of the architecture of a synchronization system 100 in a distributed system provided in this application embodiment. To support an exemplary application, the synchronization system in the distributed system may include at least one terminal, at least one coordination server, and at least two relay servers. The terminal is equipped with a client for executing a target transaction. The client corresponds to a business server for sending synchronization instructions for the target transaction. When a user triggers a synchronization instruction for the target transaction through the client, the business server sends the synchronization instruction to the coordination server. Upon receiving the synchronization instruction, the coordination server responds by sending a synchronization request for the target transaction to each relay server, causing each relay server to execute the synchronization operation requested in the synchronization request and return response information for the synchronization request. The response information is used to provide feedback on the pre-synchronization result of the corresponding relay server for the target transaction; the pre-synchronization result indicates whether the pre-synchronization for the target transaction was successful or failed. Based on the pre-synchronization results of each relay server provided in the response information, the coordination server determines the type of synchronization processing request and sends the determined type of synchronization processing request to each relay server. Each relay server performs the corresponding type of synchronization processing operation for the target transaction based on the received type of synchronization processing request.

[0028] In practical applications, servers such as coordination servers and relay servers can be physical machines, or virtual machines, containers, etc., deployed on physical machines. Physical machines are devices with data processing capabilities, such as terminals or servers. Servers can be independent physical servers, server clusters or distributed systems composed of multiple physical servers, or cloud servers providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, CDN, and big data and artificial intelligence platforms. Terminals can be smartphones, tablets, laptops, desktop computers, smart speakers, smartwatches, etc., but are not limited to these. Terminals and servers can be connected directly or indirectly through wired or wireless communication methods, which is not limited herein.

[0029] See Figure 2 , Figure 2 This is a schematic diagram of the structure of the electronic device 500 provided in the embodiments of this application. In practical applications, the electronic device 500 can be... Figure 1The terminals, coordination servers, and relay servers in the system are based on electronic devices. Figure 1 Taking the coordination server shown as an example, an electronic device implementing the synchronization method in a distributed system according to the embodiments of this application will be described. Figure 2 The illustrated electronic device 500 includes at least one processor 510, a memory 550, at least one network interface 520, and a user interface 530. The various components in the electronic device 500 are coupled together via a bus system 540. It is understood that the bus system 540 is used to implement communication between these components. In addition to a data bus, the bus system 540 also includes a power bus, a control bus, and a status signal bus. However, for clarity, ... Figure 2 The general labeled all buses as Bus System 540.

[0030] The processor 510 can be an integrated circuit chip with signal processing capabilities, such as a general-purpose processor, a digital signal processor (DSP), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor, etc.

[0031] User interface 530 includes one or more output devices 531 that enable the presentation of media content, including one or more speakers and / or one or more visual displays. User interface 530 also includes one or more input devices 532, including user interface components that facilitate user input, such as a keyboard, mouse, microphone, touch screen display, camera, other input buttons and controls.

[0032] The memory 550 may be removable, non-removable, or a combination thereof. Exemplary hardware devices include solid-state storage, hard disk drives, optical disk drives, etc. The memory 550 may optionally include one or more storage devices physically located away from the processor 510.

[0033] The memory 550 may include volatile memory or non-volatile memory, or both. The non-volatile memory may be read-only memory (ROM), and the volatile memory may be random access memory (RAM). The memory 550 described in this application embodiment is intended to include any suitable type of memory.

[0034] In some embodiments, memory 550 is capable of storing data to support various operations, examples of which include programs, modules, and data structures or subsets or supersets thereof, as illustrated below.

[0035] Operating system 551 includes system programs for handling various basic system services and performing hardware-related tasks, such as framework layer, core library layer, driver layer, etc., for implementing various basic business functions and handling hardware-based tasks; network communication module 552 is used to reach other computing devices via one or more (wired or wireless) network interfaces 520, exemplary network interfaces 520 include: Bluetooth, WiFi, and Universal Serial Bus (USB), etc.; presentation module 553 is used to enable the presentation of information (e.g., user interface for operating peripheral devices and displaying content and information) via one or more output devices 531 associated with user interface 530 (e.g., display screen, speaker, etc.); input processing module 554 is used to detect and translate one or more user inputs or interactions from one or more input devices 532.

[0036] In some embodiments, the synchronization device in the distributed system provided in this application can be implemented in software. Figure 2 A synchronization device 555 in a distributed system stored in memory 550 is shown. It can be software in the form of programs and plug-ins, including the following software modules: a first sending module 5551, a response receiving module 5552, and a second sending module 5553. These modules are logical and can therefore be arbitrarily combined or further divided according to the functions they implement. The functions of each module will be described below.

[0037] In other embodiments, the synchronization device in the distributed system provided in this application can be implemented in hardware. As an example, the synchronization device in the distributed system provided in this application can be a processor in the form of a hardware decoding processor, which is programmed to execute the synchronization method in the distributed system provided in this application. For example, the processor in the form of a hardware decoding processor can be one or more application-specific integrated circuits (ASICs), DSPs, programmable logic devices (PLDs), complex programmable logic devices (CPLDs), field-programmable gate arrays (FPGAs), or other electronic components.

[0038] Based on the above description of the synchronization system and electronic device in the distributed system provided in the embodiments of this application, the synchronization method in the distributed system provided in the embodiments of this application will be described below. In actual implementation, this method can be... Figure 1 The coordination server shown can be implemented independently, or it can be... Figure 1 The coordination server and each relay server are shown working together. The following will combine... Figure 1 and Figure 3 , Figure 3 This is a flowchart illustrating a synchronization method in a distributed system provided in an embodiment of this application. Figure 1 The following example illustrates how the coordination server and each relay server (assuming there are N servers, where N is greater than or equal to 2) work together to implement the synchronization method in the distributed system provided in this application.

[0039] In step 101, the coordinating server responds to the synchronization instruction for the target transaction by sending a synchronization request for the target transaction to each relay server.

[0040] Here, a transaction is a logical unit in the execution process of a database management system, consisting of a finite sequence of database operations. To ensure data correctness and reliability, transactions must possess four properties: atomicity, consistency, isolation, and durability. Atomicity means that all operations within a transaction either complete entirely or not at all; it will not end at any intermediate stage. If an error occurs during the execution of a transaction, it will be rolled back to the state before the transaction began. Consistency means that the integrity of the database is not compromised before and after a transaction begins. Isolation means that the database allows multiple concurrent transactions to read, write, and modify data simultaneously, preventing inconsistencies caused by overlapping execution of multiple transactions. Durability means that once a transaction is completed, the changes to the data are permanent and will not be lost even in the event of a system failure.

[0041] In the transaction processing of a distributed system, when a transaction needs to be executed by multiple relay servers, in order to ensure the above-mentioned transaction characteristics, a coordinating server is required to assume the coordinating role during the execution of the target transaction, in order to manage the synchronization results of the synchronization requests of each relay server for the target transaction.

[0042] In practical applications, the terminal is equipped with a client that executes the target transaction. The client corresponds to a business server that sends synchronization instructions for the target transaction. When a user triggers a synchronization instruction for the target transaction through the client, the business server sends the synchronization instruction to the coordination server. After receiving the synchronization instruction, the coordination server responds by sending a synchronization request for the target transaction to each relay server to request whether each relay server should perform a synchronization operation on the target transaction, and waits for the response results from each relay server for the synchronization request.

[0043] In step 102, each relay server determines the pre-synchronization result of the corresponding synchronization request based on the synchronization request, and determines the response information based on each pre-synchronization result, so as to return the response information to the coordination server.

[0044] Here, after receiving the synchronization request from the coordinating server, the relay server determines whether to perform a pre-synchronization operation on the target transaction to obtain the corresponding pre-synchronization result and feed it back to the coordinating server. If it determines to perform a pre-synchronization operation on the target transaction, it feeds back the successful pre-synchronization result to the coordinating server; if the relay server cannot receive the synchronization request or cannot perform a pre-synchronization operation on the target transaction, it feeds back the failed pre-synchronization result to the coordinating server.

[0045] In some embodiments, each relay server may determine the pre-synchronization result of the corresponding synchronization request based on the synchronization request in the following manner: when the synchronization instruction indicates that the target data in the target transaction should be synchronized, each relay server shall perform the following operations: when the relay server obtains synchronized data by synchronizing the target data based on the synchronization request, it shall determine a pre-synchronization result indicating that the pre-synchronization of the target data was successful and store the synchronized data in temporary memory; when the relay server fails to obtain synchronized data by synchronizing the target data based on the synchronization request, it shall determine a pre-synchronization result indicating that the pre-synchronization of the target data failed.

[0046] As an example, when a synchronization command instructs the synchronization of target data in a target transaction, each relay server that successfully receives the synchronization request executes its own synchronization request for the target transaction. This includes performing the synchronization operation requested in the synchronization request to update the target data and obtain the synchronized data. In this case, the pre-synchronization result is considered successful, and a pre-synchronization success response is sent to the coordinating server. It should be noted that in this situation, the target data is not replaced with synchronized data; instead, the synchronized data is temporarily stored in temporary memory for subsequent actual synchronization commit operations. If a relay server fails to receive the synchronization request or cannot successfully obtain the synchronized data based on the target data requested in the synchronization request, the pre-synchronization result is considered failed, and a pre-synchronization failure response is sent to the coordinating server.

[0047] In some embodiments, each relay server may determine the pre-synchronization result of the corresponding synchronization request based on the synchronization request in the following manner: when the synchronization instruction indicates capacity synchronization of the resource capacity in the target transaction, each relay server performs the following operations respectively: when the relay server finds the updated capacity list based on the synchronization request, it determines the pre-synchronization result indicating the success of the pre-synchronization of the resource capacity and stores the updated capacity list in temporary memory; when the relay server cannot find the updated capacity list based on the synchronization request, it determines the pre-synchronization result indicating the failure of the pre-synchronization of the resource capacity.

[0048] As an example, when a synchronization command instructs to synchronize the resource capacity in a target transaction (e.g., scaling up or down), each relay server that successfully receives the synchronization request executes its own synchronization request for the target transaction, such as querying and fetching the latest updated capacity list. This indicates a successful pre-synchronization, and a successful pre-synchronization response is sent to the coordinating server. It's important to note that in this case, the fetched updated capacity list does not replace the original capacity list; instead, it is temporarily stored in temporary memory for later synchronization commit operations. If a relay server fails to receive the synchronization request or cannot successfully fetch the updated capacity list, the pre-synchronization result is a pre-synchronization failure, and a pre-synchronization failure response is sent to the coordinating server.

[0049] In some embodiments, each relay server may determine response information based on each pre-synchronization result in the following manner, and return the response information to the coordinating server: when the pre-synchronization result indicates that the pre-synchronization for the target transaction is successful, the corresponding relay server registers a pre-synchronization node to indicate the success of the pre-synchronization; each relay server selects a master relay server from at least two relay servers; the master relay server detects the number of registered pre-synchronization nodes and compares the number of pre-synchronization nodes with the number of relay servers to determine the response information based on the comparison result, and returns the response information to the coordinating server.

[0050] Here, when a relay server receives a successful pre-synchronization result based on a synchronization request, it can register pre-synchronization nodes to indicate successful pre-synchronization. Each relay server can select a master relay server from all relay servers to detect the pre-synchronization nodes, using the number of pre-synchronization nodes to indicate the number of relay servers with successful pre-synchronization. When the number of pre-synchronization nodes detected by the master relay server is equal to the number of relay servers, it indicates that all relay servers have received successful pre-synchronization results based on the synchronization request, and the response information used to report the pre-synchronization results of each relay server is determined to be successful. When the number of pre-synchronization nodes detected by the master relay server is less than the number of relay servers, it indicates that some relay servers have not received successful pre-synchronization results based on the synchronization request, and the response information used to report that not all pre-synchronization results of each relay server are successful (i.e., some relay servers have failed pre-synchronization) is determined. After determining the response message, the coordination server performs subsequent operations based on the response information.

[0051] In some embodiments, each relay server selects a primary relay server from at least two relay servers in the following manner: each relay server registers a corresponding temporary sequence node to obtain a number of temporary sequence nodes consistent with the number of relay servers, wherein the sequence number of the temporary sequence node is auto-incrementing; based on the sequence number of the temporary sequence node, the first temporary sequence node with the smallest sequence number is selected from the corresponding number of temporary sequence nodes, and the relay server corresponding to the selected first temporary sequence node is determined as the primary relay server.

[0052] Here, each relay server corresponds to a temporary sequence node. Assuming there are 4 relay servers, the corresponding temporary sequence nodes can be registered randomly for each relay server. For example, relay server 1 corresponds to temporary sequence node 1, relay server 2 corresponds to temporary sequence node 2, relay server 3 corresponds to temporary sequence node 3, and relay server 4 corresponds to temporary sequence node 4. The temporary sequence node with the smallest or largest temporary sequence node can be selected from the 4 temporary sequence nodes as the first temporary sequence node, and the relay server corresponding to the selected first temporary sequence node is determined as the main relay server. For example, if the first temporary sequence node is temporary sequence node 1, relay server 1 is determined as the main relay server so that relay server 1 can detect the pre-synchronization status of these 4 relay servers (whether the pre-synchronization is successful and whether a pre-synchronization node has been registered).

[0053] In some embodiments, when the relay server corresponding to the selected first temporary sequence node fails, a second temporary sequence node adjacent to the first temporary sequence node is selected; the relay server corresponding to the selected second temporary sequence node is determined as the main relay server, and the failed relay server and the first temporary sequence node are deleted.

[0054] Here, when the designated primary relay server fails, another relay server can be replaced as the primary relay server. Taking the above four relay servers as an example, after relay server 1 is designated as the primary relay server, if relay server 1 fails, relay server 1 and temporary sequence node 1 are deleted, and relay server 2 corresponding to temporary sequence node 2 can be selected as the primary relay server; after relay server 4 is designated as the primary relay server, if relay server 4 fails, relay server 4 and temporary sequence node 4 are deleted, and relay server 1 corresponding to temporary sequence node 1 can be selected as the primary relay server.

[0055] It should be noted that in practical applications, the selected master relay server can be used as the coordinating server. That is, the coordinating server can detect the status of each relay server to simplify the overall architecture and reduce the overall complexity.

[0056] In step 103, the coordination server receives response information from each relay server in response to the synchronization request.

[0057] The response information is used to provide feedback on the pre-synchronization result of the corresponding relay server for the target transaction. The pre-synchronization result is used to indicate whether the pre-synchronization for the target transaction was successful or failed.

[0058] In step 104, the coordination server determines the type of synchronization processing request based on the pre-synchronization results of each relay server in the response information feedback, and sends the determined type of synchronization processing request to each relay server.

[0059] In step 105, each relay server performs the corresponding type of synchronization processing operation for the target transaction based on the determined type of synchronization processing request.

[0060] In some embodiments, the coordination server can determine the type of synchronization processing request based on the pre-synchronization results of each relay server in the response information as follows: when the pre-synchronization results of each relay server in the response information are all successful, the type of synchronization processing request is determined to be synchronization submission; when the pre-synchronization result of at least one of the at least two relay servers in the response information is pre-synchronization failure, the type of synchronization processing request is determined to be synchronization rollback.

[0061] Here, when all relay servers obtain a successful pre-synchronization result based on the synchronization request, the type of the synchronization processing request is determined to be synchronization commit, so that the actual synchronization operation is performed on the target transaction. When some relay servers do not obtain a successful pre-synchronization result based on the synchronization request (i.e., at least one relay server's pre-synchronization result is pre-synchronization failure), the type of the synchronization processing request is determined to be synchronization rollback, so that the actual synchronization operation is not performed on the target transaction, allowing the target transaction to remain unchanged.

[0062] In some embodiments, the coordinating server may send a determined type of synchronization processing request to each relay server in the following manner, so that each relay server performs a corresponding type of synchronization processing operation for the target transaction based on the determined type of synchronization processing request: when the type of the synchronization processing request is synchronization commit, a synchronization commit request is sent to each relay server, so that each relay server performs a synchronization commit operation for the target transaction based on the synchronization commit request; when the type of the synchronization processing request is synchronization rollback, a synchronization rollback request is sent to each relay server, so that each relay server performs a synchronization rollback operation for the target transaction based on the synchronization rollback request.

[0063] Here, when the determined type of the synchronization processing request is synchronous commit, after the coordinating server sends the synchronous commit request to each relay server, each relay server can perform a real synchronous commit operation on the target transaction based on the synchronous commit request, so that each relay server updates the target transaction synchronously together, ensuring the synchronization consistency (such as data consistency, capacity consistency, etc.) of the target transaction in each relay server; when the determined type of the synchronization processing request is synchronous rollback, after the coordinating server sends the synchronous rollback request to each relay server, each relay server does not perform a real synchronous commit operation on the target transaction based on the synchronous rollback request, but keeps it as is, also ensuring the synchronization consistency (such as data consistency, capacity consistency, etc.) of the target transaction in each relay server.

[0064] In some embodiments, the coordinating server may send synchronization commit requests to each relay server in the following manner, so that each relay server performs a synchronization commit operation on the target transaction based on the synchronization commit request: when the synchronization instruction indicates that the target data in the target transaction is synchronized, the coordinating server sends a synchronization commit request to each relay server, so that each relay server obtains the synchronized data obtained by synchronizing the target data from temporary memory based on the synchronization commit request, replaces the target data with the synchronized data, and backs up the target data; when the synchronization instruction indicates that the resource capacity in the target transaction is synchronized, the coordinating server sends a synchronization commit request to each relay server, so that each relay server obtains an updated capacity list from temporary memory based on the synchronization commit request, replaces the original capacity list with the updated capacity list, and backs up the original capacity list.

[0065] As an example, when a synchronization command instructs to synchronize target data in a target transaction and determines that the type of synchronization request is synchronization commit, the coordinating server sends the synchronization commit request to each relay server. All relay servers, based on the synchronization commit request, retrieve the synchronization data previously stored in temporary memory and replace the original target data with the synchronization data, thus achieving a true synchronization commit operation on the target data. Similarly, when a synchronization command instructs to synchronize the resource capacity in the target transaction and determines that the type of synchronization request is synchronization commit, the coordinating server sends the synchronization commit request to each relay server. All relay servers, based on the synchronization commit request, retrieve the updated capacity list previously stored in temporary memory and replace the original capacity list, thus achieving a true synchronization commit operation on the resource capacity. In this way, all relay servers work together to synchronize and update the target transaction, ensuring synchronization consistency across all relay servers for the target transaction.

[0066] In some embodiments, the coordinating server may send synchronization rollback requests to each relay server in the following manner, so that each relay server performs a synchronization rollback operation on the target transaction based on the synchronization rollback request: when the synchronization instruction indicates that the target data in the target transaction is synchronized, a synchronization rollback request is sent to at least two relay servers, so that the other relay servers among the at least two relay servers, except for the relay server whose synchronization result is synchronization failure, delete the synchronized data obtained by synchronizing the target data from the temporary memory based on the synchronization rollback request; when the synchronization instruction indicates that the resource capacity in the target transaction is synchronized, a synchronization rollback request is sent to each relay server, so that the other relay servers among the at least two relay servers, except for the relay server whose synchronization result is synchronization failure, delete the updated capacity list from the temporary memory based on the synchronization rollback request, and retain the original capacity list.

[0067] As an example, when a synchronization command instructs the target data in a target transaction to be synchronized, and the type of the synchronization request is determined to be a synchronization rollback, the coordinating server sends the synchronization rollback request to each relay server. Based on the synchronization rollback request, all relay servers delete the previously temporarily stored synchronized data in temporary memory and retain the original target data. This does not perform a true synchronization commit operation on the target data. Conversely, when a synchronization command instructs the resource capacity in the target transaction to be synchronized, and the type of the synchronization request is determined to be a synchronization rollback, the coordinating server sends the synchronization rollback request to each relay server. Based on the synchronization rollback request, all relay servers delete the previously temporarily stored updated capacity list in temporary memory and retain the original capacity list. This achieves the goal of not performing a true synchronization commit operation on the resource capacity. Thus, all relay servers do not synchronize updates to the target transaction, ensuring synchronization consistency across all relay servers for the target transaction.

[0068] In some embodiments, after the coordinating server sends a synchronization commit request to each relay server, it updates the synchronization status of the target transaction to a commit status; it obtains the duration of the commit status and detects the feedback information of each relay server in response to the synchronization commit request within the duration; wherein, the feedback information is used to report the synchronization commit result of the corresponding relay server for the target transaction, and the synchronization commit result is used to indicate whether the synchronization commit for the target transaction was successful or failed; when the duration exceeds the target duration and the feedback information indicates that at least one of the at least two relay servers has a synchronization commit result of synchronization failure, a synchronization rollback request is sent to each relay server so that each relay server performs a synchronization rollback operation for the target transaction based on the synchronization rollback request.

[0069] Here, assuming the synchronization request type is determined to be a synchronization commit, after the coordinating server sends the synchronization commit request to each relay server, if, within the target time period, the coordinating server detects that some or all of the relay servers cannot receive the synchronization commit request or cannot perform a true synchronization commit operation for the target transaction, it will send a synchronization rollback request to each relay server. This allows each relay server to perform a synchronization rollback operation for the target transaction based on the synchronization rollback request. For example, it might delete the synchronization data previously temporarily stored in temporary memory while retaining the original target data, meaning no true synchronization commit operation was performed on the target data. Similarly, it might delete the updated capacity list previously temporarily stored in temporary memory while retaining the original capacity list, thus achieving the goal of not performing a true synchronization commit operation on the resource capacity. In this way, all relay servers together do not synchronize updates for the target transaction, ensuring synchronization consistency across all relay servers for the target transaction.

[0070] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario. Taking a synchronization method based on the ZooKeeper distributed system as an example, see [link to relevant documentation]. Figure 4 , Figure 4 This is a schematic diagram of the architecture of a synchronization system in a distributed system provided in this application embodiment. In this architecture, the ZooKeeper cluster includes multiple coordination servers. The logical layer has multiple business servers for the target transaction, such as game lobby servers lobby1 and lobby2. The relay layer has multiple relay servers, such as Router1 and Router2. The functional submodules have applications for executing various sub-functions, such as othersvr1, othersvr2, and othersvr3. If a relay server experiences routing (data) inconsistencies, it will significantly impact stateful backend services. For example, if the routing lists of the game corpsvr servers maintained by the relay servers are inconsistent, the same corps data will be cached on different game corps servers, ultimately leading to corps data overwriting each other and causing partial data rollback.

[0071] This application utilizes ZooKeeper's ephemeral nodes to ensure that the server list maintained under a ZK Node is kept alive, and that the server list maintained by each ZK server node is consistent. This is the foundation for data consistency at the business layer. Based on ZK data consistency, it is then necessary to ensure that the behavior of each router in updating data (such as the routing list) is also consistent.

[0072] See Figure 5 , Figure 5 This is a schematic diagram of the ZK routing data model provided in this application embodiment. The root node maintaining the routing list is / routema. Each module process registers a temporary ordered node under the corresponding ZK Node upon startup. For example, the lobby (game lobby server) process registers a lobby_x.xxx child node in / routemap / lobby upon startup, and there are 3 process instances. Similarly, it can be seen that the above routing table has 3 friendsvr process instances and 3 httpproxy process instances, where friendsvr corresponds to the friend server and httpproxy corresponds to the HTTP protocol access proxy server.

[0073] The game lobby server, friend server, and HTTP protocol access proxy server are all business servers used to trigger synchronization instructions for target transactions. For example, if the game lobby server has already registered three child nodes: lobby_9.0.4.1_0000000001, lobby_9.0.4.2_0000000002, and lobby_9.0.4.3_0000000003, when registering a fourth node (such as lobby_9.0.4.4_0000000004), the relevant information of the newly registered fourth node needs to be synchronized to each relay server. At this time, the relevant information of the newly registered fourth node can become the target transaction.

[0074] See Figure 6 , Figure 6 This is a schematic diagram of the architecture of a synchronization system in a distributed system provided in this application embodiment. The distributed system includes: a friends server (friendsvr), a coordinating server (ZK cluster), and three relay servers (router1, router2, and router3). The following description uses the expansion of the friends server (friendsvr) as an example to illustrate the synchronization method in the distributed system provided in this application embodiment. The method includes: Step 1: The friend server sends a synchronization command for the target node to the coordinating server. In response to the synchronization command, the coordinating server sends the synchronization request for the target node to each relay server.

[0075] Here, after friendsvr expands and registers a new node to / routemap / friendsvr, the friend server triggers and sends a corresponding synchronization command (i.e., expansion command) to the coordinating server. The coordinating server responds to the expansion command by sending an expansion request (synchronization request, used to request expansion of the newly registered node) for the target transaction to router1, router2, and router3. The target node is the newly registered node (equivalent to the target transaction mentioned above).

[0076] Step 2: The relay server responds to the synchronization request and determines the pre-synchronization result of the corresponding synchronization request.

[0077] The pre-synchronization result indicates whether the pre-scaling of the target node was successful or failed. After receiving the synchronization request, the relay server (such as router1, router2, router3) sends get_children_list to query the latest friendsvr list. When the query retrieves the latest friendsvr list (i.e., the updated capacity list), the pre-synchronization result is determined to be successful. If the relay server does not receive the synchronization request or does not retrieve the latest friendsvr list based on the synchronization request, the pre-synchronization result is determined to be failed.

[0078] It should be noted that when the pre-synchronization result of successful pre-expansion is obtained, the latest friendsvr list is stored in the temporary memory prepare_list, instead of replacing the original friendsvr list with the latest friendsvr list. Therefore, the actual routing information being used will not be updated at this time.

[0079] Step 3: The relay server determines the response information based on the pre-synchronization results and returns the response information to the coordinating server.

[0080] Here, after updating the temporary memory, the relay server sends an acknowledgment message (i.e., a response message) to the coordinating server. When the relay server receives a successful pre-synchronization result based on the synchronization request, it can register a pre-synchronization node to indicate the success of the pre-synchronization. For example, router1 registers a new prepare_x.xxx node on the / routech / friendsvr node, indicating that the router1 process has obtained the latest friendsvr list.

[0081] See Figure 7 , Figure 7 This is a schematic diagram of the data structure provided in the embodiments of this application. An example of ZKNode Data is shown below. Figure 7 As shown, the root node for maintaining state changes is / routechg. When the three relay servers router1, router2, and router3 have all successfully pre-synchronized with the target node, they register the prepare_9.0.20.1, prepare_9.0.20.2, and prepare_9.0.20.3 nodes respectively.

[0082] Step 4: Based on the pre-synchronization results of each relay server in the response information, the coordination server determines the type of synchronization processing request and sends the determined type of synchronization processing request to each relay server.

[0083] Here, after receiving the response information, the coordination server checks the pre-synchronization nodes of each relay server to indicate the number of relay servers that have successfully pre-synchronized. When the number of pre-synchronization nodes detected by the coordination server is equal to the number of relay servers, it indicates that all relay servers have obtained a successful pre-synchronization result based on the synchronization request, and the type of synchronization processing request is determined to be synchronization commit. When the number of pre-synchronization nodes detected by the coordination server is less than the number of relay servers, it indicates that some relay servers have not obtained a successful pre-synchronization result based on the synchronization request (i.e., at least one relay server's pre-synchronization result is a pre-synchronization failure), and the type of synchronization processing request is determined to be synchronization rollback.

[0084] In other words, when the coordinating server detects that all router nodes under / routechg / friendsvr have committed prepare_x.xxx, the coordinating server can modify the transaction status of the nodes under / routechg / friendsvr to state=COMMIT. See details below. Figure 8 , Figure 8 The data structure diagram provided in this application embodiment shows that when the coordination server detects that the three relay servers router1, router2, and router3 have registered prepare_x.xxx, it changes the transaction status from PREPARE to COMMIT.

[0085] Step 5: Each relay server performs the corresponding type of synchronization processing operation for the target transaction based on the determined type of synchronization processing request.

[0086] Here, when each relay server detects that the transaction status has changed to COMMIT, the type of synchronization processing request is synchronous commit. This triggers a formal route change operation, performing a synchronous commit operation on the target node. This includes retrieving the latest friendsvr list from temporary memory to replace the original friendsvr list, and backing up the original friendsvr list (e.g., to backup_list). Simultaneously, a commit_x.xxx node is written to the / routerchg / friendsvr node. An example of ZKNode data is shown below. Figure 9 As shown, Figure 9This is a data structure diagram provided in an embodiment of this application. When the three relay servers, router1, router2, and router3, have all successfully performed actual synchronization with the target node, they register commit_9.0.20.1, commit_9.0.20.2, and commit_9.0.20.3 nodes, respectively. When the coordinating server detects that all router nodes have registered commit_x.xxx nodes, it means that all relay servers have completed the route switch, and at this time, state = NONE can be set.

[0087] When each relay server detects that the transaction status has not changed to COMMIT, the type of synchronization processing request is synchronization rollback. Instead of performing a formal route change operation, a synchronization rollback operation is performed on the target node, such as deleting the latest temporarily stored friendsvr list from the temporary memory.

[0088] The aforementioned detection of the node status corresponding to each relay server is implemented through a coordinating server. When each relay server corresponds to a node, the routing change process requires a master node to detect / routechg / friendsvr and drive the entire transaction state transition. Therefore, to a certain extent, the coordinating server can be regarded as one of many relay servers, and the node corresponding to the coordinating server is regarded as the master node. The role of the master node is to detect whether each router node has committed, such as checking whether the router has committed prepare_x.xxx or commit_x.xxx.

[0089] The following explanation uses the example of checking whether prepare_x.xxx has been submitted. See [link to documentation]. Figure 10 , Figure 10 The diagram illustrates a state detection method provided in this application embodiment. The method includes: in step 201, FriendsVR scaling triggers a scaling notification to each router; in step 202, each router performs prepare phase processing, registers prepare nodes, and triggers a query notification to the master node; in step 203, the master node queries changes in child nodes (e.g., the master node queries changes in child nodes of / routerchg / friendsvr), and when a new router submits prepare_x.xxx, the master node receives a notification and retrieves a list of all child nodes; in step 204, the master node determines whether the number of prepare nodes is equal to router_num. If the number of prepare nodes == router_num, then step 205 is executed, where the transaction state is changed to state = COMMIT; otherwise, step 206 is executed to exit the process.

[0090] See Figure 11 , Figure 11 The master node selection view provided in this application embodiment simplifies the overall architecture and reduces overall complexity. The master node can be elected from among the router nodes. When the process starts, it registers a temporary sequential node with ` / routerlead` in the ZooKeeper cluster and monitors ` / routerlead`, for example, `router_x.xxx_000000010`. During initial startup, the registration of a new node triggers a notification. Routers already started can receive the notification and pull the latest router list. Since the sequence number of ZooKeeper sequential nodes is auto-incrementing, we can select the router with the smallest sequence number as the master node. Subsequent new router nodes automatically become slave nodes due to their larger sequence numbers. When the master node fails, the temporary nature of the ZooKeeper nodes ensures that the master node `router_x.xxx_00000010` will be deleted from the ZooKeeper cluster due to heartbeat timeout. At this time, other routers receive notification of the change in the child nodes of ` / routerlead`, pull the latest router list, and select the router with the smallest sequence number, `router_x.xxx_000000011`, as the master node, thus completing a new round of master node election.

[0091] In practical applications, extreme network conditions can cause router nodes to fail to receive notifications. In such cases, some routers may not complete the voting or commit operations, leading to a blockage in the entire transaction state. A timeout mechanism is needed for state rollback, with different rollback methods at different stages: For steps 1-3: For example, when router2 fails to receive notification and cannot create the prepare_x.xxx node, the master node detects a timeout of state == PREPARE, even though the actual routing of each router has not changed. At this point, the master node will set the state to NONE. When other routers receive the transaction state switch to initial, they will perform some data initialization work, such as clearing the routing information in temporary memory.

[0092] For steps 4-5, for example, if router2 does not receive a notification in time, it may fail to create the commit_x.xxx node in / routechg / friendsvr. In this case, if the master node detects that state == COMMIT has remained unchanged for a certain period and the cumulative number of commit_x.xxx nodes is less than router_num, it considers the transaction abnormal and switches it to state == ROLLBACK. At this point, each router node detects the transaction state as ROLLBACK and performs a rollback operation, which actually uses the back_list from step 5 for route recovery. After the rollback operation is complete, a rollback_x.xxx node will be created under / routechg / friendsvr, such as... Figure 12 As shown, Figure 12 The data structure diagram provided in this application embodiment shows that when the three relay servers router1, router2, and router3 fail to perform a true synchronization success for the target node (i.e., perform a rollback operation), they register rollback_9.0.20.1, rollback_9.0.20.2, and rollback_9.0.20.3 nodes respectively.

[0093] In the above manner, this application embodiment, while making full use of ZooKeeper, ensures that each relay server either switches routes together (synchronizes data) or does not switch at all based on multi-step judgment, thus ensuring the consistency of change transaction behavior; in this way, if some relay servers do not receive the notification, then other relay servers that have received the notification will not update the route, so that the loss of the notification does not affect the consistency of data in each relay server.

[0094] The following description further illustrates the exemplary structure of the synchronization device 555 in the distributed system provided in this application embodiment as a software module. In some embodiments, the distributed system includes at least one coordination server and at least two relay servers, such as... Figure 2As shown, the software modules in the synchronization device 555 of the distributed system stored in the memory 550 may include: a first sending module 5551, configured to, in response to a synchronization instruction for a target transaction, send a synchronization request for the target transaction to each of the relay servers; a response receiving module 5552, configured to receive response information returned by each of the relay servers in response to the synchronization request, the response information being used to provide feedback on the pre-synchronization result of the corresponding relay server for the target transaction; wherein the pre-synchronization result is used to indicate whether the pre-synchronization for the target transaction was successful or failed; and a second sending module 5553, configured to, based on the pre-synchronization result of each of the relay servers provided in the response information, determine the type of synchronization processing request, and send the type of synchronization processing request to each of the relay servers, so that each of the relay servers performs a corresponding type of synchronization processing operation for the target transaction based on the type of synchronization processing request.

[0095] In some embodiments, the first sending module is further configured to have the coordination server generate a synchronization request for the target transaction indicated by the synchronization instruction, and send the synchronization request to each of the relay servers, so that each of the relay servers determines a pre-synchronization result corresponding to the synchronization request based on the synchronization request, and determines response information based on each pre-synchronization result, so as to return the response information to the coordination server.

[0096] In some embodiments, the apparatus further includes a relay server execution module, configured to, when the synchronization instruction instructs to synchronize target data in the target transaction, each of the relay servers respectively performs the following operations: when the relay server synchronizes the target data based on the synchronization request and obtains synchronized data, it determines a pre-synchronization result indicating successful pre-synchronization of the target data and stores the synchronized data in temporary memory; when the relay server fails to synchronize the target data based on the synchronization request and obtains synchronized data, it determines a pre-synchronization result indicating failed pre-synchronization of the target data.

[0097] In some embodiments, the relay server execution module is further configured to, when the synchronization instruction indicates capacity synchronization of the resource capacity in the target transaction, each relay server performs the following operations: when the relay server queries the updated capacity list based on the synchronization request, it determines a pre-synchronization result indicating successful pre-synchronization of the resource capacity and stores the updated capacity list in temporary memory; when the relay server cannot query the updated capacity list based on the synchronization request, it determines a pre-synchronization result indicating failed pre-synchronization of the resource capacity.

[0098] In some embodiments, the relay server execution module is further configured to, when the pre-synchronization result indicates that the pre-synchronization for the target transaction is successful, register a pre-synchronization node for indicating successful pre-synchronization on the corresponding relay server; each relay server selects a master relay server from the at least two relay servers; the master relay server detects the number of registered pre-synchronization nodes and compares the number of pre-synchronization nodes with the number of relay servers to determine the response information based on the comparison result, and returns the response information to the coordination server.

[0099] In some embodiments, the relay server execution module is further configured to register a corresponding temporary sequence node for each relay server, obtain a number of temporary sequence nodes consistent with the number of relay servers, wherein the sequence number of the temporary sequence node is auto-incrementing; select the first temporary sequence node with the smallest sequence number from the number of temporary sequence nodes according to the sequence number of the temporary sequence node, and determine the relay server corresponding to the selected first temporary sequence node as the main relay server.

[0100] In some embodiments, the relay server execution module is further configured to select a second temporary sequence node adjacent to the first temporary sequence node when the relay server corresponding to the selected first temporary sequence node fails; determine the relay server corresponding to the selected second temporary sequence node as the main relay server; and delete the failed relay server and the first temporary sequence node.

[0101] In some embodiments, the second sending module is further configured to determine the type of the synchronization processing request as synchronization submission when the response information indicates that the pre-synchronization results of each of the relay servers are all successful; and to determine the type of the synchronization processing request as synchronization rollback when the response information indicates that the pre-synchronization result of at least one of the at least two relay servers is a pre-synchronization failure.

[0102] In some embodiments, the second sending module is further configured to send a synchronous commit request to each of the relay servers when the type of the synchronous processing request is synchronous commit, so that each of the relay servers performs a synchronous commit operation on the target transaction based on the synchronous commit request; and to send a synchronous rollback request to each of the relay servers when the type of the synchronous processing request is synchronous rollback, so that each of the relay servers performs a synchronous rollback operation on the target transaction based on the synchronous rollback request.

[0103] In some embodiments, the second sending module is further configured to: when the synchronization instruction indicates data synchronization of target data in the target transaction, send a synchronization commit request to each of the relay servers, so that each of the relay servers, based on the synchronization commit request, retrieves the synchronization data obtained from synchronizing the target data from temporary memory, replaces the target data with the synchronization data, and backs up the target data; when the synchronization instruction indicates capacity synchronization of resource capacity in the target transaction, send a synchronization commit request to each of the relay servers, so that each of the relay servers, based on the synchronization commit request, retrieves an updated capacity list from temporary memory, replaces the original capacity list with the updated capacity list, and backs up the original capacity list.

[0104] In some embodiments, the second sending module is further configured to: when the synchronization instruction indicates data synchronization of target data in the target transaction, send a synchronization rollback request to the at least two relay servers, so that the other relay servers among the at least two relay servers, excluding the relay server whose synchronization result is synchronization failure, delete the synchronized data obtained by synchronizing the target data from the temporary memory based on the synchronization rollback request; and when the synchronization instruction indicates capacity synchronization of resource capacity in the target transaction, send a synchronization rollback request to each of the relay servers, so that the other relay servers among the at least two relay servers, excluding the relay server whose synchronization result is synchronization failure, delete the updated capacity list from the temporary memory based on the synchronization rollback request, and retain the original capacity list.

[0105] In some embodiments, after sending the synchronization commit request to each of the relay servers, the apparatus further includes: a third sending module, configured to update the synchronization status corresponding to the target transaction to a commit status; obtain the duration of the commit status, and within the duration, detect feedback information from each of the relay servers in response to the synchronization commit request; wherein the feedback information is used to provide feedback on the synchronization commit result of the corresponding relay server for the target transaction, and the synchronization commit result is used to indicate whether the synchronization commit for the target transaction was successful or failed; when the duration exceeds a target duration and the feedback information indicates that the synchronization commit result of at least one of the at least two relay servers is a synchronization commit failure, a synchronization rollback request is sent to each of the relay servers, so that each of the relay servers performs a synchronization rollback operation for the target transaction based on the synchronization rollback request.

[0106] This application provides a computer program product or computer program that includes computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the synchronization method in the distributed system described above in this application.

[0107] This application provides a computer-readable storage medium storing executable instructions. When these executable instructions are executed by a processor, they cause the processor to execute a synchronization method in a distributed system provided in this application. For example, ... Figure 3 The method shown.

[0108] In some embodiments, the computer-readable storage medium may be a memory such as FRAM, ROM, PROM, EPROM, EEPROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0109] In some embodiments, executable instructions may take the form of a program, software, software module, script, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as a standalone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0110] As an example, executable instructions may, but do not necessarily, correspond to files in the file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a Hyper Text Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple collaborative files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0111] As an example, executable instructions can be deployed to execute on a single computing device, or on multiple computing devices located in one location, or on multiple computing devices distributed across multiple locations and interconnected via a communication network.

[0112] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A synchronization method in a distributed system, characterized in that, The distributed system includes at least one coordination server and at least two relay servers, and the method includes: In response to a synchronization command for a target transaction, the coordinating server sends a synchronization request for the target transaction to each of the relay servers, so that each relay server determines a pre-synchronization result corresponding to the synchronization request, the pre-synchronization result indicating whether the pre-synchronization for the target transaction is successful or fails. When the pre-synchronization result indicates that the pre-synchronization for the target transaction is successful, the corresponding relay server registers a pre-synchronization node to indicate successful pre-synchronization. Each relay server selects a master relay server from the at least two relay servers. The master relay server detects the number of registered pre-synchronization nodes and compares the number of pre-synchronization nodes with the number of relay servers. When the number of pre-synchronization nodes is equal to the number of relay servers, a response message is obtained to indicate that the pre-synchronization results of all relay servers are successful. When the number of pre-synchronization nodes is less than the number of relay servers, a response message is obtained to indicate that the pre-synchronization results of some relay servers are failed, and the response message is returned to the coordinating server. The coordination server determines the type of synchronization processing request based on the pre-synchronization results of each of the relay servers fed back by the response information, and sends the synchronization processing request of the type to each of the relay servers, so that each of the relay servers performs the corresponding type of synchronization processing operation for the target transaction based on the synchronization processing request of the type.

2. The method according to claim 1, characterized in that, The coordinating server sends synchronization requests for the target transaction to each of the relay servers, including: The coordination server generates a synchronization request for the target transaction as indicated by the synchronization instruction, and sends the synchronization request to each of the relay servers.

3. The method according to claim 1, characterized in that, Each of the relay servers determines a pre-synchronization result corresponding to the synchronization request based on the synchronization request, including: When the synchronization command instructs the target data in the target transaction to be synchronized, each of the relay servers performs the following operations: When the relay server obtains synchronized data by synchronizing the target data based on the synchronization request, it determines a pre-synchronization result indicating the success of the pre-synchronization for the target data and stores the synchronized data in temporary memory. When the relay server is unable to synchronize the target data based on the synchronization request, it determines a pre-synchronization result indicating a failure of pre-synchronization for the target data.

4. The method according to claim 1, characterized in that, Each of the relay servers determines a pre-synchronization result corresponding to the synchronization request based on the synchronization request, including: When the synchronization command instructs to synchronize the resource capacity in the target transaction, each of the relay servers performs the following operations: When the relay server queries the updated capacity list based on the synchronization request, it determines the pre-synchronization result indicating the success of the pre-synchronization of the resource capacity, and stores the updated capacity list in temporary memory; When the relay server is unable to find the updated capacity list based on the synchronization request, it determines a pre-synchronization result indicating the failure of the pre-synchronization of the resource capacity.

5. The method according to claim 1, characterized in that, Each of the aforementioned relay servers selects a primary relay server from the at least two relay servers, including: Each of the relay servers registers a corresponding temporary sequence node, resulting in a number of temporary sequence nodes that is consistent with the number of the relay servers. The sequence number of the temporary sequence node is auto-incrementing. Based on the sequence number of the temporary sequence node, select the first temporary sequence node with the smallest sequence number from the temporary sequence nodes, and determine the relay server corresponding to the selected first temporary sequence node as the main relay server.

6. The method according to claim 5, characterized in that, The method further includes: When the relay server corresponding to the first temporary sequence node fails, a second temporary sequence node adjacent to the first temporary sequence node is selected. The relay server corresponding to the selected second temporary sequence node is determined as the main relay server, and the faulty relay server and the first temporary sequence node are deleted.

7. The method according to claim 1, characterized in that, The type of synchronization processing request is determined based on the pre-synchronization results of each of the relay servers, according to the feedback of the response information, including: When the response information feedback from each of the relay servers indicates that the pre-synchronization result is successful, the type of the synchronization processing request is determined to be synchronization submission. When the response information indicates that at least one of the at least two relay servers has a pre-synchronization result of pre-synchronization failure, the type of the synchronization processing request is determined to be synchronization rollback.

8. The method according to claim 1, characterized in that, Sending the synchronization processing request of the aforementioned type to each of the relay servers, so that each of the relay servers performs a corresponding type of synchronization processing operation for the target transaction based on the synchronization processing request of the aforementioned type, includes: When the type of the synchronization processing request is synchronization commit, a synchronization commit request is sent to each of the relay servers, so that each of the relay servers performs a synchronization commit operation on the target transaction based on the synchronization commit request; When the type of the synchronization processing request is synchronization rollback, a synchronization rollback request is sent to each of the relay servers so that each of the relay servers performs a synchronization rollback operation on the target transaction based on the synchronization rollback request.

9. The method according to claim 8, characterized in that, Sending a synchronization commit request to each of the relay servers, so that each of the relay servers performs a synchronization commit operation on the target transaction based on the synchronization commit request, includes: When the synchronization instruction indicates that the target data in the target transaction is synchronized, a synchronization commit request is sent to each of the relay servers, so that each of the relay servers can obtain the synchronization data obtained by synchronizing the target data from the temporary memory based on the synchronization commit request, so as to replace the target data with the synchronization data and back up the target data. When the synchronization instruction indicates that the resource capacity in the target transaction is synchronized, a synchronization commit request is sent to each of the relay servers, so that each of the relay servers can obtain an updated capacity list from temporary memory based on the synchronization commit request, replace the original capacity list with the updated capacity list, and back up the original capacity list.

10. The method according to claim 8, characterized in that, Sending a synchronization rollback request to each of the relay servers, so that each of the relay servers performs a synchronization rollback operation on the target transaction based on the synchronization rollback request, includes: When the synchronization instruction indicates that the target data in the target transaction is synchronized, a synchronization rollback request is sent to the at least two relay servers, so that the other relay servers among the at least two relay servers, except for the relay server whose pre-synchronization result is pre-synchronization failure, delete the synchronized data obtained by synchronizing the target data from the temporary memory based on the synchronization rollback request. When the synchronization instruction indicates that the resource capacity in the target transaction is synchronized, a synchronization rollback request is sent to each of the relay servers, so that the other relay servers among the at least two relay servers, except for the relay server whose pre-synchronization result is pre-synchronization failure, delete the updated capacity list from the temporary memory based on the synchronization rollback request, and retain the original capacity list.

11. The method according to claim 8, characterized in that, After sending the synchronization submission request to each of the relay servers, the method further includes: Update the synchronization status corresponding to the target transaction to the committed status; The duration of the submission status is obtained, and the feedback information of each of the relay servers in response to the synchronous submission request is detected within the duration. The feedback information is used to provide feedback on the synchronous commit result of the corresponding relay server for the target transaction. The synchronous commit result is used to indicate whether the synchronous commit for the target transaction was successful or failed. When the duration exceeds the target duration and the feedback information indicates that at least one of the at least two relay servers has failed to commit the synchronization, a synchronization rollback request is sent to each of the relay servers so that each of the relay servers performs a synchronization rollback operation on the target transaction based on the synchronization rollback request.

12. A synchronization device in a distributed system, characterized in that, The distributed system includes at least one coordination server and at least two relay servers, and the apparatus includes: The first sending module is configured to respond to a synchronization instruction for a target transaction, wherein the coordinating server sends a synchronization request for the target transaction to each of the relay servers, so that each of the relay servers determines a pre-synchronization result corresponding to the synchronization request based on the synchronization request, wherein the pre-synchronization result is used to indicate whether the pre-synchronization for the target transaction is successful or fails. The apparatus further includes: when the pre-synchronization result indicates that the pre-synchronization for the target transaction is successful, the corresponding relay server registers a pre-synchronization node to indicate the pre-synchronization success; each relay server selects a master relay server from the at least two relay servers; the master relay server detects the number of registered pre-synchronization nodes and compares the number of pre-synchronization nodes with the number of relay servers; when the number of pre-synchronization nodes is equal to the number of relay servers, a response information is obtained to indicate that the pre-synchronization results of each relay server are all successful; when the number of pre-synchronization nodes is less than the number of relay servers, a response information is obtained to indicate that the pre-synchronization results of some relay servers are failed, and the response information is returned to the coordination server. The second sending module is used to determine the type of synchronization processing request based on the pre-synchronization results of each of the relay servers fed back by the response information, and send the type of synchronization processing request to each of the relay servers, so that each of the relay servers performs the corresponding type of synchronization processing operation for the target transaction based on the type of synchronization processing request.

13. The apparatus according to claim 12, characterized in that, The first sending module is further configured to: The coordination server generates a synchronization request for the target transaction as indicated by the synchronization instruction, and sends the synchronization request to each of the relay servers.

14. An electronic device, characterized in that, include: Memory, used to store executable instructions; A processor, when executing executable instructions stored in the memory, implements the synchronization method in the distributed system according to any one of claims 1 to 11.

15. A computer-readable storage medium, characterized in that, It stores executable instructions for use by a processor to implement the synchronization method in the distributed system according to any one of claims 1 to 11.

16. A computer program product comprising a computer program or instructions, characterized in that, When the computer program or instructions are executed by the processor, they implement the synchronization method in the distributed system according to any one of claims 1 to 11.

Images