Data synchronization method, device, system, electronic device and storage medium

Abstract

The embodiments of the present application provide a data synchronization method, device, system, electronic device and storage medium for realizing data synchronization of multiple endpoints in a conversation group; the method is applied to the initiator in the conversation group, and the method includes: in response to meeting the synchronization trigger condition, executing the following data synchronization process: obtaining the data to be synchronized; determining the synchronization type of this synchronization, and generating a synchronization identifier according to the synchronization type; the synchronization type includes normal synchronization and failed retry; based on the synchronization identifier and the data to be synchronized, encapsulating the target data message; synchronizing the target data message to the receiving end of the conversation group through an intermediate server. The initiator can initiate two types of data synchronization processes, and by encapsulating the synchronization identifier indicating the synchronization type into the data to be synchronized, other devices in the data synchronization process can know the synchronization type of this synchronization according to the synchronization identifier, and thus perform corresponding processing. In this way, an automatic one-to-many synchronization topology is achieved.

Description

Technical Field

[0001] The present application relates to the field of data processing technology, and in particular to a data synchronization method, device, system, electronic device and storage medium. Background Art

[0002] File transfer is a hot topic on the internet today. In many business scenarios, there's often a need for one endpoint to synchronize data with multiple endpoints, also known as a one-to-many synchronization topology. Due to network instability, synchronization failures are unavoidable for some endpoints in a one-to-many synchronization topology. Implementing automatic one-to-many synchronization in unstable network conditions is a pressing technical challenge in this field. Summary of the Invention

[0003] The purpose of the embodiments of the present application is to provide a data synchronization method, device, system, electronic device and storage medium to achieve an automatic one-to-many synchronization topology technical effect.

[0004] In a first aspect, an embodiment of the present application provides a data synchronization method for implementing data synchronization among multiple endpoints in a conversation group. The method is applied to an initiating end in the conversation group, and includes:

[0005] In response to the synchronization trigger condition being met, the following data synchronization process is executed:

[0006] Get the data to be synchronized;

[0007] Determine the synchronization type of this synchronization and generate a synchronization identifier according to the synchronization type; wherein the synchronization type includes normal synchronization and failure retry;

[0008] Encapsulating a target data message based on the synchronization identifier and the data to be synchronized;

[0009] The target data message is synchronized to the receiving end of the conversation group through an intermediate server.

[0010] In the above implementation, the initiator can initiate two types of data synchronization processes. By encapsulating a synchronization identifier indicating the synchronization type into the data to be synchronized, other devices in the data synchronization process can determine the synchronization type based on the synchronization identifier and perform corresponding processing. As can be seen, since the initiator can automatically perform normal synchronization, a one-to-many synchronization topology can be automatically implemented even in unstable network conditions. Even if some receiving ends fail to synchronize, the initiator can automatically trigger a retry upon failure.

[0011] Furthermore, the method further comprises:

[0012] In response to receiving a target result message fed back based on the target data message, determining a synchronization result of the data to be synchronized according to the target result message;

[0013] If the synchronization result is a synchronization failure, it is determined that the synchronization trigger condition is met, the data synchronization process is returned to be executed, and the synchronization type is determined to be the failure retry.

[0014] In the above implementation, upon receiving a target result message indicating synchronization failure, the initiator automatically initiates a data synchronization process with a failed retry, thus forming a data synchronization loop. By using synchronization failure as a trigger, the data synchronization process is executed repeatedly until all receiving ends have successfully synchronized. This eliminates the need for manual triggering of data synchronization retry failures, enabling automatic synchronization failure detection and re-initiation on the initiator.

[0015] Furthermore, the target result message also indicates a target receiving end that has failed synchronization;

[0016] The generating of a synchronization identifier according to the synchronization type includes: generating a synchronization identifier indicating the target receiving end;

[0017] The synchronizing the target data message to the receiving end of the conversation group through the intermediate server includes: synchronizing the target data message to the target receiving end through the intermediate server.

[0018] In the above implementation process, the initiator determines which receiving ends have failed to synchronize through the target result message, thereby obtaining the target receiving end. This allows the data synchronization process of failed retries to be initiated for the target receiving end. By generating a synchronization identifier that can be used to indicate the target receiving end, other devices in the data synchronization process can know from the synchronization identifier the object that needs to be synchronized with the data, that is, the target receiving end, and thus perform corresponding processing on the target receiving end. In this way, in the data synchronization process of failed retries, resynchronization can be initiated specifically for the target receiving end that failed to synchronize, without the need to resynchronize all receiving ends without deviation, thereby improving the intelligence of failed retries and saving computing resources.

[0019] Furthermore, the method further comprises:

[0020] generating a conversation group identifier according to the conversation group to which the initiating end belongs;

[0021] The encapsulating the target data message based on the synchronization identifier and the data to be synchronized includes:

[0022] Based on the synchronization identifier, the session group identifier and the data to be synchronized, a target data message is encapsulated to obtain the target data message.

[0023] In the above implementation process, the synchronization identifier and the session group identifier are encapsulated together into the data to be synchronized, thereby obtaining the target data message, so that other devices in the data synchronization process can know the session group to which the initiator belongs through the session group identifier, and thus can accurately forward the target data message to the receiving end in the session group to which it belongs, thereby completing the one-to-many synchronization topology within the session group.

[0024] A second aspect of an embodiment of the present application provides a data synchronization method for implementing data synchronization of multiple endpoints in a conversation group; the method is applied to an intermediate server, the intermediate server being communicatively connected to multiple endpoints, and the intermediate server having established at least one conversation group; the method includes:

[0025] In response to receiving a target data message sent by the initiator, parsing a synchronization identifier carried in the target data message;

[0026] Determine the receiving end in the conversation group to which the initiating end belongs according to the synchronization type indicated by the synchronization identifier; wherein the synchronization type includes normal synchronization and failure retry;

[0027] Send the target data message to the receiving end.

[0028] In the above implementation, leveraging the intermediary server's communication connections with all endpoints in the session group, the intermediary server can forward the initiator's target data packet to multiple recipients. Furthermore, by parsing the synchronization identifier carried in the target data packet, it determines the synchronization type and selects different endpoints as recipients for each synchronization type. This allows the intermediary server to select matching endpoints as recipients, regardless of whether the initiator initiates a normal synchronization or a failed retry. This enables a one-to-many synchronization topology to be implemented even in unstable network conditions.

[0029] Furthermore, the method further comprises:

[0030] In response to receiving the result message sent by the receiving end, generating a target result message according to the result message; the target result message is used to indicate the synchronization result of the data to be synchronized;

[0031] Send the target result message to the initiator.

[0032] In the above implementation process, by designing the receiving end to return the result message, the intermediate server generates a target result message based on the result message to feedback the synchronization result of the data to be synchronized to the initiating end, so that the initiating end can perform corresponding processing based on the synchronization result, including ending the synchronization process or initiating a failed retry data synchronization process, so as to realize an automatic one-to-many synchronization topology.

[0033] Furthermore, the result message includes a plurality of messages, and generating a target result message according to the result message includes:

[0034] Parsing the plurality of result messages to determine a target receiving end that failed to synchronize the data to be synchronized;

[0035] A target result message indicating the synchronization result and the target receiving end is generated.

[0036] In this implementation, the intermediate server generates a target result message that indicates the target receiving end. This allows the initiator to determine which receiving end failed synchronization based on the target result message and then initiate data synchronization for the target receiving end. This eliminates the need to resynchronize all receiving ends without deviation, improves the intelligence of failure retry, and saves computing resources.

