zoukankan      html  css  js  c++  java
  • 最终同步策略

    因为一些原因,对之前的同步策略进行了修改,原有策略:[同步策略选择](http://www.cnblogs.com/huangzp1104/p/9394358.html)。现在的同步策略如下:

    名词解释

    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 |modified |
    |-|-|-|-|
    |2 |Jim | 010-12345678 |1 |6 |

    服务端收到请求后,对比客户端的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

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

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

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

  • 相关阅读:
    ECharts之柱状图 饼状图 折线图
    Vue自定义指令(directive)
    HDU 1231 最大连续子序列
    POJ 2533 Longest Ordered Subsequence
    HDU 1163 Eddy's digital Roots
    HDU 2317 Nasty Hacks
    HDU 2571 命运
    HDU 4224 Enumeration?
    HDU 1257 最少拦截系统
    HDU 2740 Root of the Problem
  • 原文地址:https://www.cnblogs.com/USTC-CC/p/9400328.html
Copyright © 2011-2022 走看看