最终同步策略

Posted 2020-12-26 ustc-cc

因为一些原因，对之前的同步策略进行了修改，原有策略：同步策略选择。现在的同步策略如下：

名词解释

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

服务端响应客户端的请求？？？？

客户端收到响应
客户端直接进行物理删除

服务端删除记录
如果客户端从服务端获取的增量信息中包含删除记录的消息，则客户端直接进行物理删除