[0037] Furthermore, determining the receiving end in the conversation group to which the initiating end belongs according to the synchronization type indicated by the synchronization identifier includes:

[0038] If the synchronization type is normal synchronization, determining endpoints other than the initiating end in the conversation group as receiving ends;

[0039] If the synchronization type is failure retry, a target receiving end indicated by the synchronization identifier is determined in the corresponding session group.

[0040] In the above implementation process, the intermediate server determines different endpoint groups as receiving ends according to the synchronization type, so that no matter whether the initiator initiates normal synchronization or failed retry, the intermediate server can filter out matching endpoints as receiving ends, thereby realizing a one-to-many synchronization topology under unstable network conditions.

[0041] Furthermore, the target data message also carries a session group identifier;

[0042] Determining the receiving end in the conversation group to which the initiating end belongs includes:

[0043] Determining the conversation group to which the user belongs according to the conversation group identifier;

[0044] A receiving end is determined from the conversation group.

[0045] In the above implementation process, the intermediate server finds the session group to which the initiator belongs through the session group identifier carried by the target data message, so that it can accurately forward the target data message to the receiving end in the session group to which it belongs, completing the one-to-many synchronization topology within the session group.

[0046] Furthermore, the target data message is volatilely stored in the intermediate server.

[0047] In this implementation, the target data packets do not need to be written to disk during forwarding. The intermediate server can directly reuse the network IO data sent by the initiator, avoiding the additional read and write operations generated by each receiving end pulling the target data packets.

[0048] A third aspect of the embodiment of the present application provides a data synchronization system, the system comprising an intermediate server and a plurality of endpoints; the plurality of endpoints forming at least one session group; the plurality of endpoints comprising an initiating end and a receiving end;

[0049] The initiator is configured to obtain data to be synchronized in response to a synchronization trigger condition being met; and

[0050] Determine the synchronization type of this synchronization and generate a synchronization identifier according to the synchronization type; wherein the synchronization type includes normal synchronization and failure retry; and

[0051] Encapsulating a target data message based on the synchronization identifier and the data to be synchronized; and

[0052] Sending the target data message to the intermediate server;

[0053] The intermediate server is configured to, in response to receiving a target data message sent by the initiator, parse the synchronization identifier carried in the target data message; and

[0054] Determining a receiving end in the conversation group to which the initiating end belongs according to the synchronization type indicated by the synchronization identifier; and

[0055] Send the target data message to the receiving end.

[0056] A fourth aspect of the present application provides a data synchronization device for implementing data synchronization among multiple endpoints in a conversation group; the device is applied to an initiating end in the conversation group, and includes:

[0057] An acquisition module, configured to acquire data to be synchronized in response to a synchronization trigger condition being met;

[0058] A generation module, configured to determine the synchronization type of this synchronization and generate a synchronization identifier according to the synchronization type; wherein the synchronization type includes normal synchronization and failure retry;

[0059] An encapsulation module, configured to encapsulate a target data message based on the synchronization identifier and the data to be synchronized;

[0060] A synchronization module is used to synchronize the target data message to the receiving end of the conversation group through an intermediate server.

[0061] According to a fifth aspect of the present application, a data synchronization device is provided for implementing data synchronization of multiple endpoints in a conversation group. The device is applied to an intermediate server, the intermediate server is in communication connection with multiple endpoints, and the intermediate server has established at least one conversation group. The device includes:

[0062] a parsing module, configured to, in response to receiving a target data message sent by the initiator, parse a synchronization identifier carried in the target data message;

[0063] A determination module, configured to determine a receiving end in the conversation group to which the initiating end belongs according to a synchronization type indicated by the synchronization identifier; wherein the synchronization type includes normal synchronization and failure retry;

[0064] A sending module is used to send the target data message to the receiving end.

[0065] According to a sixth aspect of the present application, an electronic device is provided, comprising:

[0066] processor;

[0067] a memory for storing processor-executable instructions;

[0068] Wherein, when the processor calls the executable instruction, it implements the operation of any method described in the first aspect or the second aspect.

[0069] A seventh aspect of an embodiment of the present application provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of any of the methods described in the first aspect or the second aspect. BRIEF DESCRIPTION OF THE DRAWINGS

[0070] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments of the present application. It should be understood that the following drawings only show certain embodiments of the present application and therefore should not be regarded as limiting the scope. For ordinary technicians in this field, other relevant drawings can be obtained based on these drawings without creative work.

[0071] Figure 1 A schematic diagram of a data synchronization system provided in an embodiment of the present application;

[0072] Figure 2 A flowchart of a data synchronization method provided in an embodiment of the present application;

[0073] Figure 3 A flowchart of another data synchronization method provided in an embodiment of the present application;

[0074] Figure 4A flowchart of another data synchronization method provided in an embodiment of the present application;

[0075] Figure 5 A flowchart of another data synchronization method provided in an embodiment of the present application;

[0076] Figure 6 A flowchart of another data synchronization method provided in an embodiment of the present application;

[0077] Figure 7 A flowchart of another data synchronization method provided in an embodiment of the present application;

[0078] Figure 8 A flowchart of another data synchronization method provided in an embodiment of the present application;

[0079] Figure 9 A flowchart of another data synchronization method provided in an embodiment of the present application;

[0080] Figure 10 A structural block diagram of a data synchronization device provided in an embodiment of the present application;

[0081] Figure 11 A structural block diagram of another data synchronization device provided in an embodiment of the present application;

[0082] Figure 12 A hardware structure diagram of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0083] The technical solutions in the embodiments of the present application will be described below in conjunction with the drawings in the embodiments of the present application.

[0084] It should be noted that similar reference numerals and letters represent similar items in the following drawings. Therefore, once an item is defined in one drawing, it does not need to be further defined or explained in subsequent drawings. At the same time, in the description of this application, the terms "first", "second", etc. are only used to distinguish the description and should not be understood as indicating or implying relative importance.

[0085] File transfer is a hot topic on the current Internet. In many business scenarios, there is often a need for one end to synchronize data with multiple ends, which is also called the need for a one-to-many synchronization topology. Due to the instability of the network status, it is inevitable that some endpoints will fail to synchronize in a one-to-many synchronization topology. In related technologies, when some endpoints fail to synchronize, manual maintenance is often required, including discovering the synchronization failure and re-initiating synchronization for the endpoints that failed to synchronize. Therefore, how to achieve automatic one-to-many synchronization topology under unstable network conditions is a technical problem that urgently needs to be solved in this field.

[0086] To this end, the present application provides a data synchronization method. Figure 1 An application scenario of a data synchronization method is shown. Figure 1 As shown, the data synchronization system 100 includes an intermediate server 110 and multiple endpoints. The so-called endpoint is also a network endpoint, which is a network device with a storage medium and a processor. For example, Figure 1 As an example, a total of 6 endpoints, endpoint 121 to endpoint 126, are shown. Figure 1 The examples shown do not impose any restrictions on the number of endpoints and intermediate servers.

[0087] In data synchronization system 100, intermediary server 110 is connected to multiple endpoints, forming a network topology. These endpoints form at least one conversation group. For example, endpoints 121, 122, and 123 form conversation group A. Endpoints 124, 125, and 126 form another conversation group, group B.

[0088] A conversation group can be created based on data synchronization requirements. The initiator of data synchronization and the recipients to be synchronized can jointly open an inter-group conversation with the intermediate server to create a conversation group that includes the initiator and all recipients.

