多終端數據同步機制設計（一）

Intro

因為項目需要，需要設計一個多終端數據同步的機制， 需要滿足以下條件： 1. 多個終端數據操作及同步 2. 每次同步的時候只拉取需要同步的數據，且數據不能存在丟失 3. 儘可能少的調用伺服器端介面

同步流程

整體同步流程

我想仿照Git數據同步的方式來進行數據同步，於是放著Git同步的流程來進行設計，首先每次提交會有一個版本號，另外每次提交之前應儘可能先從伺服器端拉取數據， 保證客戶端的數據是最新的情況下再進行提交本地的修改。按照Git的方式來進行數據同步時，可能會存在數據衝突，如果存在數據衝突需要客戶端解決衝突。
也就是總體來說，操作有兩個大的操作，一個是從伺服器端拉取數據，一個是向伺服器端推送數據更新。
在資料庫層面有一個數據版本表來存儲每一次提交，每一次更新會在更新結束之後將在版本表中加上一條記錄，更新一個版本，並將版本號返回給客戶端， 每次從伺服器端拉取更新的時候不僅會將更新的數據返回給客戶端，也會將最新的版本號返回到客戶端，用以客戶端下一次同步數據。

最後伺服器端提供了三個介面

1. GetCurrentVersion() 查詢用戶數據的最新版本號，
2. PullData() 從伺服器端拉取更新數據,
3. PushData() 向伺服器端推送本地數據更新

思慮再三之後最終產出了下麵的流程圖：

從伺服器端獲取用戶數據的最新版本號

客戶端調用 GetCurrentVersion() 介面，需要傳遞一個標識用戶賬號的參數，這樣才能查詢到某一個用戶的數據信息。 根據用戶賬號信息查詢數據的最新版本號,返回到客戶端，客戶端根據伺服器端的版本號和本地進行比較，如果一致則說明是最新版本之後判斷本地是否有修改有修改則直接提交即可，如果不一致一定不是最新版本則進行伺服器端拉取數據更新數據和版本號後再提交本地修改（如果有修改）。

從伺服器端拉取數據流程

從伺服器端拉取更新有些麻煩，如果在一臺設備上有幾個版本沒有更新的話，需要考慮將幾個版本的數據合併，具體問題以及流程在後文中會提及。

從伺服器端拉取數據基本流程如下：

客戶端拉取數據後更新本地數據流程

客戶端調用 PullData 介面 從伺服器拉取本地需要修改的數據同時每一條數據都對應一個操作狀態來更新本地數據，從伺服器端返回數據的同時返回數據對應的操作狀態，客戶端根據返回的操作狀態對數據進行相應的處理，返回數據時也需要將最新數據的版本號也返回用以客戶端更新本地數據版本。

客戶端向伺服器推送更新

客戶端調用 PushData 介面向伺服器端推送更新，將需要提交的修改提交到伺服器端，伺服器端返回客戶端每一個需要進行修改的數據的操作狀態，是否修改成功。

伺服器端更新數據

客戶端向伺服器端推送更新之後，伺服器端需要進行處理。 首先需要判斷客戶端的版本是否是最新版本，如果不是最新則提示客戶端先更新本地數據到最新版本再更新數據，如果是最新的再向下處理。 之後需要將客戶端的請求數據（一個json字元串）反序列化轉換為請求實體列表，如果轉換失敗則說明客戶端的請求數據是有問題的則不進行處理，如果轉換成功再向下處理。 然後遍歷請求實體列表，根據請求數據的操作類型進行不同數據操作，每條數據操作完之後設置對應的操作狀態。 最後所有請求數據更新完成之後，新增一個版本，並將版本設置到響應。

被我踩到的那些坑

Pull 數據版本合併

