CN105450682B - Method, device and system for synchronously storing data and synchronizing data to client - Google Patents
Method, device and system for synchronously storing data and synchronizing data to client Download PDFInfo
- Publication number
- CN105450682B CN105450682B CN201410389659.0A CN201410389659A CN105450682B CN 105450682 B CN105450682 B CN 105450682B CN 201410389659 A CN201410389659 A CN 201410389659A CN 105450682 B CN105450682 B CN 105450682B
- Authority
- CN
- China
- Prior art keywords
- data
- record
- server
- client
- data record
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Landscapes
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Information Transfer Between Computers (AREA)
Abstract
The application discloses a method, a device and a system for synchronizing a server side to a client side for data submission, wherein the method for synchronizing the server side to the client side comprises the following steps: sending a request for synchronizing data to a server; receiving a data record stored by a server; acquiring a failure data list locally stored by a client; judging whether the data record exists in a failure data list or not; if not, judging whether the data record exists in the local database, if so, updating the data record, and if not, inserting the data record into the local database; if yes, comparing the updating time of the two data, and if the data record is updated, updating the data record into a local database; otherwise, the data record is abandoned, and the corresponding data in the local database is reserved. Correspondingly, the application also provides a data storage method. Through the technical scheme of the application, data can be stored in a non-network state, and the data on various devices are kept synchronous.
Description
Technical Field
The present application relates to the field of data synchronization technologies, and in particular, to a method and an apparatus for data synchronization storage, a method and an apparatus for a server to synchronize data to a client, and a system for data synchronization storage and data synchronization to a client.
Background
With the development of mobile applications, more and more applications start to support multiple clients, and not only pc versions, but also android versions, ios versions and the like are respectively suitable for multiple application versions of different operating systems. And the data interacted by the user through the clients can be synchronized at multiple ends, for example, the content received or transmitted by the user on the android version can be seen on the ios version, and can be seen by replacing an android mobile phone. The conventional method ensures that the user data is synchronized at a plurality of client terminals on the premise that all data is subject to the data of the server terminal, and even if some local data is stored at the client terminal, the local data is replaced by the server terminal data when the client terminal performs judging and repeating processing with the server terminal data. And the data stored by the client is also submitted to the server successfully, namely the client does not store the data when the feedback of the server fails.
because the existing technical scheme has to rely on various conditions such as good network conditions and normal server service at that time when data is submitted, the defects are that the dependence conditions are very many, each dependence can cause failure when data is submitted, data input by a user in a client cannot be submitted normally or cannot be stored in a server database after being submitted, the data input by the user cannot be stored in the client database, and the data cannot be synchronized to other clients, the data update fails, and troubles are caused to the user, so the use of the user is very inconvenient.
Disclosure of Invention
The application provides a method and a device for data synchronous storage, which are used for solving the problems of the existing data synchronous storage method. The application also provides a method and a device for synchronizing data from the server side to the client side, and a system for synchronizing data.
The embodiment of the application provides a data synchronous storage method, which comprises the following steps:
Sending a synchronous storage request to a server, wherein the synchronous storage request comprises synchronous data submitted in a client;
After the server side feeds back the message that the synchronous data is successfully stored, a synchronous success label is added to the synchronous data; after the server side feeds back the message that the storage of the synchronous data fails or after the feedback of the synchronous request from the server side is not received within the set time, adding a synchronous failed label to the synchronous data;
And storing the synchronous data in a local database.
optionally, the storing the synchronization data in a local database specifically includes:
And storing the data storage time, the data content, the tag and the unique ID of the data of the synchronous data in a local database.
optionally, the method for synchronously storing data further includes:
When the network communication of the client is detected to be normal, sending a synchronous storage request to the server again aiming at the data record added with the synchronous failure label in the local database;
And after receiving the message of successful storage of the synchronous data fed back by the server, modifying the failed label of the data record into a synchronous successful label.
Optionally, the method for synchronously storing data further includes:
And after receiving the message of successful synchronous data storage fed back by the server, modifying the data storage time of the data record into the time corresponding to the time when the synchronous storage request is sent to the server again.
Optionally, in the step of storing the synchronization data in the local database, when the data is stored, the data with the successful tag and the data with the failed tag are stored in the same database table.
optionally, in the step of storing the synchronization data in the local database, when the data is stored, the data with the successful tag and the data with the failed tag are stored separately and stored in different database tables.
Correspondingly, the present application also provides an apparatus for synchronously saving data, including:
The sending module is used for sending a synchronous storage request to the server side, wherein the synchronous storage request comprises synchronous data submitted in the client side;
The tag adding module is used for adding a synchronization success tag to the synchronization data stored in the local database after the server side feeds back the message that the synchronization data is successfully stored; after the server side feeds back the message that the storage of the synchronous data fails or after the feedback of the synchronous request from the server side is not received within the set time, adding a synchronous failed tag to the synchronous data stored in the local data;
and the local database module is used for storing the synchronous data in a local database.
Optionally, the local database module is specifically configured to store the data storage time, the data content, the tag of the synchronized data, and the unique ID of the data.
Optionally, the sending module further includes:
And the synchronous data storage failure sending unit is used for sending a synchronous storage request to the server again aiming at the data record added with the synchronous failure label in the local database when the network communication of the client is detected to be normal.
optionally, the adding module further includes:
and the label modifying unit is used for modifying the failed label of the data record into a synchronous successful label after receiving the message that the synchronous data fed back by the server end is successfully stored.
Optionally, the local database module further includes:
And the storage time modifying unit is used for modifying the data storage time of the data record into the time corresponding to the synchronous storage request sent to the server again after receiving the message that the synchronous data storage fed back by the server is successful.
Optionally, the local database module is specifically configured to, in the step of storing the synchronization data in the local database, store the data with the successful tag and the data with the failed tag in the same database table when storing the data.
optionally, the local database module is specifically configured to store the synchronization data in a local database, and when the data is stored, store the data with the successful tag and the data with the failed tag separately, and store the data in different database tables.
according to another aspect of the present application, an embodiment of the present application further provides a method for a server to synchronize data to a client, where when a synchronization request is submitted, the method may be that the client sends a request to the server; or the server side sends a request to the client side; or a request sent in both directions between the client and the server, the method comprises the following steps:
sending a request for synchronizing data to a server;
receiving a synchronous data record which is sent by the server end aiming at the request and is stored by the server end;
acquiring a failure data list which is locally stored by a client and fails to be synchronously stored to a server;
Judging whether each data record of the synchronous data records exists in the failure data list one by one; if not, further judging whether the data record exists in a database to be synchronized of the client, if so, updating the data record, and if not, inserting the data record into the database to be synchronized;
If so, judging which record of the data record corresponding to the failure data list is an updated record, and if the data record is the updated data record, updating the data record to the database to be synchronized; and if the record in the failure data list is a new record, discarding the data record and reserving the corresponding data record in the database to be synchronized.
optionally, each of the synchronized data records includes: data update time, data content, and a unique ID for each piece of data.
Optionally, each record in the failure data list includes: data update time, data content, and a unique ID for each piece of data.
optionally, the receiving, by the server, the synchronization data record stored by the server for requesting to issue includes:
Receiving all synchronous data records stored by the server side issued by the server side aiming at the request; or
And receiving the synchronous data record updated after the previous request stored by the server terminal aiming at the request issued by the server terminal.
optionally, the obtaining a failure data list that is locally stored by the client and fails to be synchronously stored to the server includes:
Traversing all data records of a local database when the client synchronously stores data to the server;
and identifying and selecting the data records with the labels as the synchronization failure labels to form a data record set with the labels as the synchronization failure labels as a failure data list.
Optionally, the obtaining a failure data list that is locally stored by the client and fails to be synchronously stored to the server includes:
And acquiring a data record list with a label as a synchronization failure label when the client synchronously stores data to the server as the failure data list.
Optionally, in the step of determining which record of the data record corresponding to the failed data list is an updated record, the determination of which data record is a new record is made by determining a retention time or a version of the data record.
Correspondingly, the present application also provides an apparatus for a server to synchronize data to a client, including:
the request module is used for sending a request of synchronous data to the server;
The receiving module is used for receiving the synchronous data record which is sent by the server end aiming at the request and is stored by the server end;
The failure data list module is used for acquiring a failure data list which is locally stored by the client and fails to be synchronously stored to the server;
And the judging module is used for judging whether each data record of the synchronous data records exists in the failure data list one by one.
Optionally, the receiving module is specifically configured to receive synchronous data records, where each received synchronous data record includes: data update time, data content, and a unique ID for each piece of data.
Optionally, the failed data list module is specifically configured to store data with a failed tag, where each record in the failed data list includes: data update time, data content, and a unique ID for each piece of data.
optionally, the failure data list module is configured to traverse all data records of a local database when the client synchronously stores data to the server; and identifying and selecting the data records with the labels as the synchronization failure labels to form a data record set with the labels as the synchronization failure labels as the failure data list.
Optionally, the failed data list module is configured to obtain a data record list, where a tag formed when the client synchronously stores data to the server is a synchronization failed tag, as the failed data list.
Optionally, the determining module specifically includes:
And the data record judging unit is used for judging whether the data record exists in a database to be synchronized of the client, if so, updating the data record, and if not, inserting the data record into the data to be synchronized.
A modification time determining unit, configured to determine which record of the data record corresponding to the failure data list is an updated record, and if the data record is an updated data record, update the data record to the to-be-synchronized database; and if the record in the failure data list is a new record, discarding the data record and reserving the corresponding data record in the database to be synchronized.
optionally, the modification time determining unit is configured to determine which data record is a new record by determining a saving time or a version of the data record in the step of determining which record of the data record corresponding to the failed data list is an updated record.
In addition, the present application further provides a system for synchronizing data from a server to a client for data submission, including: the device for synchronously storing the data and the device for the server side to synchronize the data to the client side are provided.
The technical scheme provided by the embodiment of the application has the following beneficial effects:
the success or failure label added for the synchronous stored data is used for management, so that the problem of synchronous stored data submission under the condition of no network is solved, the synchronous state of the data and the server side is stored locally, and the data input by a user can be stored in a local database of the client side when the data cannot be submitted to the server side.
When the server side data and the local data are synchronized by using the method for synchronizing the data from the server side to the client side, the local data is considered to be updated compared with the server side data, and under the condition that the local data is updated later and the synchronization state is failed, the local data is taken as the standard instead of the synchronous data stored by the server side, so that the consistency of the data can be always ensured even if a plurality of devices across platforms are used by a user.
Drawings
in order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings needed to be used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments described in the present application, and other drawings can be obtained by those skilled in the art according to the drawings.
FIG. 1 is a flow chart of an embodiment of a method for synchronized saving of data of the present application;
FIG. 2 is a schematic diagram of an embodiment of an apparatus for synchronous saving of data according to the present application;
FIG. 3 is a flowchart of an embodiment of a method for server-side to client-side synchronization of data according to the present application;
FIG. 4 is a schematic diagram of an embodiment of an apparatus for server-side to client-side synchronization of data according to the present application;
FIG. 5 is a schematic diagram of an embodiment of a server-side to client data synchronization system for data submission of the present application.
Detailed Description
the embodiment of the application provides a method, a device and a system for synchronously storing data and synchronizing data to a client.
In order that the above objects, features and advantages of the present application can be more clearly understood, the present application will be described in further detail with reference to the accompanying drawings and detailed description. It should be noted that the embodiments and features of the embodiments of the present application may be combined with each other without conflict.
In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present application. This application is capable of implementation in many different ways than those herein set forth and of similar import by those skilled in the art without departing from the spirit of this application and is therefore not limited to the specific implementations disclosed below.
In the application, a method and a device for data synchronous storage, a method and a device for server-side data synchronization to a client, and a server-side data synchronization to the client for data submission are respectively provided. Details are described in the following examples one by one.
Referring to fig. 1, a schematic flow chart diagram of an embodiment of a method for data synchronous saving according to the present application is shown. The data synchronous storage method comprises the following steps:
Step 101, sending a synchronous storage request to a server, where the synchronous storage request includes synchronous data submitted in a client.
In the method of this embodiment, when the client sends the synchronous storage request to the server, a communication link is established between the server and the client, and a connection is established on the communication link. The connection is used for maintaining the communication state between the server side and the client side. After the connection is established between the server and the client, the server receives a data synchronous storage request sent by the client based on the connection. The server side can store the synchronous data submitted by the client side according to the received data synchronous storage request. The sync data included in the sync save request includes data newly input or modified by the user in the client. If the synchronization data includes the newly input data, the client adds an ID for distinguishing each piece of data to the data.
For example, the user modifies the existing content information or inputs a new data record in the client, and after the modification or input is completed, the user clicks a save or submit button, and the client submits the information to the server for synchronous saving. If the user inputs a new data record in the client, the client adds an ID for distinguishing each piece of data to the piece of data. The client can be a mobile phone, a pc and other terminal equipment.
As for the method in which the client adds the ID for distinguishing each piece of data to the data, a way of adding a timestamp, which is the time when new data is input, may be adopted; or a unique Hash value calculated by a Hash (Hash) algorithm is used as the unique ID of the data; or in other ways, and is not limited herein.
103, after feeding back the message that the synchronous data is successfully stored, the server adds a synchronous success label to the synchronous data; and after the server side feeds back the message that the storage of the synchronous data fails or after the feedback of the server side about the synchronous request is not received within the set time, adding a synchronous failed label to the synchronous data.
and the client adds different labels to the synchronous data through different information fed back by the server. If a communication link is successfully established between a server and a client and a connection is established on the communication link, the server receives a synchronous storage request sent by the client and stores synchronous data in the synchronous storage request in a database of the server, the server feeds back a message that the synchronous data is successfully stored to the client, and the client adds a synchronous success label to the synchronous data after receiving the message fed back by the server; if the communication link is not successfully established between the server and the client, the communication link is successfully established between the server and the client, but the server does not receive the synchronous storage request sent by the client or the communication link is successfully established between the server and the client, the server receives the synchronous storage request sent by the client, but the data is not successfully stored in a database of the server, the server feeds back a message that the synchronous data storage fails to the client, and the client adds a synchronous failure label to the synchronous data after receiving the message fed back by the server; the server side feeds back the synchronous data storage message to the client side, but the client side does not receive the feedback of the server side about the synchronous request in the set time, and the client side also adds a synchronous failure label to the synchronous data.
Step 105, storing the synchronization data in a local database.
the local database is used for managing the tables stored in the local database, and the tables stored in the local database can be in various forms such as a mesh type, a relational type and an object-oriented type. Here, the table stored in the local database may also be simply referred to as a database table.
After the client adds the label to the synchronous data, the client stores the synchronous data in the synchronous storage request added with the label in a local database. When preserving synchronized data, a consideration is whether the tag of the data is a failed tag. Specifically, firstly, the synchronous data is saved in a local database; then, judging whether the label of the stored synchronous data is a failure label, if not, finishing the storage; if so, after the storage is finished, the client sends the synchronous storage request to the server again according to the preset time interval, when the client is started, when the client is closed or when the network environment of the client is changed. For example, sending a synchronized save request to the server for data records tagged as failed may be performed periodically, such as with a commit performed every 30 minutes. At this time, a timer may be set, and the timing duration of the timer is equal to the preset time interval, and the trigger condition is the timing duration of the timer. The synchronization data stored in the local database specifically includes: the retention time of the synchronization data, the data content, the tag, and the unique ID of the data.
after the client sends the data record with the label as the failure to the server again to send a synchronous storage request, if the client receives a message that the synchronous data storage fed back by the server is successful, the client modifies the failure label of the data record as a synchronous successful label, and modifies the data storage time of the data record as the time corresponding to the synchronous storage request sent to the server again.
For example, a user adds a piece of data through a client, the client is in a no-network state (when network communication is abnormal) when submitting the data, and the client does not receive information fed back by the server, so that the client adds a failure tag to the data and stores the data in a local database, and the storage time is 201407221149. When the network communication of the client side is detected to be normal (for example, the network communication state is changed from the non-networking state to the network connection state), the client side immediately submits the data to the server side, after a message that the synchronous data fed back by the server side is successfully stored is received, the failure label of the data record is modified into a synchronous success label, the data storage time of the data record is modified into the time corresponding to the synchronous storage request sent to the server again, and the modified storage time is 201407221249.
Optionally, when the synchronous data is stored in the local database, the data with the successful label and the data with the failed label may be stored in the same database table; data with a successful tag may also be stored separately from data with a failed tag in a different database table.
In the embodiment, the application further provides a device for synchronously saving the data. Please refer to fig. 2, which is a schematic diagram of an embodiment of an apparatus for synchronous saving of data according to the present application. Since the apparatus embodiments are substantially similar to the method embodiments, they are described in a relatively simple manner, and reference may be made to some of the descriptions of the method embodiments for relevant points. The device embodiments described below are merely illustrative.
An apparatus for synchronously saving data according to this embodiment includes: a sending module 201, configured to send a synchronous storage request to a server, where the synchronous storage request includes synchronous data submitted in a client; the local database module 203 is used for storing the synchronous data in a local database; a tag adding module 205, configured to add a successful synchronization tag to the synchronization data stored in the local database after the server side feeds back the message that the synchronization data is successfully stored; and after the server side feeds back the message that the storage of the synchronous data fails or after the feedback of the server side about the synchronous request is not received within the set time, adding a synchronous failed label to the synchronous data stored in the local data.
Optionally, the local database module is specifically configured to store the data storage time, the data content, the tag of the synchronized data, and the unique ID of each piece of data.
optionally, the sending module further includes:
and the synchronous saving data failure sending unit is used for sending a synchronous saving request to the server again aiming at the data record added with the synchronous failure label in the local database.
Optionally, the adding module further includes:
and the label modifying unit is used for modifying the failed label of the data record into a synchronous successful label after receiving the message that the synchronous data fed back by the server end is successfully stored.
Optionally, the local database module further includes:
And the storage time modifying unit is used for modifying the data storage time of the data record into the time corresponding to the synchronous storage request sent to the server again after receiving the message that the synchronous data storage fed back by the server is successful.
optionally, the local database module is specifically configured to, in the step of storing the synchronous data in the local database, store data tagged with a success and tagged with a failure in the same database table when storing the data.
optionally, the local database module is specifically configured to, in the step of storing the synchronized data in the local database, store the data tagged as successful in the step of storing the synchronized data in a different database table from the data tagged as failed in the step of storing the synchronized data.
The application provides a method for synchronizing data from a server side to a client side. Please refer to fig. 3, which is a flowchart illustrating an embodiment of a method for a server to synchronize data to a client according to the present application, the method includes:
step 301, a request for synchronizing data is sent to a server.
in the method of this embodiment, when the client sends a request for synchronizing data to the server, a communication link is established between the server and the client, and a connection is established on the communication link. The connection is used for maintaining the communication state between the server side and the client side. After the connection is established between the server and the client, the server receives a request for synchronizing data sent by the client based on the connection. The server side can synchronize data with the client side according to the received request for synchronizing data.
The client may send a request to the server to synchronize data at predetermined intervals, each time the client starts up, each time the client shuts down, or each time user data changes. The request for synchronizing data described in this embodiment may be a request sent by a client to a server; or the server side sends a request to the client side; or a request sent bi-directionally between a client and a server.
Step 303, receiving the synchronous data record stored by the server side, which is issued by the server side according to the request.
and when the synchronization request is successful, the client receives the synchronization data record which is sent by the server and stored by the server. For example, the sent synchronous data records stored by the server may be all synchronous data records stored by the server for the request sent by the receiving server; or receiving the synchronous data records updated by the server after the previous request stored by the server and issued according to the request, and arranging according to the update time of each piece of data stored by the server, wherein the issued synchronous data records stored by the server specifically include: data update time, data content, and a unique ID for each piece of data.
Step 305, acquiring a failure data list which is locally stored by the client and fails to be synchronously stored to the server.
in the method of this embodiment, when the synchronization request is successful, the client acquires a failure data list that is stored locally and failed to be synchronously stored to the server, for example, the acquisition mode may be that all data records stored in a local database when the client synchronously stores data to the server are traversed, and a data record set whose tag is a synchronization failure tag is formed as the failure data list by identifying and selecting the data records whose tag is the synchronization failure tag; or acquiring a data record list with a label as a synchronization failure label when the client synchronously stores data to the server as the failure data list. Each record in the failure data list specifically includes: data update time, data content, and a unique ID for each piece of data.
Step 307, judging whether each data record of the synchronous data records exists in the failure data list one by one; if not, further judging whether the data record exists in a database to be synchronized of the client, if so, updating the data record, and if not, inserting the data record into the database to be synchronized.
Judging whether each data record of the synchronous data records exists in the failed data list or not through the unique ID of each piece of data, if the ID in the synchronous data record does not exist in the failed data list, comparing the data with the ID of the data which is marked as success in a local database of the client, if the ID is the same, updating the data record, if the ID is not the same, indicating that the original data in the client is older or the client is the client on other platforms used by the user, and storing the synchronous data into the local database of the client by the client, wherein the stored content comprises: and updating the data updating time, the data content and the ID of the data, and adding a success label to the piece of data.
and when the IDs are the same, updating the data in the local database, specifically deleting the data in the local database, and storing the data in the synchronous data record in the local database.
Step 309, if yes, determining which record of the data record corresponding to the failure data list is an updated record, and if the data record is an updated data record, updating the data record to the database to be synchronized; and if the record in the failure data list is a new record, discarding the data record and reserving the corresponding data record in the database to be synchronized.
judging whether each data record of the synchronous data records exists in the failed data list or not through the unique ID of each piece of data, and if the ID in the synchronous data records exists in the failed data list, indicating that the data exists in the failed data list; comparing the update time of the data, if the data record is updated compared with the corresponding record in the failure data list, which indicates that the original data in the local database is older, deleting the data in the local database, and storing the data record in the local database, wherein the stored content comprises: updating time, data content and ID of the data, and adding a success label for the data; and if the failed data list is more updated than the corresponding record in the data record, which indicates that the data in the database at the server side is older, the data in the client side is not processed, and the synchronization is subject to the content recorded by the client side.
In the foregoing embodiment, a method for a server side to synchronize data to a client side is provided, and correspondingly, an apparatus for a server side to synchronize data to a client side is also provided. Please refer to fig. 4, which is a schematic diagram of an embodiment of an apparatus for server-side synchronizing data to a client according to the present application. Since the apparatus embodiments are substantially similar to the method embodiments, they are described in a relatively simple manner, and reference may be made to some of the descriptions of the method embodiments for relevant points. The device embodiments described below are merely illustrative.
a request module 401, configured to send a request for synchronizing data to a server; a receiving module 403, configured to receive a synchronous data record stored by the server side, where the synchronous data record is issued by the server side according to the request; a failure data list module 405, configured to obtain a failure data list that is locally stored by the client and fails to be synchronously stored to the server; the determining module 407 is configured to determine whether each data record of the synchronous data records exists in the failed data list one by one.
optionally, the receiving module is specifically configured to receive synchronous data records, where each received synchronous data record includes: data update time, data content, and a unique ID for each piece of data.
Optionally, the failed data list module is specifically configured to store data with a failed tag, where each record in the failed data list includes: data update time, data content, and a unique ID for each piece of data.
Optionally, the failure data list module is configured to traverse all data records of a local database when the client synchronously stores data to the server; and identifying and selecting the data records with the labels as the synchronization failure labels to form a data record set with the labels as the synchronization failure labels as the failure data list.
Optionally, the failed data list module is configured to obtain a data record list, where a tag formed when the client synchronously stores data to the server is a synchronization failed tag, as the failed data list.
Optionally, the determining module specifically includes:
And the data record judging unit is used for judging whether the data record exists in a database to be synchronized of the client, if so, updating the data record, and if not, inserting the data record into the data to be synchronized.
A modification time determining unit, configured to determine which record of the data record corresponding to the failure data list is an updated record, and if the data record is an updated data record, update the data record to the to-be-synchronized database; and if the record in the failure data list is a new record, discarding the data record and reserving the corresponding data record in the database to be synchronized.
Optionally, the modification time determining unit is configured to determine which data record is a new record by determining a saving time or a version of the data record in the step of determining which record of the data record corresponding to the failed data list is an updated record.
the embodiment of the present application further provides a system for data synchronization from a server to a client for data submission, as shown in fig. 5, the system includes the data synchronization storage device 501 and the server-to-client data synchronization device 503 described in the foregoing embodiment. The data synchronization storage method and the server-side data synchronization method to the client can be executed on a computer or a mobile terminal, but are not limited to these two devices, and may be any device capable of implementing the data synchronization storage method and the server-side data synchronization method to the client.
In a typical configuration, a computing device includes one or more processors (CPUs), input/output interfaces, network interfaces, and memory.
The memory may include forms of volatile memory in a computer readable medium, Random Access Memory (RAM) and/or non-volatile memory, such as Read Only Memory (ROM) or flash memory (flash RAM). Memory is an example of a computer-readable medium.
1. computer-readable media, including both non-transitory and non-transitory, removable and non-removable media, may implement information storage by any method or technology. The information may be computer readable instructions, data structures, modules of a program, or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), other types of Random Access Memory (RAM), Read Only Memory (ROM), Electrically Erasable Programmable Read Only Memory (EEPROM), flash memory or other memory technology, compact disc read only memory (CD-ROM), Digital Versatile Discs (DVD) or other optical storage, magnetic cassettes, magnetic tape magnetic disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information that can be accessed by a computing device. As defined herein, computer readable media does not include non-transitory computer readable media (transient media), such as modulated data signals and carrier waves.
2. as will be appreciated by one skilled in the art, embodiments of the present application may be provided as a method, system, or computer program product. Accordingly, the present application may take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application may take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, and the like) having computer-usable program code embodied therein.
Although the present application has been described with reference to the preferred embodiments, it is not intended to limit the present application, and those skilled in the art can make variations and modifications without departing from the spirit and scope of the present application, therefore, the scope of the present application should be determined by the claims that follow.
Claims (14)
1. a method for synchronizing data from a server side to a client side is characterized by comprising the following steps:
Sending a request for synchronizing data to a server;
Receiving a synchronous data record which is sent by the server end aiming at the request and is stored by the server end;
Acquiring a failure data list which is locally stored by a client and fails to be synchronously stored to a server;
judging whether each data record of the synchronous data records exists in the failure data list one by one; if not, further judging whether the data record exists in a database to be synchronized of the client, if so, updating the data record, if not, inserting the data record into the database to be synchronized, specifically, comparing the ID of the data included in the data record in the synchronous data record with the ID of the data which is marked by the same ID in the database to be synchronized and successfully stored for the server in the database to be synchronized, if so, deleting the data marked by the same ID in the database to be synchronized, storing the data marked by the ID of the data included in the data record in the synchronous data record in the database to be synchronized, and if not, storing the data marked by the ID of the data included in the data record in the database to be synchronized;
If so, judging which record in the data record and the corresponding record in the failure data list is an updated record, and if the data record is the updated data record, updating the data record to the database to be synchronized; and if the record in the failure data list is a new record, discarding the data record and reserving the corresponding data record in the database to be synchronized.
2. The method for server-side to client-side synchronization of data according to claim 1, wherein each of the synchronized data records comprises: data update time, data content, and a unique ID for each piece of data.
3. the method according to claim 1, wherein each record in the failure data list comprises: data update time, data content, and a unique ID for each piece of data.
4. the method according to claim 1, wherein the receiving of the synchronization data record, which is sent by the server side for the request, stored by the server side comprises:
Receiving all synchronous data records stored by the server side issued by the server side aiming at the request; or
and receiving the synchronous data record updated after the previous request stored by the server terminal aiming at the request issued by the server terminal.
5. The method according to claim 3, wherein the obtaining the list of failed data that is locally stored by the client and that fails to be synchronously stored to the server comprises:
traversing all data records of a local database when the client synchronously stores data to the server;
and identifying and selecting the data records with the labels as the synchronization failure labels to form a data record set with the labels as the synchronization failure labels as a failure data list.
6. the method according to claim 3, wherein the obtaining the list of failed data that is locally stored by the client and that fails to be synchronously stored to the server comprises:
And acquiring a data record list with a label as a synchronization failure label when the client synchronously stores data to the server as the failure data list.
7. The method according to claim 1, wherein the step of determining which record of the data record corresponding to the failed data list is an updated record determines which data record is a new record by determining a retention time or version of the data record.
8. An apparatus for server-side synchronization of data to a client, comprising:
The request module is used for sending a request of synchronous data to the server;
The receiving module is used for receiving the synchronous data record which is sent by the server end aiming at the request and is stored by the server end;
The failure data list module is used for acquiring a failure data list which is locally stored by the client and fails to be synchronously stored to the server;
the judging module is used for judging whether each data record of the synchronous data records exists in the failure data list one by one;
The judging module specifically comprises:
A data record judging unit, configured to judge whether the data record exists in a database to be synchronized at a client, if the data record exists, update the data record, and if the data record does not exist, insert the data record into the database to be synchronized, specifically, compare an ID of data included in the data record in the synchronized data record with an ID of data that is stored successfully for a server in the database to be synchronized, if the data record has the same ID, delete data identified by the same ID in the database to be synchronized, store data identified by the ID of data included in the data record in the synchronized data record in the database to be synchronized, and if the data record does not have the same ID, store data identified by the ID of data included in the data record in the database to be synchronized;
a modification time determining unit, configured to determine which record of the data record corresponding to the failure data list is an updated record, and if the data record is an updated data record, update the data record to the to-be-synchronized database; and if the record in the failure data list is a new record, discarding the data record and reserving the corresponding data record in the database to be synchronized.
9. The apparatus according to claim 8, wherein the receiving module is specifically configured to receive the synchronized data records, and each received synchronized data record includes: data update time, data content, and a unique ID for each piece of data.
10. The apparatus according to claim 8, wherein the failed data list module is specifically configured to store data labeled as failed, and each record in the failed data list includes: data update time, data content, and a unique ID for each piece of data.
11. The apparatus according to claim 10, wherein the failed data list module is configured to traverse all data records of a local database stored when the client synchronously stores data to the server; and identifying and selecting the data records with the labels as the synchronization failure labels to form a data record set with the labels as the synchronization failure labels as the failure data list.
12. the apparatus according to claim 10, wherein the failed data list module is configured to obtain a data record list, as the failed data list, where a tag of the data record list is a synchronization failure tag, where the data record list is formed when the client synchronously saves data to the server.
13. The apparatus according to claim 8, wherein the modification time determining unit is configured to determine which data record is a new record by determining a retention time or version of the data record in the step of determining which record corresponding to the data record in the failed data list is an updated record.
14. A system for data synchronous storage and data synchronization to a client, comprising a device for server-side data synchronization to the client according to any one of claims 8 to 13.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410389659.0A CN105450682B (en) | 2014-08-08 | 2014-08-08 | Method, device and system for synchronously storing data and synchronizing data to client |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201410389659.0A CN105450682B (en) | 2014-08-08 | 2014-08-08 | Method, device and system for synchronously storing data and synchronizing data to client |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN105450682A CN105450682A (en) | 2016-03-30 |
| CN105450682B true CN105450682B (en) | 2019-12-06 |
Family
ID=55560456
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201410389659.0A Active CN105450682B (en) | 2014-08-08 | 2014-08-08 | Method, device and system for synchronously storing data and synchronizing data to client |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN105450682B (en) |
Families Citing this family (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN107277085A (en) * | 2016-04-06 | 2017-10-20 | 阿里巴巴集团控股有限公司 | Business compensation method and device |
| CN107341163B (en) * | 2016-05-03 | 2020-08-14 | 阿里巴巴集团控股有限公司 | Data synchronization method and device |
| CN106254456B (en) * | 2016-08-03 | 2020-03-10 | 深圳市商汤科技有限公司 | Data synchronization method and data synchronization system |
| CN109561126B (en) * | 2017-09-27 | 2022-01-28 | 北京国双科技有限公司 | Data synchronization method and device, storage medium and processor |
| CN108255434B (en) * | 2018-01-15 | 2021-11-02 | 腾讯科技（深圳）有限公司 | Label management method, management device and computer readable storage medium |
| CN110225119B (en) * | 2019-06-13 | 2022-09-16 | 平安科技（深圳）有限公司 | Data synchronization method and related equipment |
| CN111198894B (en) * | 2020-01-03 | 2023-09-22 | 中国铁道科学研究院集团有限公司通信信号研究所 | Method for realizing operation line data fusion and consistency |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101009516A (en) * | 2006-01-26 | 2007-08-01 | 华为技术有限公司 | A method and system for data synchronization |
| CN101018113A (en) * | 2007-01-24 | 2007-08-15 | 华为技术有限公司 | The method for synchronizing data and obtaining the data synchronization result and its system and HLR |
| CN101751473A (en) * | 2009-12-31 | 2010-06-23 | 中兴通讯股份有限公司 | The searching of a kind of amendment record item, renewal and method for synchronous and data sync equipment |
| CN103973727A (en) * | 2013-01-28 | 2014-08-06 | 深圳市腾讯计算机系统有限公司 | Data synchronizing method and device |
-
2014
- 2014-08-08 CN CN201410389659.0A patent/CN105450682B/en active Active
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN101009516A (en) * | 2006-01-26 | 2007-08-01 | 华为技术有限公司 | A method and system for data synchronization |
| CN101018113A (en) * | 2007-01-24 | 2007-08-15 | 华为技术有限公司 | The method for synchronizing data and obtaining the data synchronization result and its system and HLR |
| CN101751473A (en) * | 2009-12-31 | 2010-06-23 | 中兴通讯股份有限公司 | The searching of a kind of amendment record item, renewal and method for synchronous and data sync equipment |
| CN103973727A (en) * | 2013-01-28 | 2014-08-06 | 深圳市腾讯计算机系统有限公司 | Data synchronizing method and device |
Also Published As
| Publication number | Publication date |
|---|---|
| CN105450682A (en) | 2016-03-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN105450682B (en) | Method, device and system for synchronously storing data and synchronizing data to client | |
| CN107483627B (en) | File distribution method, file download method, distribution server, client and system | |
| US11012505B2 (en) | Application information sharing method and apparatus | |
| CN1988535B (en) | Synchronous method, system for file storage and customer terminal | |
| US20170249328A1 (en) | A Method, Cloud Synchronization Function Means and File System for Handling Files and Directories in a Cloud Storage Service | |
| CN106933547B (en) | Global information acquisition and processing method, device and updating system | |
| US20170031948A1 (en) | File synchronization method, server, and terminal | |
| CN106503158B (en) | Data synchronization method and device | |
| CN106933550B (en) | Global information obtaining, processing and updating method, device and system | |
| JP2017037666A (en) | Sending category information | |
| US20200264777A1 (en) | Method and apparatus for upgrading a distributed storage system | |
| CN107153644B (en) | Data synchronization method and device | |
| CN107181686B (en) | Method, device and system for synchronizing routing table | |
| US20180121531A1 (en) | Data Updating Method, Device, and Related System | |
| CN107291768B (en) | Index establishing method and device | |
| CN104104739A (en) | Data synchronization method for metadata service cluster of cloud storage system | |
| CN107592199B (en) | Data synchronization method and system | |
| US20100332506A1 (en) | Marking sought after content items on network media devices | |
| CN107357557B (en) | Information updating method and device | |
| CN110555040A (en) | Data caching method and device and server | |
| CN110958287A (en) | Operation object data synchronization method, device and system | |
| CN112865927B (en) | Message delivery verification method, device, computer equipment and storage medium | |
| CN116708563A (en) | File data processing method and device, server and readable storage medium | |
| CN107707590A (en) | System, the method and device of data transfer | |
| CN111131498B (en) | URL information updating method, cache server, equipment and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| C06 | Publication | ||
| PB01 | Publication | ||
| C10 | Entry into substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant | ||
| TR01 | Transfer of patent right | ||
| TR01 | Transfer of patent right |
Effective date of registration: 20211123 Address after: Room 507, floor 5, building 3, No. 969, Wenyi West Road, Wuchang Street, Yuhang District, Hangzhou City, Zhejiang Province Patentee after: ZHEJIANG TMALL TECHNOLOGY Co.,Ltd. Address before: Box 847, four, Grand Cayman capital, Cayman Islands, UK Patentee before: ALIBABA GROUP HOLDING Ltd. |