[0089] The terms "initiator" and "receiver" refer to the roles an endpoint plays in a synchronization. These terms are relative and relate to the role an endpoint plays in synchronization. An endpoint can be the initiator in one synchronization and the receiver in another.

[0090] The present application provides a data synchronization method for implementing data synchronization among multiple endpoints in a conversation group. The so-called data synchronization among multiple endpoints in a conversation group refers to the existence of multiple endpoints in a conversation group that require data synchronization, and the data to be synchronized is initiated by another endpoint in the conversation group. The endpoint that initiates data synchronization is called the initiating endpoint, also known as the data synchronization initiating endpoint; the endpoint that requires data synchronization is called the receiving endpoint, and there may be multiple receiving endpoints. In other words, the present application provides a data synchronization method for implementing a one-to-many synchronization topology in a conversation group.

[0091] In a first aspect, the present application provides a data synchronization method, which is applied to an initiating end in a conversation group. The method comprises:

[0092] In response to the synchronization trigger condition being met, the following is executed: Figure 2 The data synchronization process shown includes the following steps:

[0093] Step 210: Obtain data to be synchronized;

[0094] Step 220: Determine the synchronization type of this synchronization, and generate a synchronization identifier according to the synchronization type;

[0095] The synchronization type includes normal synchronization and failure retry;

[0096] Step 230: Encapsulating a target data message based on the synchronization identifier and the data to be synchronized;

[0097] Step 240: Synchronize the target data message to the receiving end of the conversation group through the intermediate server.

[0098] When the synchronization trigger condition is met, the initiator initiates the data synchronization process. The data synchronization process steps 210 to 240. The initiator first obtains the data to be synchronized. The data to be synchronized needs to be synchronized to the receiving end in the conversation group.

[0099] The initiator then determines the synchronization type for this synchronization. Synchronization types include normal synchronization and retry upon failure. A normal synchronization is the first attempt to synchronize the data to the receiving end. A retry upon failure is a non-first attempt to synchronize the data to the receiving end. Prior to this synchronization, an attempt to synchronize the data to the receiving end had already failed. Therefore, by re-initiating synchronization, i.e., initiating this synchronization, a new attempt is made to synchronize the data to the receiving end that previously failed.

[0100] It can be seen that the data synchronization process initiated by the initiator can be initiated for the first time for the data to be synchronized; or it can be initiated for the retry after the synchronization of the data to be synchronized fails.

[0101] Since the data synchronization processes of normal synchronization type and failed retry type are different, the initiator needs to determine the synchronization type of this synchronization and generate a synchronization identifier based on the synchronization type so that other devices participating in the data synchronization process, such as intermediate servers, can determine the type of this synchronization based on the synchronization identifier and perform corresponding processing.

[0102] Then, the initiator encapsulates the target data message based on the synchronization identifier and the data to be synchronized. For example, the initiator may encapsulate the synchronization identifier into the data to be synchronized, thereby obtaining the target data message.

[0103] Finally, the target data is synchronized to the receiving end in the conversation group via the intermediate server. For example, the intermediate server acts as a message forwarder. The initiator can send the target data message to the intermediate server via a communication link established with the intermediate server. The intermediate server can forward the received target data message to the receiving end via a communication link established with the receiving end. The communication link can be a transport layer connection, including, but not limited to, a TCP (Transmission Control Protocol) connection or a UDP (User Datagram Protocol) connection.

[0104] It can be seen that in the data synchronization method provided in the first aspect of the present application, the initiator can initiate two types of data synchronization processes, and by encapsulating the synchronization identifier indicating the synchronization type into the data to be synchronized, other devices in the data synchronization process can know the synchronization type of this synchronization based on the synchronization identifier, and thus perform corresponding processing. It can be seen that since the initiator can automatically perform normal synchronization, a one-to-many synchronization topology can be automatically realized even in an unstable network state. Even if some receiving ends fail to synchronize, the initiator can automatically trigger a failure retry.

[0105] Regarding synchronization trigger conditions, they can be related to synchronization types. Different synchronization types correspond to different synchronization trigger conditions. Therefore, multiple synchronization trigger conditions can be included. Different synchronization trigger conditions trigger the initiator to initiate different types of synchronization.

[0106] In some embodiments, the synchronization trigger condition may be the detection of a data synchronization request. For example, if another endpoint sends a data synchronization request to a certain endpoint, it is determined that a data synchronization request has been detected, and the synchronization trigger condition is satisfied. For another example, if a user inputs a synchronization command, it is determined that a data synchronization request has been detected, and the synchronization trigger condition is satisfied.

[0107] In this way, in response to detecting a data synchronization requirement, the initiator is triggered to initiate a data synchronization process, and the synchronization type of this synchronization can be determined to be normal synchronization.

[0108] In a normal data synchronization process, there are multiple receiving ends, so that the data to be synchronized is synchronized to multiple receiving ends. Then, step 240 may include: synchronizing the target data message to the multiple receiving ends of the conversation group through the intermediate server.

[0109] In other embodiments, the synchronization trigger condition may be data synchronization failure. For example, if it is determined through the received target result message that some receiving ends have failed to synchronize data in historical synchronization, then the synchronization trigger condition is determined to be met.

[0110] In this way, in response to the data synchronization failure, the triggering end initiates the data synchronization process and can determine that the synchronization type of this synchronization is failure retry. And the data to be synchronized in this synchronization is consistent with the data to be synchronized in the historical synchronization.

[0111] In the data synchronization process of failed retry, there is at least one receiving end, so step 240 may include: synchronizing the target data message to at least one receiving end of the conversation group through the intermediate server; the at least one receiving end is the receiving end that failed to synchronize in the historical synchronization.

[0112] As an example, Figure 3 As shown, a data synchronization method provided in the first aspect of the present application further includes the steps of:

[0113] Step 250: In response to receiving a target result message fed back based on the target data message, determining a synchronization result of the data to be synchronized according to the target result message;

[0114] Step 260: If the synchronization result is synchronization failure, determine whether the synchronization trigger condition is met;

[0115] At this point, the process returns to step 210 - step 240 , and determines that the synchronization type is failure retry.

[0116] After receiving the target data message, the receiver can parse the target data message to obtain the data to be synchronized and synchronize the data. Regardless of whether the synchronization is successful or not, the receiver can also provide feedback on the synchronization result to the initiator based on the target data message. For example, the receiver can provide feedback on the synchronization result to the initiator through an intermediate server.

[0117] In this embodiment, upon receiving a target result message indicating synchronization failure, the initiating end automatically initiates a data synchronization process with a failed retry, thus forming a data synchronization process loop. By using synchronization failure as a trigger, the data synchronization process is executed cyclically until all receiving ends have successfully synchronized. This eliminates the need for manual triggering of data synchronization retry failures, enabling automatic synchronization failure detection and synchronization re-initiation on the initiating end.

[0118] Regarding the target result message, in some embodiments, the target result message also indicates the target receiving end that has synchronization failure.

[0119] For example, when a receiving end that fails synchronization feeds back the synchronization result, it can attach its own endpoint identifier, such as an identifier that uniquely identifies the endpoint, so that the initiating end can obtain the target receiving end that failed synchronization through the target result message.

[0120] Thus, the above step 220 may specifically include: determining that the synchronization type of this synchronization is a failure retry, and generating a synchronization identifier indicating the target receiving end.

