一種用戶端同步server資料的方案

標籤：備份   同步   方案   

情境

用戶端A不定時地把本機資料同步到server上，然後另一個用戶端B（app）從server把資料同步下來，匯總展示

用戶端A資料結構

原始的資料（來自用戶端A），每條都有create_time和modify_time，用於表示這條記錄的建立時間和修改時間。同時系統裡還有latest_backup_time欄位，用來表示上次備份的時間。用戶端每次備份，都會以這3個欄位作為條件，找出需要備份的資料，上傳到server

服務端資料結構

由於曆史遺留問題，服務端收到備份資料之後，沒有做其他的處理，而是直接寫入資料庫

用戶端B同步邏輯

用戶端B有latest_sync_time欄位，用於表示最後一次從server同步的時間。這個欄位是每次同步之後，服務端確定並返回的，用戶端把這個時間戳記下來。請求同步時，再帶上這個時間戳記。然後服務端就以create_time，modify_time，latest_sync_time這3個欄位作為條件，找出需要下發的資料，返回用戶端B

查詢哪些資料需要下發的邏輯是：

這個方案的關鍵是，如何確定latest_sync_time。由於create_time和modify_time都是用戶端A的本地時間，服務端也沒有欄位表示服務端入庫的時間，所以服務端返回latest_sync_time到用戶端B的時候，不能用伺服器接收到同步請求的時間，而要用本次查詢到的資料中，最後的create_time或modify_time

其他方案

上面這個方案主要在確定latest_sync_time的時候比較麻煩。根源在於服務端入庫的時候，沒有把入庫的服務端時間儲存下來。如果在服務端有sync_time，那麼比較起來就很容易，只要找到sync_time在latest_sync_time和now之間的資料就可以了。這些資料就是從上次同步到當前時刻的新資料，然後只要把當前的時間，放在響應裡一起返回用戶端，用戶端重新整理latest_sync_time就行了

另外，上面這個方案把判斷insert和update的邏輯也放在了服務端。其實服務端也可以把滿足的資料直接發回用戶端B，然後在用戶端判斷id是否存在，就可以確定該資料是新增的，還是需要update的

這個方案感覺會更簡單，而且由於sync_time是由服務端控制的，也可以避免由於用戶端A修改本地系統時間引起的邏輯錯誤，應該是一個更優的方案。但是由於現在server裡已經存在沒有記錄sync_time的曆史資料，遷移起來比較麻煩，而且這種方案也需要改動server現有的備份邏輯，所以最後還是決定採用第一種方案。新開發的系統，建議採用第二種方案