從伺服器端拉取數據的時候需要考慮到多個版本的提交數據合併問題，我們的數據比較簡單是直接更新原來的數據，因此不會涉及到文本分塊再合併這一類太複雜的操作，但是也需要將幾個版本的修改進行合併，例如新增數據，兩個版本各新增兩條數據則應返回四條數據才對,一個版本新增另一個版本刪除掉的數據就不應該返回給客戶端。 這就需要考慮如何高效並且準確的返回客戶端需要更新的數據，這裡需要提及一下我的版本表的涉及，版本表裡除了版本號之外有更新人，更新時間和每次調用 PushData 介面時的請求參數和返回給客戶端的操作狀態集合的響應的轉換為json字元串存儲在資料庫中，每次更新完數據之後在版本表中插入一條新的版本數據。

解決方案一：

第一種方式，首先我考慮從版本表裡取出每次修改成功的數據，再將多個版本的修改進行合併到一個List，再去重，如果遇到兩條相同的數據需要進行去重操作，需要根據每條數據的操作類型來判斷該如何具體的去重，大致分四種情況：

1. 先新增後修改 --> Add
2. 先新增最後刪除 --> null 不需要返回給客戶端
3. 先修改之後還是修改 --> Update
4. 先修改最後刪除 --> Delete

這裡不僅操作類型需要修改，數據內容也是需要進行合併的，需要最新的數據返回。

解決方案二：

第二種方式，按照版本的更新時間和數據的創建時間和更新時間的關係來進行篩選數據和判斷數據的操作類型，如果數據刪除的話只是修改數據的狀態並不真正的刪除數據。

首先將更新時間大於本地版本對應的版本更新時間的數據查詢出來，這些數據是在本地版本更新之後的所有數據， 之後篩選數據，按操作類型可分四種情況：

1. 創建時間 >= 版本更新時間 && IsDeleted = 0 --> Add
2. 創建時間 >= 版本更新時間 && IsDeleted = 1 --> null 先創建後刪除，不需要返回到客戶端
3. 創建時間 < 版本更新時間 && IsDeleted = 0 --> Update
4. 創建時間 < 版本更新時間 && IsDeleted = 1 --> Delete

篩選並判斷操作類型之後將數據返回給客戶端

綜合比較，確定版本合併方案

經過分析，第一種方案數據操作起來非常麻煩，相對的第二種解決方案數據操作會很少，可以在資料庫層面進行判斷篩選，至於數據準確度方面兩者差不多， 考慮併發問題的話可以在 調用 Push 介面時根據用戶賬號進行加鎖，綜合一下，最終採用第二種解決方案。

Push介面

調用Push介面的時候原本沒有判斷本地的版本號，如果出現客戶端沒有按照設定的順序來調用介面可能就會出現不可想象的數據災難，而且作為介面本身是沒辦法控制客戶端的調用順序的。 所以，修改後的 Push 介面需要客戶端傳遞一個客戶端版本號的參數，如果不是最新版本的數據拒絕提交，並提示客戶端先更新數據到最新版本後再提交數據。

時間不統一

這個問題算是自己給自己挖的坑，在更新數據的時候時間取的都是網站伺服器端時間，但是在新增版本的時候新增的參數里的更新時間用的卻是資料庫伺服器的時間，由於資料庫伺服器和網站伺服器不在一臺伺服器上， 資料庫伺服器的時間比網站伺服器上的時間慢了幾秒，這導致我在從伺服器端拉取數據時出現有的數據沒有拉取出來的情況，後來debug從資料庫中查詢數據確實更新了而且版本也正確插入了，最後一一記錄每一條數據的更新時間和每個版本的更新時間， 這才發現時間有點不太對，再檢查下自己的sql語句，發現新增版本的sql的更新時間用的是GETDATE(),而更新數據的sql都是參數，用的是網站伺服器的時間。。發現問題的我頓時想抽死自己...（

In the end

最後，這個設計一定還存在著不足，希望大神看到能給出自己的看法和意見，有不正確的地方還希望能夠告知。