[0121] Exemplarily, the initiator may obtain the endpoint identifier of the target receiving end from the target result message, and record the obtained endpoint identifier in the synchronization identifier field, so that the generated synchronization identifier indicates that there is a target receiving end.

[0122] Thus, the above step 240 may specifically include: synchronizing the target data message to the target receiving end via the intermediate server.

[0123] In this embodiment, the initiator determines which receiving ends have failed synchronization through the target result message, thereby obtaining the target receiving end. This allows the data synchronization process of failed retries to be initiated for the target receiving end. By generating a synchronization identifier that can be used to indicate the target receiving end, other devices in the data synchronization process can learn from the synchronization identifier the object that needs to be synchronized with the data, that is, the target receiving end, and thus perform corresponding processing on the target receiving end. In this way, in the data synchronization process of failed retries, resynchronization can be initiated specifically for the target receiving end that failed synchronization, without the need to resynchronize all receiving ends without deviation, thereby improving the intelligence of failed retries and saving computing resources.

[0124] As described above, multiple endpoints form at least one session group in the data synchronization system 100. When there are more than one session groups, the intermediate server needs to determine the session group to which the initiating endpoint belongs before synchronizing the target data message to the receiving endpoint in the session group.

[0125] Therefore, in some embodiments, the above method further includes the step of: generating a session group identifier according to the session group to which the initiating end belongs.

[0126] It can be seen that the session group identifier is used to indicate the session group to which the initiating end belongs. Exemplarily, the session group identifier may be identity information used to uniquely identify the session group.

[0127] Thus, the above step 230 may include: encapsulating to obtain a target data message based on the synchronization identifier, the session group identifier and the data to be synchronized.

[0128] Exemplarily, the initiator may encapsulate the synchronization identifier and the session group identifier into the data to be synchronized, thereby obtaining a target data message.

[0129] In this embodiment, the synchronization identifier and the conversation group identifier are encapsulated together into the data to be synchronized, thereby obtaining the target data message, so that other devices in the data synchronization process can know the conversation group to which the initiating end belongs through the conversation group identifier, and thus can accurately forward the target data message to the receiving end in the conversation group to which it belongs, thereby completing the one-to-many synchronization topology within the conversation group.

[0130] Regarding the encapsulation of the data to be synchronized, in addition to encapsulating the synchronization identifier and the session group identifier in the data to be synchronized, in some embodiments, data information about the data to be synchronized may also be encapsulated.

[0131] Optionally, the data information includes one or more combinations of the following: message type, time, source address, data name, data size, and checksum.

[0132] The message type indicates the type of encapsulated message, including result messages and data messages. A result message indicates the synchronization result of the receiving end. For example, a result message can be generated by the receiving end or by an intermediate server. A data message carries the data to be synchronized. In other words, a data message is generated by the initiator.

[0133] Time may refer to time information such as synchronization initiation time, generation time of data to be synchronized, and packaging time.

[0134] The source address refers to the address information of the originating end, such as an IP (Internet Protocol) address.

[0135] The data name refers to the name of the data to be synchronized.

[0136] Data size refers to the size of the data to be synchronized.

[0137] A checksum is a value calculated using a preset algorithm on data and is used to verify data integrity.

[0138] Since the information encapsulated into the data to be synchronized includes multiple items, the encapsulation format of the multiple items of information can be pre-set through a private protocol. For example, the multiple items of information can be encapsulated into the data to be synchronized in the following format:

[0139]

[0140] Optionally, after the synchronization data is encapsulated with the above-mentioned multiple pieces of information, a protocol header of a transport layer protocol may be encapsulated before the encapsulated message, such as but not limited to a TCP header, a UDP header, etc., to finally obtain the target data message.

[0141] The second aspect of the present application provides a data synchronization method, which is applied to an intermediate server, such as Figure 1 The intermediate server 110 is shown. The intermediate server has at least one session group established therein. All endpoints in the session group are in communication connection with the intermediate server.

[0142] Figure 4 A flowchart of a data synchronization method provided in the second aspect of the present application is shown, including:

[0143] Step 410: In response to receiving the target data message sent by the initiator, parsing the synchronization identifier carried in the target data message;

[0144] Step 420: Determine a receiving end in the conversation group to which the initiating end belongs according to the synchronization type indicated by the synchronization identifier;

[0145] The synchronization type includes normal synchronization and failure retry;

[0146] Step 430: Send the target data message to the receiving end.

[0147] The target data message generated by the initiator is synchronized to the receiving end of the conversation group through the intermediate server. In this way, after receiving the target data message, the intermediate server first needs to know which endpoints the target data message is to be sent to.

[0148] The intermediate server can analyze the synchronization identifier carried in the target data message to learn the synchronization type indicated by the synchronization identifier, including normal synchronization and failure retry, and then determine the receiving end that matches the synchronization type in the conversation group to which the initiator belongs.

[0149] As described above, the initiating and receiving endpoints can jointly initiate an inter-group session with an intermediary server to create a session group. During the creation process, the intermediary server can obtain endpoint information for all endpoints in the session group and record it using the session group as the key and the endpoint information as the value. The endpoint information may include, but is not limited to, endpoint identifiers and endpoint addresses.

[0150] Exemplarily, the intermediate server may establish a session table, each session table recording endpoint information of all endpoints in a session group.

[0151] In this way, the intermediate server can use the session table to query all endpoints in the session group to which the initiator belongs, and then determine an endpoint matching the synchronization type from these endpoints as the receiving end.

[0152] Finally, the intermediate server sends the target data message to the receiving end. Exemplarily, the target data message can be forwarded to the receiving end via a communication link established with the receiving end.

[0153] As can be seen, the data synchronization method provided in the second aspect of this application utilizes the characteristic that the intermediate server is in communication with all endpoints in the session group. The intermediate server can forward the target data message of the initiator to multiple receiving ends. At the same time, by parsing the synchronization identifier carried by the target data message, the synchronization type of this synchronization is determined, and different endpoints are selected as receiving ends for different synchronization types. In this way, regardless of whether the initiator initiates normal synchronization or a failed retry, the intermediate server can select a matching endpoint as the receiving end, thereby realizing a one-to-many synchronization topology under unstable network conditions.

[0154] In some embodiments, a data synchronization method provided by the second aspect further includes: Figure 5 Steps shown:

[0155] Step 440: In response to receiving the result message sent by the receiving end, generating a target result message according to the result message;

[0156] The target result message is used to indicate the synchronization result of the data to be synchronized;

[0157] Step 450: Send the target result message to the initiator.

[0158] As described above, regardless of whether synchronization is successful or not, the receiving end can provide feedback on the synchronization result to the initiating end based on the target data message. In this embodiment, the receiving end provides feedback on the synchronization result to the initiating end via the intermediate server in the form of a result message. Because there are multiple receiving ends in a one-to-many synchronization topology, the intermediate server will receive multiple result messages from different receiving ends. Each result message provides feedback on the synchronization result of that receiving end.

[0159] The intermediate server can generate a target result message based on the result message and send the target result message to the initiator. The target result message is used to indicate the synchronization result of the data to be synchronized.

[0160] Alternatively, the intermediate server can directly use all received result messages as the target result message. This target result message is the collection of all received result messages. This collection of result messages is then sent to the initiator, which can then parse each result message one by one to determine the synchronization result for each receiving end.

[0161] Optionally, the intermediate server may merge all received result messages to generate a target result message. Exemplarily, the intermediate server may parse the result message to obtain the synchronization result indicated by each result message, and then merge all result messages according to the synchronization result to obtain the target result message.

