最終同步策略

由於一些緣由，對以前的同步策略進行了修改，原有策略：同步策略選擇。如今的同步策略以下：

名詞解釋

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

服務端響應客戶端的請求？？？？

客戶端收到響應
客戶端直接進行物理刪除

服務端刪除記錄 若是客戶端從服務端獲取的增量信息中包含刪除記錄的消息，則客戶端直接進行物理刪除