因为一些原因,对之前的同步策略进行了修改,原有策略:同步策略选择。现在的同步策略如下:
名词解释
anchor:同步锚点,用时间戳来表示,用来表示某项记录最后同步时间
modified:修改时间,用时间戳来表示,用来表示某项纪录内容实际最后修改时间
客户端设计
每条表项包含两个用来同步用的字段:
status:用来标识记录的状态
modified:记录每条记录最后修改时间
status | 含义 |
---|---|
0 | 本地新增 |
-1 | 标记删除 |
1 | 本地更新 |
9 | 已同步 |
另外,保存一个anchor,记录服务端同步过来的时间戳;若尚未进行任何同步,anchor为-1
服务端设计
每条表项包含两个用来同步用的字段:
modified:记录每条记录最后修改时间
anchor:记录每条记录与客户端时间最后同步时间
双向同步过程
初始状态下,我们假设客户端和服务端的表各有两条数据
客户端:
id | name | phone | status | modified |
---|---|---|---|---|
1 | Ken | 18612345678 | 9 | 2 |
2 | Jim | 13888888888 | 9 | 3 |
anchor = 4
服务端:
id | name | phone | modified | anchor |
---|---|---|---|---|
1 | Ken | 18612345678 | 2 | 4 |
2 | Jim | 13888888888 | 3 | 4 |
此时,客户端与服务端的数据是完全同步好了的
Client在时间5增加1条记录
id | name | phone | status | modified |
---|---|---|---|---|
1 | Ken | 18612345678 | 9 | 2 |
2 | Jim | 13888888888 | 9 | 3 |
3 | Tim | 12345678 | 0 | 5 |
Client在时间6修改2条记录
id | name | phone | status | modified |
---|---|---|---|---|
1 | Ken | 2333333 | 1 | 6 |
2 | Jim | 010-12345678 | 1 | 6 |
3 | Tim | 12345678 | 0 | 5 |
由于还未同步,anchor仍为4
Server由于在时间8与另一客户端同步,从而修改2条记录
id | name | phone | modified | anchor |
---|---|---|---|---|
1 | Ken | 6666666666 | 7 | 8 |
2 | Jim | 77777777777 | 4 | 8 |
Client发送本地更新
客户端发送本地更新,即status为0、1或-1的表项,执行sql语句:SELECT * FROM table WHERE status < 9
找出客户端需要同步到服务端的记录。下表中的数据是发送的同步消息
id | name | phone | status | modified |
---|---|---|---|---|
1 | Ken | 2333333 | 1 | 6 |
2 | Jim | 010-12345678 | 1 | 6 |
3 | Tim | 12345678 | 0 | 5 |
anchor = 4
Server在时间9处理同步消息
首先处理第一条数据
id | name | phone | status | modified |
---|---|---|---|---|
1 | Ken | 2333333 | 1 | 6 |
服务端收到请求后,对比客户端的modified和服务端的modified,保留modified较晚一项;在这里,保留服务器的数据,不进行修改。
然后处理第二条数据
id | name | phone | status |
---|---|---|---|
2 | Jim | 010-12345678 | 1 |
服务端收到请求后,对比客户端的modified和服务端的modified,保留modified较晚一项;在这里,保留客户端修改后的数据,并将anchor修改为此次同步时间。
最后处理第三条数据
id | name | phone | status | modified |
---|---|---|---|---|
3 | Tim | 12345678 | 0 | 5 |
如果得知status = 0,直接插入即可,并将anchor修改为此次同步时间。
服务端经过这两次操作后,数据表如下
id | name | phone | modified | anchor |
---|---|---|---|---|
1 | Ken | 6666666666 | 7 | 8 |
2 | Jim | 010-12345678 | 6 | 10 |
3 | Tim | 12345678 | 5 | 10 |
Client根据响应更新本地记录
服务端处理完数据后,还要响应客户端的请求,将所有anchor大于客户端anchor = 4的表项发送给客户端,如下
id | name | phone | modified | anchor |
---|---|---|---|---|
1 | Ken | 6666666666 | 7 | 8 |
2 | Jim | 010-12345678 | 6 | 10 |
3 | Tim | 12345678 | 5 | 10 |
并发送同步时间anchor = 9
收到响应后,客户端就开始执行UPDATE了,对每一项进行修改、将status改为9,并将anchor改为最后修改时间7。
客户端现在的数据表如下:
id | name | phone | status | modified |
---|---|---|---|---|
1 | Ken | 6666666666 | 9 | 7 |
2 | Jim | 010-12345678 | 9 | 6 |
3 | Tim | 12345678 | 9 | 5 |
并将anchor修改为anchor = 9。
客户端删除记录
逻辑删除记录:
|id |name |phone |status |modified |
|-|-|-|-|-|
|1 |Ken |6666666666 |-1 |7 |
|2 |Jim | 010-12345678 |9 |6 |
|3 |Tim |12345678 |9 |5 |
客户端发送消息到服务端
根据status < 9,将逻辑删除的记录发送至服务端,服务端收到消息后,将该记录移至deleted_table(相当于时光机,以后可以进行数据的恢复)表中
id | name | phone | modified | anchor |
---|---|---|---|---|
1 | Ken | 6666666666 | 7 | 12 |
服务端响应客户端的请求????
客户端收到响应
客户端直接进行物理删除
服务端删除记录
如果客户端从服务端获取的增量信息中包含删除记录的消息,则客户端直接进行物理删除