A client-side data synchronization Solution

Scenario

Client A synchronizes local data to the server from time to time, and then another client B (APP) synchronizes data from the server to summarize and display

Client a Data Structure

The original data (from client a), each with create_time and modify_time, is used to indicate the creation time and modification time of this record. At the same time, the latest_backup_time field is included in the system to indicate the time of the last backup. Each time the client backs up, the three fields are used as conditions to find the data to be backed up and upload it to the server.

Server Data Structure

Due to historical issues, after the server receives the backup data, it does not perform any other processing, but directly writes the data to the database.

Client B synchronization Logic

Client B has the latest_sync_time field, which indicates the last synchronization time from the server. This field is determined and returned by the server after each synchronization. The client writes down this timestamp. This timestamp is added to the request for synchronization. Then, the server uses the create_time, modify_time, latest_sync_time fields as the condition to find the data to be delivered and return to client B.

The logic for querying which data needs to be delivered is:

The key to this solution is how to determine latest_sync_time. Because both create_time and modify_time are the local time of Client A, and the server does not have a field to indicate the time when the server enters the database, when the server returns latest_sync_time to client B, you cannot use the time when the server receives the synchronous request. Instead, use the last create_time or modify_time in the queried data.

Other solutions

The above scheme is difficult to determine latest_sync_time. The root cause is that when the server enters the database, it does not save the time for receiving the database. If sync_time is available on the server, it is easy to compare it. You only need to find the data between latest_sync_time and now. The data is the new data from the last synchronization to the current time, And then you only need to put the current time in the response and return it together to the client. The client refresh latest_sync_time.

In addition, the above scheme also places the logic for judging insert and update on the server. In fact, the server can also directly send the satisfied data back to client B, and then determine whether the ID exists on the client, you can determine whether the data is added or need to be updated

This solution is simpler, and because sync_time is controlled by the server, it can also avoid logical errors caused by Client A's local system time modification. It should be a better solution. However, because there is no historical data record sync_time in the server, it is difficult to migrate, and this solution also needs to change the existing backup logic of the server, so the first solution is finally decided. The second solution is recommended for newly developed systems.