多终端数据同步机制设计（一）

多终端数据同步机制设计（一）

Intro

由于项目须要，须要设计一个多终端数据同步的机制， 须要知足如下条件： 1. 多个终端数据操做及同步 2. 每次同步的时候只拉取须要同步的数据，且数据不能存在丢失 3. 尽量少的调用服务器端接口

同步流程

总体同步流程

我想仿照Git数据同步的方式来进行数据同步，因而放着Git同步的流程来进行设计，首先每次提交会有一个版本号，另外每次提交以前应尽量先从服务器端拉取数据， 保证客户端的数据是最新的状况下再进行提交本地的修改。按照Git的方式来进行数据同步时，可能会存在数据冲突，若是存在数据冲突须要客户端解决冲突。
也就是整体来讲，操做有两个大的操做，一个是从服务器端拉取数据，一个是向服务器端推送数据更新。
在数据库层面有一个数据版本表来存储每一次提交，每一次更新会在更新结束以后将在版本表中加上一条记录，更新一个版本，并将版本号返回给客户端， 每次从服务器端拉取更新的时候不只会将更新的数据返回给客户端，也会将最新的版本号返回到客户端，用以客户端下一次同步数据。

最后服务器端提供了三个接口

1. GetCurrentVersion() 查询用户数据的最新版本号，
2. PullData() 从服务器端拉取更新数据,
3. PushData() 向服务器端推送本地数据更新

思虑再三以后最终产出了下面的流程图：

 

从服务器端获取用户数据的最新版本号

客户端调用 GetCurrentVersion() 接口，须要传递一个标识用户帐号的参数，这样才能查询到某一个用户的数据信息。 根据用户帐号信息查询数据的最新版本号,返回到客户端，客户端根据服务器端的版本号和本地进行比较，若是一致则说明是最新版本以后判断本地是否有修改有修改则直接提交便可，若是不一致必定不是最新版本则进行服务器端拉取数据更新数据和版本号后再提交本地修改（若是有修改）。

从服务器端拉取数据流程

从服务器端拉取更新有些麻烦，若是在一台设备上有几个版本没有更新的话，须要考虑将几个版本的数据合并，具体问题以及流程在后文中会说起。

从服务器端拉取数据基本流程以下：

 

 

客户端拉取数据后更新本地数据流程

客户端调用 PullData 接口 从服务器拉取本地须要修改的数据同时每一条数据都对应一个操做状态来更新本地数据，从服务器端返回数据的同时返回数据对应的操做状态，客户端根据返回的操做状态对数据进行相应的处理，返回数据时也须要将最新数据的版本号也返回用以客户端更新本地数据版本。

 

客户端向服务器推送更新

客户端调用 PushData 接口向服务器端推送更新，将须要提交的修改提交到服务器端，服务器端返回客户端每个须要进行修改的数据的操做状态，是否修改为功。

服务器端更新数据

客户端向服务器端推送更新以后，服务器端须要进行处理。 首先须要判断客户端的版本是不是最新版本，若是不是最新则提示客户端先更新本地数据到最新版本再更新数据，若是是最新的再向下处理。 以后须要将客户端的请求数据（一个json字符串）反序列化转换为请求实体列表，若是转换失败则说明客户端的请求数据是有问题的则不进行处理，若是转换成功再向下处理。 而后遍历请求实体列表，根据请求数据的操做类型进行不一样数据操做，每条数据操做完以后设置对应的操做状态。 最后全部请求数据更新完成以后，新增一个版本，并将版本设置到响应。

 

被我踩到的那些坑

Pull 数据版本合并

从服务器端拉取数据的时候须要考虑到多个版本的提交数据合并问题，咱们的数据比较简单是直接更新原来的数据，所以不会涉及到文本分块再合并这一类太复杂的操做，可是也须要将几个版本的修改进行合并，例如新增数据，两个版本各新增两条数据则应返回四条数据才对,一个版本新增另外一个版本删除掉的数据就不该该返回给客户端。 这就须要考虑如何高效而且准确的返回客户端须要更新的数据，这里须要说起一下个人版本表的涉及，版本表里除了版本号以外有更新人，更新时间和每次调用 PushData 接口时的请求参数和返回给客户端的操做状态集合的响应的转换为json字符串存储在数据库中，每次更新完数据以后在版本表中插入一条新的版本数据。

解决方案一：

第一种方式，首先我考虑从版本表里取出每次修改为功的数据，再将多个版本的修改进行合并到一个List，再去重，若是遇到两条相同的数据须要进行去重操做，须要根据每条数据的操做类型来判断该如何具体的去重，大体分四种状况：

1. 先新增后修改 --> Add
2. 先新增最后删除 --> null 不须要返回给客户端
3. 先修改以后仍是修改 --> Update
4. 先修改最后删除 --> Delete

这里不只操做类型须要修改，数据内容也是须要进行合并的，须要最新的数据返回。

解决方案二：

第二种方式，按照版本的更新时间和数据的建立时间和更新时间的关系来进行筛选数据和判断数据的操做类型，若是数据删除的话只是修改数据的状态并不真正的删除数据。

首先将更新时间大于本地版本对应的版本更新时间的数据查询出来，这些数据是在本地版本更新以后的全部数据， 以后筛选数据，按操做类型可分四种状况：

1. 建立时间 >= 版本更新时间 && IsDeleted = 0 --> Add
2. 建立时间 >= 版本更新时间 && IsDeleted = 1 --> null 先建立后删除，不须要返回到客户端
3. 建立时间 < 版本更新时间 && IsDeleted = 0 --> Update
4. 建立时间 < 版本更新时间 && IsDeleted = 1 --> Delete

筛选并判断操做类型以后将数据返回给客户端

综合比较，肯定版本合并方案

通过分析，第一种方案数据操做起来很是麻烦，相对的第二种解决方案数据操做会不多，能够在数据库层面进行判断筛选，至于数据准确度方面二者差很少， 考虑并发问题的话能够在 调用 Push 接口时根据用户帐号进行加锁，综合一下，最终采用第二种解决方案。

Push接口

调用Push接口的时候本来没有判断本地的版本号，若是出现客户端没有按照设定的顺序来调用接口可能就会出现不可想象的数据灾难，并且做为接口自己是没办法控制客户端的调用顺序的。 因此，修改后的 Push 接口须要客户端传递一个客户端版本号的参数，若是不是最新版本的数据拒绝提交，并提示客户端先更新数据到最新版本后再提交数据。

时间不统一

这个问题算是本身给本身挖的坑，在更新数据的时候时间取的都是网站服务器端时间，可是在新增版本的时候新增的参数里的更新时间用的倒是数据库服务器的时间，因为数据库服务器和网站服务器不在一台服务器上， 数据库服务器的时间比网站服务器上的时间慢了几秒，这致使我在从服务器端拉取数据时出现有的数据没有拉取出来的状况，后来debug从数据库中查询数据确实更新了并且版本也正确插入了，最后一一记录每一条数据的更新时间和每一个版本的更新时间， 这才发现时间有点不太对，再检查下本身的sql语句，发现新增版本的sql的更新时间用的是GETDATE(),而更新数据的sql都是参数，用的是网站服务器的时间。。发现问题的我顿时想抽死本身...（

In the end

最后，这个设计必定还存在着不足，给本身挖个坑，过一段时间再来填，【数据校验】+【数据分割】，下一次解决这两个问题，

但愿大神看到能给出本身的见解和意见，有不正确的地方还但愿可以告知。