[0162] For example, if all received result messages indicate that synchronization is successful, a target result message indicating that synchronization is successful is generated.

[0163] For another example, if a result message indicating synchronization failure is received, a target result message indicating synchronization failure of some receiving ends is generated.

[0164] A target result message indicating successful synchronization can be distinguished from a target result message indicating a partial synchronization failure by marking a different bit in a preset flag. The initiator can obtain the synchronization result of the data to be synchronized based on the marking information in the preset flag bit. For example, the preset flag bit can be a result flag.

[0165] In this way, the intermediate server generates a target result message by merging multiple result messages. The initiator can directly obtain the synchronization results of multiple receiving ends from the target result message, eliminating the need to parse multiple result messages one by one.

[0166] In this embodiment, by designing the receiving end to return a result message, the intermediate server generates a target result message based on the result message to feedback the synchronization result of the data to be synchronized to the initiating end, so that the initiating end can perform corresponding processing based on the synchronization result, including ending the synchronization process or initiating a failed retry data synchronization process, so as to realize an automatic one-to-many synchronization topology.

[0167] Regarding the process of generating the target result message, in some embodiments, the above step 440 may specifically include the following steps: Figure 6 Steps shown:

[0168] Step 441: parsing the plurality of result messages to determine the target receiving end that failed to synchronize the data to be synchronized;

[0169] Step 442: Generate a target result message indicating the synchronization result and the target receiving end.

[0170] As described above, the intermediate server may parse the result message to obtain the synchronization result indicated by each result message, thereby determining the target receiving end for which synchronization of the data to be synchronized has failed.

[0171] Optionally, if the result message indicates that the synchronization of the corresponding receiving end fails, the result message may carry the endpoint identifier of the receiving end.

[0172] Optionally, the result message may not carry the endpoint identifier. Instead, when the intermediate server parses the result message indicating synchronization failure, it determines the endpoint identifier of the receiving end that sent the result message in a pre-stored session table.

[0173] After determining the target receiving end, the intermediate server can generate a target result message indicating the synchronization result and the target receiving end. For example, the target result message can carry the endpoint identifier of the target receiving end, so that the initiator can determine the target receiving end where synchronization failed through the carried endpoint identifier.

[0174] In addition, the synchronization result and the endpoint identifier of the target receiving end can be recorded in the same identifier of the target result message. For example, the same identifier can be the result identifier as described above.

[0175] For example, if the flag carries a preset mark, it indicates that the data to be synchronized has been successfully synchronized. Alternatively, if the flag is blank, it indicates that there is no receiving end that has failed synchronization, and thus it can be determined that the data to be synchronized has been successfully synchronized. If the flag carries at least one endpoint identifier, it indicates that there is a target endpoint that has failed synchronization, and the target endpoint is the endpoint indicated by the endpoint identifier.

[0176] In this embodiment, the intermediate server generates a target result message that indicates the target receiving end. This allows the initiating end to determine which receiving ends have failed synchronization based on the target result message and then initiate data synchronization for the target receiving end. This eliminates the need to resynchronize all receiving ends without deviation, improves the intelligence of failure retry, and saves computing resources.

[0177] exist Figure 6 Based on the illustrated embodiment, the initiator may obtain the endpoint identifier of the target receiving end from the target result message, and record the obtained endpoint identifier in the synchronization identifier field, so that the generated synchronization identifier indicates the presence of the target receiving end.

[0178] Based on this, regarding the determination process of the receiving end, in some embodiments, step 420 may include the following: Figure 7 Steps shown:

[0179] Step 421: If the synchronization type is normal synchronization, determine that the endpoints other than the initiating end in the conversation group are receiving ends;

[0180] Step 422: If the synchronization type is failure retry, determine the target receiving end indicated by the synchronization identifier in the corresponding session group.

[0181] The intermediate server can determine whether the synchronization type is normal synchronization or failure retry by parsing the synchronization identifier carried in the target data message.

[0182] If the synchronization type is normal synchronization, this indicates that the data to be synchronized in the target data packet is being synchronized for the first time. Therefore, the intermediate server can determine that all endpoints in the session group to which the initiator belongs, excluding the initiator, are receiving endpoints. For example, the intermediate server can use a pre-stored session table to query all endpoints in the session group, then remove the initiator from the table. The remaining endpoints are the receiving endpoints.

[0183] If the synchronization type is "failure retry", it means that the data to be synchronized in the target data packet has been synchronized before, but at least some of the receivers failed to synchronize the data to be synchronized. Therefore, in this synchronization, you only need to re-initiate synchronization for the target receivers that failed synchronization before.

[0184] Since the synchronization identifier carried by the target data message indicates a target receiving end in the failed retry data synchronization process, the intermediate server can determine the target receiving end indicated by the synchronization identifier in the session group to which it belongs.

[0185] For example, the synchronization identifier field records an endpoint identifier, so the intermediate server can use the endpoint indicated by the endpoint identifier as the target receiving end. For example, the intermediate server can match the endpoint identifier recorded in the synchronization identifier field with a pre-stored session table to obtain the target receiving end.

[0186] In this embodiment, the intermediate server determines different endpoint groups as receiving ends according to the synchronization type, so that no matter whether the initiator initiates normal synchronization or failed retry, the intermediate server can filter out matching endpoints as receiving ends, thereby realizing a one-to-many synchronization topology under unstable network conditions.

[0187] As described above, multiple endpoints form at least one session group in the data synchronization system 100. When there are more than one session groups, the intermediate server needs to determine the session group to which the initiating endpoint belongs before synchronizing the target data message to the receiving endpoint in the session group.

[0188] Therefore, in some embodiments, the target data message also carries a session group identifier, wherein the session group identifier is used to indicate the session group to which the initiating end belongs. Exemplarily, the session group identifier can be identity information used to uniquely identify the session group.

[0189] Thus, step 420 may include the steps of: determining the conversation group to which the user belongs according to the conversation group identifier; and determining the receiving end from the conversation group.

[0190] For example, the intermediate server may store multiple session tables, each corresponding to a session group. Thus, the intermediate server may determine the matching target session table based on the session group identifier carried in the target data message, and then use the target session table to determine the receiving end.

[0191] For example, in normal synchronization, all endpoints except the initiating end recorded in the target session table are determined to be receiving ends.

[0192] For another example, in a failed retry, the endpoint identifier recorded in the synchronization identifier field is matched with the target session table to obtain the target receiving end.

[0193] In this embodiment, the intermediate server finds the session group to which the initiator belongs through the session group identifier carried in the target data message, so that it can accurately forward the target data message to the receiving end in the session group, completing the one-to-many synchronization topology within the session group.

[0194] In order to improve IO (Input / Output, read and write) performance and reduce data write and reading, in some embodiments, the target data message can be temporarily stored in the intermediate server in a volatile storage manner.

[0195] It is understood that volatile data storage also means that data is not persistent. When the intermediate server is powered off, the target data message in volatile storage will be lost. For example, the target data message can be stored in a volatile storage medium such as memory, cache, etc.

[0196] In this way, the target data message does not need to be written to the disk during the forwarding process. The intermediate server can directly reuse the network IO data sent by the initiator, avoiding the additional read and write operations generated by each receiving end pulling the target data message.

[0197] As an example, the steps and roles performed by the intermediate server in the entire data synchronization process are as follows: Figure 8 As shown:

