最终同步策略

名词解释

anchor：同步锚点，用时间戳来表示，用来表示某项记录最后同步时间
modified：修改时间，用时间戳来表示，用来表示某项纪录内容实际最后修改时间

客户端设计

每条表项包含两个用来同步用的字段：
status：用来标识记录的状态
modified：记录每条记录最后修改时间

另外，保存一个anchor，记录服务端同步过来的时间戳；若尚未进行任何同步，anchor为-1

服务端设计

每条表项包含两个用来同步用的字段：
modified：记录每条记录最后修改时间
anchor：记录每条记录与客户端时间最后同步时间

双向同步过程

初始状态下，我们假设客户端和服务端的表各有两条数据

客户端：

anchor = 4

服务端：

此时，客户端与服务端的数据是完全同步好了的

Client在时间5增加1条记录

Client在时间6修改2条记录

由于还未同步，anchor仍为4

Server由于在时间8与另一客户端同步，从而修改2条记录

Client发送本地更新

客户端发送本地更新，即status为0、1或-1的表项，执行sql语句：
SELECT * FROM table WHERE status < 9
找出客户端需要同步到服务端的记录。下表中的数据是发送的同步消息

anchor = 4

Server在时间9处理同步消息

首先处理第一条数据

服务端收到请求后，对比客户端的modified和服务端的modified，保留modified较晚一项；在这里，保留服务器的数据，不进行修改。

然后处理第二条数据

服务端收到请求后，对比客户端的modified和服务端的modified，保留modified较晚一项；在这里，保留客户端修改后的数据，并将anchor修改为此次同步时间。

最后处理第三条数据

如果得知status = 0，直接插入即可，并将anchor修改为此次同步时间。

服务端经过这两次操作后，数据表如下

Client根据响应更新本地记录

服务端处理完数据后，还要响应客户端的请求，将所有anchor大于客户端anchor = 4的表项发送给客户端，如下

并发送同步时间anchor = 9

收到响应后，客户端就开始执行UPDATE了，对每一项进行修改、将status改为9，并将anchor改为最后修改时间7。

客户端现在的数据表如下：

并将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（相当于时光机，以后可以进行数据的恢复）表中

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

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