[0198] First, the intermediate server receives the target data message sent by the initiator (step 801). The target data message carries a synchronization identifier and a session group identifier. In this way, the intermediate server can check whether there is a session group indicated by the session group identifier in the pre-stored session table (step 802). If the session group does not exist, a session exception message is returned to the initiator (step 803) and the process ends. If the session group exists, based on the synchronization type indicated by the synchronization identifier, the endpoint that matches the synchronization type is screened out from the session group as the receiving end (step 804), and the target data message is forwarded to each receiving end (step 805). Subsequently, the result message returned by each endpoint is collected and processed to generate a target result message (step 806). After returning the target result message to the initiator (step 807), the process ends.

[0199] From the receiver's perspective, after receiving the target data message, it can parse the target data message to obtain the data to be synchronized. Then, the data to be synchronized can be persisted, for example, by writing the data to disk and storing it in a non-volatile storage medium.

[0200] In this way, it can be set that if the receiving end succeeds in persisting the data to be synchronized, it is determined that the synchronization of the receiving end is successful; if the receiving end fails to persist the data to be synchronized, it is determined that the synchronization of the receiving end fails.

[0201] Optionally, after the data to be synchronized is persisted, the checksum carried in the target data message may be used to verify whether the data has been tampered with.

[0202] In this way, it can be set that if the receiving end successfully persists the data to be synchronized and passes the verification, the synchronization of the receiving end is determined to be successful; if the receiving end fails to persist the data to be synchronized or fails the verification, the synchronization of the receiving end is determined to be failed.

[0203] The receiving end can then generate a result message indicating the synchronization result of the local end and feed it back to the initiating end through the intermediate server. If the verification fails, the receiving end can also delete the persisted data to be synchronized.

[0204] For example, the synchronization result may be recorded in the result identification bit of the result message. Different synchronization results may be distinguished by marking the result identification bit differently.

[0205] In addition to the synchronization result, the result message can also carry other result information.

[0206] Optionally, the result information includes one or more combinations of the following: message type, session group identifier, result identifier, time, source address, data name, data size, failure reason, and number of failures.

[0207] The failure reason may include persistence failure or verification failure.

[0208] The number of failures can record the cumulative number of synchronization failures of the data to be synchronized.

[0209] Since the result information carried by the result message includes multiple items, the encapsulation format of the multiple items of information can be pre-set through a private protocol. For example, the multiple items of information can be encapsulated in the following format to generate a result message:

[0210]

[0211] Optionally, after encapsulating the above-mentioned multiple pieces of information, a protocol header of a transport layer protocol may be encapsulated before the encapsulated message, including but not limited to a TCP header, a UDP header, etc., to finally obtain a result message.

[0212] Exemplarily, if the intermediate server merges multiple result messages, it can also generate a target result message according to the above format.

[0213] In addition, from the perspective of the endpoint, as described above, an endpoint can be both an initiator and a receiver. When the endpoint detects that the synchronization trigger condition is met, it initiates data synchronization by executing a data synchronization method provided in the first aspect of the present application.

[0214] When an endpoint receives a message, it can Figure 9 The steps shown are used to process the message. Figure 9 As shown, after receiving a message (step 901), the endpoint first determines the message type (step 902). For example, the message type can be determined by parsing the message and based on the flag in the message type field. If the message type is a result message, the result message processing flow (including steps 903 and 904) is triggered; if the message type is a data message, the data message processing flow (including steps 905 and 910) is triggered.

[0215] During the result message processing process, the endpoint can determine that the received message is the target result message. In this way, the endpoint can determine whether the data to be synchronized is successfully synchronized based on the target result message (step 903). If successful, the data synchronization process and the result message processing process are terminated. If unsuccessful, a data synchronization process for failure retry is initiated (step 904), and the result message processing process is terminated. The implementation details of the data synchronization process for failure retry are described in the above embodiment, and this application will not be repeated here.

[0216] In the data message processing flow, the endpoint may determine that the received message is the target data message, and thus the endpoint may attempt to persist the data to be synchronized in the target data message (step 905).

[0217] If persistence fails, a result message indicating synchronization failure is generated (step 906), and the result message is returned to the intermediate server (step 907), and finally the data message processing flow ends.

[0218] If persistence is successful, the data is further verified using the checksum carried in the target data message (step 908). If the verification fails, the persisted data to be synchronized is deleted (step 909), a result message indicating synchronization failure is generated (step 906), and the result message is returned to the intermediate server (step 907), finally terminating the data message processing flow. If the verification passes, a result message indicating synchronization success is generated (step 910), and the result message is returned to the intermediate server (step 907), finally terminating the data message processing flow.

[0219] Regarding the application scenario of a data synchronization method provided in this application, the application scenario can be any scenario where there is a one-to-many synchronization topology requirement.

[0220] As an example, the application scenario of the present application may include a secure isolation scenario. The intermediate server may be a secure isolation device, such as, but not limited to, a gateway, a cross-network data security exchange platform, etc. The initiator may be an endpoint on one side of the secure isolation device, while the receiver may be an endpoint on the other side of the secure isolation device.

[0221] In this way, when endpoints on both sides of the security isolation device need to perform a one-to-many synchronization topology, they can apply to the security isolation device to establish an inter-group session and perform data synchronization through a data synchronization method provided by this application.

[0222] In some embodiments, the application scenario of the present application may include an instant messaging scenario. The intermediate server may be an instant messaging server, or other server connected to multiple endpoints.

[0223] In related technologies, when an instant messaging client needs to perform a one-to-many synchronization topology, the client uploads the data to be synchronized to a file server (not the instant messaging server). The file server stores the data to be synchronized persistently on disk and returns the address of the data to be synchronized on the file server to the instant messaging client. In this way, the instant messaging client shares the address with multiple clients, and the multiple clients use the address to obtain the data to be synchronized from the file server.

[0224] As can be seen, in the above solution, the data to be synchronized needs to be written to the disk once more in the file server, and the user needs to actively pull the data multiple times to complete the synchronization. The whole process has a high degree of human involvement.

[0225] Applying the data synchronization method provided by this application in an instant messaging scenario can, on the one hand, reduce the number of times data is written to the disk, and on the other hand, the entire data synchronization process is automatic without the need for human intervention.

[0226] The third aspect of the present application also provides a data synchronization system, including an intermediate server and multiple endpoints. The multiple endpoints form at least one session group, and the multiple endpoints include an initiating end and a receiving end. As one embodiment, it can be as follows Figure 1 The data synchronization system 100 is shown.

[0227] The initiator is configured to obtain the data to be synchronized in response to the synchronization trigger condition being met; and

[0228] Determine the synchronization type of this synchronization and generate a synchronization identifier according to the synchronization type; wherein the synchronization type includes normal synchronization and failure retry; and

[0229] Encapsulating a target data message based on the synchronization identifier and the data to be synchronized; and

[0230] Sending the target data message to the intermediate server;

[0231] The intermediate server is configured to, in response to receiving a target data message sent by the initiator, parse the synchronization identifier carried in the target data message; and

[0232] Determining a receiving end in the conversation group to which the initiating end belongs according to the synchronization type indicated by the synchronization identifier; and

[0233] Send the target data message to the receiving end.

[0234] In some embodiments, the initiator is further configured to:

[0235] In response to receiving a target result message fed back based on the target data message, determining a synchronization result of the data to be synchronized according to the target result message; and

[0236] If the synchronization result is a synchronization failure, it is determined that the synchronization trigger condition is met, the data synchronization process is returned to be executed, and the synchronization type is determined to be the failure retry.

[0237] In some embodiments, the target result message further indicates a target receiving end with synchronization failure; in this case, the initiator is configured to:

[0238] generating a synchronization identifier indicating the target receiving end; and

[0239] The target data message is synchronized to the target receiving end through an intermediate server.

[0240] In some embodiments, the initiator is further configured to:

[0241] generating a conversation group identifier according to the conversation group to which the initiating end belongs;

[0242] Based on the synchronization identifier, the session group identifier and the data to be synchronized, a target data message is encapsulated to obtain the target data message.

[0243] In some embodiments, the intermediate server is further configured to:

[0244] In response to receiving the result message sent by the receiving end, generating a target result message according to the result message; the target result message is used to indicate the synchronization result of the data to be synchronized;

[0245] Send the target result message to the initiator.

[0246] In some embodiments, the result message includes multiple messages, and the intermediate server is specifically used to:

[0247] Parsing the plurality of result messages to determine a target receiving end that failed to synchronize the data to be synchronized;

[0248] A target result message indicating the synchronization result and the target receiving end is generated.

[0249] In some embodiments, the intermediate server is specifically configured to:

[0250] If the synchronization type is normal synchronization, determining endpoints other than the initiating end in the conversation group as receiving ends;

[0251] If the synchronization type is failure retry, a target receiving end indicated by the synchronization identifier is determined in the corresponding session group.

[0252] In some embodiments, the target data message further carries a session group identifier; the intermediate server is specifically configured to:

[0253] Determining the conversation group to which the user belongs according to the conversation group identifier;

[0254] A receiving end is determined from the conversation group.

[0255] In some embodiments, the target data message is volatilely stored in the intermediate server.

[0256] The implementation process of the functions and effects of each device in the above system is specifically described in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0257] The fourth aspect of the present application provides a data synchronization device for realizing data synchronization of multiple endpoints in a conversation group; the device is applied to the initiating end in the conversation group. Figure 10 As shown, a data synchronization device 1000 includes:

[0258] An acquisition module 1010 is configured to acquire data to be synchronized in response to a synchronization trigger condition being met;

[0259] The generating module 1020 is used to determine the synchronization type of this synchronization and generate a synchronization identifier according to the synchronization type; wherein the synchronization type includes normal synchronization and failure retry;

[0260] An encapsulation module 1030 is configured to encapsulate a target data message based on the synchronization identifier and the data to be synchronized;

[0261] The synchronization module 1040 is configured to synchronize the target data message to the receiving end of the conversation group via an intermediate server.

[0262] In some embodiments, a data synchronization device 1000 further includes:

[0263] a synchronization result determining module, configured to, in response to receiving a target result message fed back based on the target data message, determine a synchronization result of the data to be synchronized according to the target result message; and

[0264] The return module is used to determine whether the synchronization trigger condition is met if the synchronization result is a synchronization failure, return to execute the data synchronization process, and determine the synchronization type as the failure retry.

[0265] In some embodiments, the target result message further indicates a target receiving end with synchronization failure; the generating module 1020 is specifically configured to:

[0266] generating a synchronization identifier indicating the target receiving end;

[0267] The synchronization module 1040 is specifically used for:

[0268] The target data message is synchronized to the target receiving end through an intermediate server.

[0269] In some embodiments, a data synchronization device 1000 further includes:

[0270] A conversation group identification module, configured to generate a conversation group identification according to the conversation group to which the initiating end belongs;

[0271] The encapsulation module 1030 is specifically used for:

[0272] Based on the synchronization identifier, the session group identifier and the data to be synchronized, a target data message is encapsulated to obtain the target data message.

[0273] The implementation process of the functions and effects of each module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0274] In a fifth aspect, the present application provides a data synchronization device for realizing data synchronization of multiple endpoints in a conversation group; the device is applied to an intermediate server, the intermediate server is in communication connection with multiple endpoints, and the intermediate server has established at least one conversation group. Figure 11 As shown, a data synchronization device 1100 includes:

[0275] The parsing module 1110 is configured to, in response to receiving a target data message sent by the initiator, parse the synchronization identifier carried in the target data message;

[0276] The determining module 1120 is configured to determine the receiving end in the conversation group to which the initiating end belongs according to the synchronization type indicated by the synchronization identifier; wherein the synchronization type includes normal synchronization and failure retry;

[0277] The sending module 1130 is configured to send the target data message to the receiving end.

[0278] In some embodiments, a data synchronization apparatus 1100 further includes:

[0279] a message generating module, configured to generate a target result message according to the result message in response to receiving the result message sent by the receiving end; the target result message is used to indicate the synchronization result of the data to be synchronized;

[0280] A message sending module is used to send the target result message to the initiating end.

[0281] In some embodiments, the result message includes multiple messages, and the message generation module is specifically used to:

[0282] Parsing the plurality of result messages to determine a target receiving end that failed to synchronize the data to be synchronized;

[0283] A target result message indicating the synchronization result and the target receiving end is generated.

[0284] In some embodiments, the determination module 1120 is specifically configured to:

[0285] If the synchronization type is normal synchronization, determining endpoints other than the initiating end in the conversation group as receiving ends;

[0286] If the synchronization type is failure retry, a target receiving end indicated by the synchronization identifier is determined in the corresponding session group.

[0287] In some embodiments, the target data message further carries a session group identifier; the determination module 1120 is specifically configured to:

[0288] Determining the conversation group to which the user belongs according to the conversation group identifier;

[0289] A receiving end is determined from the conversation group.

[0290] In some embodiments, the target data message is volatilely stored in the intermediate server.

[0291] The implementation process of the functions and effects of each module in the above-mentioned device is specifically described in the implementation process of the corresponding steps in the above-mentioned method, and will not be repeated here.

[0292] Based on the data synchronization method described in any embodiment of the first aspect and the second aspect above, the sixth aspect of the present application further provides: Figure 12 A schematic diagram of the structure of an electronic device is shown in FIG. Figure 12At the hardware level, the electronic device includes a processor, an internal bus, a network interface, memory, and non-volatile storage, and may also include hardware required for other services. The processor reads the corresponding computer program from the non-volatile storage into the internal memory and then runs it to implement the data synchronization method described in any embodiment of the first aspect and / or the data synchronization method described in any embodiment of the second aspect.

[0293] In some embodiments, an electronic device may be an endpoint, and a processor of the endpoint reads a corresponding computer program from a non-volatile memory into a memory and then runs the program to implement a data synchronization method described in any embodiment of the first aspect.

[0294] In some embodiments, an electronic device may be an intermediate server. A processor of the intermediate server reads a corresponding computer program from a non-volatile memory into a memory and then runs the program to implement a data synchronization method described in any embodiment of the second aspect.

[0295] The seventh aspect of the present application also provides a computer storage medium, which stores a computer program. When the computer program is executed by a processor, it can be used to execute a data synchronization method described in any embodiment of the first aspect above, and / or a data synchronization method described in any embodiment of the second aspect above.

[0296] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions and operations of the devices, methods and computer program products according to the multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of the code, and the module, program segment or a part of the code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

[0297] In addition, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0298] If the functions are implemented in the form of software function modules and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application, or the part that contributes to the prior art or the part of the technical solution, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0299] The foregoing is merely an embodiment of the present application and is not intended to limit the scope of protection of the present application. Various modifications and variations are possible for those skilled in the art. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application shall be included within the scope of protection of the present application. It should be noted that similar reference numerals and letters represent similar items in the following figures. Therefore, once an item is defined in one figure, it does not need to be further defined or explained in subsequent figures.

[0300] The above description is merely a specific embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included in the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

[0301] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

Claims

1. A data synchronization method, characterized in that: The method is used to achieve data synchronization of multiple endpoints in a conversation group; The method is applied to the initiating end in the conversation group, and the method includes: In response to the synchronization trigger condition being met, the following data synchronization process is executed: Get the data to be synchronized; Determine the synchronization type of this synchronization and generate a synchronization identifier according to the synchronization type; wherein the synchronization type includes normal synchronization and failure retry; Encapsulating the synchronization identifier and the session group identifier into the data to be synchronized to obtain a target data message; the session group identifier is used to indicate the session group to which the initiator belongs; The target data message is sent to the intermediate server, so that the intermediate server determines the synchronization type by parsing the synchronization identifier carried by the target data message, and determines the session group to which the initiator belongs through the session group identifier, and determines the receiving end in the session group according to the synchronization type indicated by the synchronization identifier, and synchronizes the target data message to the receiving end; wherein, if the synchronization type is normal synchronization, the receiving end is the endpoint in the session group other than the initiator; if the synchronization type is failure retry, the receiving end is the target receiving end indicated by the synchronization identifier in the session group.

2. The method according to claim 1, characterized in that The method further comprises: In response to receiving a target result message fed back based on the target data message, determining a synchronization result of the data to be synchronized according to the target result message; If the synchronization result is a synchronization failure, it is determined that the synchronization trigger condition is met, the data synchronization process is returned to be executed, and the synchronization type is determined to be the failure retry.

3. The method according to claim 2, characterized in that The target result message also indicates a target receiving end that has failed synchronization; The generating of a synchronization identifier according to the synchronization type includes: generating a synchronization identifier indicating the target receiving end; The synchronizing the target data message to the receiving end of the conversation group through the intermediate server includes: synchronizing the target data message to the target receiving end through the intermediate server.

4. The method according to claim 1, wherein The method further comprises: A session group identifier is generated according to the session group to which the initiating end belongs.

5. A data synchronization method, characterized in that: The method is used to achieve data synchronization of multiple endpoints in a conversation group; the method is applied to an intermediate server, the intermediate server is in communication connection with multiple endpoints, and the intermediate server has established at least one conversation group; the method includes: In response to receiving a target data message sent by an initiator, parsing a synchronization identifier carried in the target data message, and determining the session group to which the initiator belongs based on the session group identifier carried in the target data message; the target data message is obtained by the initiator encapsulating the synchronization identifier and the session group identifier into data to be synchronized; Determine a receiving end in the conversation group to which the initiating end belongs according to the synchronization type indicated by the synchronization identifier; wherein the synchronization type includes normal synchronization and failure retry; wherein, if the synchronization type is normal synchronization, the receiving end is an endpoint in the conversation group other than the initiating end; and if the synchronization type is failure retry, the receiving end is a target receiving end indicated by the synchronization identifier in the conversation group; Send the target data message to the receiving end.

6. The method according to claim 5, characterized in that The method further comprises: In response to receiving the result message sent by the receiving end, generating a target result message according to the result message; the target result message is used to indicate the synchronization result of the data to be synchronized; Send the target result message to the initiator.

7. The method according to claim 6, characterized in that The result message includes a plurality of messages, and generating a target result message according to the result message includes: Parsing the plurality of result messages to determine a target receiving end that failed to synchronize the data to be synchronized; A target result message indicating the synchronization result and the target receiving end is generated.

8. The method according to claim 5, characterized in that The target data message is volatilely stored in the intermediate server.

9. A data synchronization system, characterized in that: The system includes an intermediate server and multiple endpoints; the multiple endpoints form at least one conversation group; the multiple endpoints include an initiating end and a receiving end; The initiator is configured to obtain the data to be synchronized in response to the synchronization triggering condition being met; as well as Determine the synchronization type of this synchronization and generate a synchronization identifier according to the synchronization type; wherein the synchronization type includes normal synchronization and failure retry; and Encapsulating the synchronization identifier and the conversation group identifier into the data to be synchronized to obtain a target data message; the conversation group identifier is used to indicate the conversation group to which the initiating end belongs; the target data message is obtained by the initiating end encapsulating the synchronization identifier and the conversation group identifier into the data to be synchronized; and Sending the target data message to the intermediate server; The intermediate server is configured to, in response to receiving a target data message sent by the initiator, parse the synchronization identifier carried in the target data message, and determine the session group to which the initiator belongs based on the session group identifier carried in the target data message; and Determine a receiving end in the conversation group to which the initiator belongs according to the synchronization type indicated by the synchronization identifier; wherein, if the synchronization type is normal synchronization, the receiving end is an endpoint other than the initiator in the conversation group; if the synchronization type is failure retry, the receiving end is a target receiving end indicated by the synchronization identifier in the conversation group; and Send the target data message to the receiving end.

10. A data synchronization device, characterized in that: The device is used to achieve data synchronization of multiple endpoints in a conversation group; The device is applied to an initiating end in the conversation group, and includes: An acquisition module, configured to acquire data to be synchronized in response to a synchronization trigger condition being met; A generation module, configured to determine the synchronization type of this synchronization and generate a synchronization identifier according to the synchronization type; wherein the synchronization type includes normal synchronization and failure retry; An encapsulation module, configured to encapsulate the synchronization identifier and the conversation group identifier into the data to be synchronized to obtain a target data message; the conversation group identifier is used to indicate the conversation group to which the initiating end belongs; A synchronization module is used to send the target data message to an intermediate server, so that the intermediate server determines the synchronization type by parsing the synchronization identifier carried by the target data message, and determines the session group to which the initiator belongs through the session group identifier, and determines the receiving end in the session group according to the synchronization type indicated by the synchronization identifier, and synchronizes the target data message to the receiving end; wherein, if the synchronization type is normal synchronization, the receiving end is the endpoint in the session group other than the initiator; if the synchronization type is failure retry, the receiving end is the target receiving end indicated by the synchronization identifier in the session group.

11. A data synchronization device, characterized in that: The device is used to synchronize data between multiple endpoints in a conversation group. The device is applied to an intermediate server, the intermediate server is in communication with multiple endpoints, and the intermediate server has established at least one conversation group. The device includes: a parsing module configured to, in response to receiving a target data message sent by an initiating end, parse a synchronization identifier carried in the target data message, and determine the session group to which the initiating end belongs based on the session group identifier carried in the target data message; the target data message is obtained by the initiating end encapsulating the synchronization identifier and the session group identifier into data to be synchronized; a determination module, configured to determine a receiving end in the conversation group to which the initiating end belongs based on the synchronization type indicated by the synchronization identifier; wherein the synchronization type includes normal synchronization and failure retry; wherein, if the synchronization type is normal synchronization, the receiving end is an endpoint in the conversation group other than the initiating end; and if the synchronization type is failure retry, the receiving end is a target receiving end indicated by the synchronization identifier in the conversation group; A sending module is used to send the target data message to the receiving end.

12. An electronic device, characterized in that: The electronic device comprises: processor; a memory for storing processor-executable instructions; Wherein, when the processor calls the executable instruction, it implements the operation of any method described in claims 1-4 or 5-8.

13. A computer-readable storage medium, characterized in that Computer instructions are stored thereon, and when the computer instructions are executed by a processor, the steps of any one of the methods of claims 1-4 or 5-8 are implemented.

Images