多終端數(shù)據(jù)同步機制設(shè)計（一）
Intro
因為項目需要，需要設(shè)計一個多終端數(shù)據(jù)同步的機制，
需要滿足以下條件：
- 多個終端數(shù)據(jù)操作及同步
- 每次同步的時候只拉取需要同步的數(shù)據(jù)，且數(shù)據(jù)不能存在丟失
- 盡可能少的調(diào)用服務(wù)器端接口
同步流程
整體同步流程
我想仿照Git數(shù)據(jù)同步的方式來進行數(shù)據(jù)同步，于是放著Git同步的流程來進行設(shè)計，首先每次提交會有一個版本號，另外每次提交之前應(yīng)盡可能先從服務(wù)器端拉取數(shù)據(jù)，
保證客戶端的數(shù)據(jù)是最新的情況下再進行提交本地的修改。按照Git的方式來進行數(shù)據(jù)同步時，可能會存在數(shù)據(jù)沖突，如果存在數(shù)據(jù)沖突需要客戶端解決沖突。
也就是總體來說，操作有兩個大的操作，一個是從服務(wù)器端拉取數(shù)據(jù)，一個是向服務(wù)器端推送數(shù)據(jù)更新。
在數(shù)據(jù)庫層面有一個數(shù)據(jù)版本表來存儲每一次提交，每一次更新會在更新結(jié)束之后將在版本表中加上一條記錄，更新一個版本，并將版本號返回給客戶端，
每次從服務(wù)器端拉取更新的時候不僅會將更新的數(shù)據(jù)返回給客戶端，也會將最新的版本號返回到客戶端，用以客戶端下一次同步數(shù)據(jù)。
最后服務(wù)器端提供了三個接口
-
GetCurrentVersion()查詢用戶數(shù)據(jù)的最新版本號， -
PullData()從服務(wù)器端拉取更新數(shù)據(jù), -
PushData()向服務(wù)器端推送本地數(shù)據(jù)更新
思慮再三之后最終產(chǎn)出了下面的流程圖：
從服務(wù)器端獲取用戶數(shù)據(jù)的最新版本號
客戶端調(diào)用 GetCurrentVersion() 接口，需要傳遞一個標(biāo)識用戶賬號的參數(shù)，這樣才能查詢到某一個用戶的數(shù)據(jù)信息。
根據(jù)用戶賬號信息查詢數(shù)據(jù)的最新版本號,返回到客戶端，客戶端根據(jù)服務(wù)器端的版本號和本地進行比較，如果一致則說明是最新版本之后判斷本地是否有修改有修改則直接提交即可，如果不一致一定不是最新版本則進行服務(wù)器端拉取數(shù)據(jù)更新數(shù)據(jù)和版本號后再提交本地修改（如果有修改）。
從服務(wù)器端拉取數(shù)據(jù)流程
從服務(wù)器端拉取更新有些麻煩，如果在一臺設(shè)備上有幾個版本沒有更新的話，需要考慮將幾個版本的數(shù)據(jù)合并，具體問題以及流程在后文中會提及。
從服務(wù)器端拉取數(shù)據(jù)基本流程如下：
客戶端拉取數(shù)據(jù)后更新本地數(shù)據(jù)流程
客戶端調(diào)用 PullData 接口 從服務(wù)器拉取本地需要修改的數(shù)據(jù)同時每一條數(shù)據(jù)都對應(yīng)一個操作狀態(tài)來更新本地數(shù)據(jù)，從服務(wù)器端返回數(shù)據(jù)的同時返回數(shù)據(jù)對應(yīng)的操作狀態(tài)，客戶端根據(jù)返回的操作狀態(tài)對數(shù)據(jù)進行相應(yīng)的處理，返回數(shù)據(jù)時也需要將最新數(shù)據(jù)的版本號也返回用以客戶端更新本地數(shù)據(jù)版本。
客戶端向服務(wù)器推送更新
客戶端調(diào)用 PushData 接口向服務(wù)器端推送更新，將需要提交的修改提交到服務(wù)器端，服務(wù)器端返回客戶端每一個需要進行修改的數(shù)據(jù)的操作狀態(tài)，是否修改成功。
服務(wù)器端更新數(shù)據(jù)
客戶端向服務(wù)器端推送更新之后，服務(wù)器端需要進行處理。
首先需要判斷客戶端的版本是否是最新版本，如果不是最新則提示客戶端先更新本地數(shù)據(jù)到最新版本再更新數(shù)據(jù)，如果是最新的再向下處理。
之后需要將客戶端的請求數(shù)據(jù)（一個json字符串）反序列化轉(zhuǎn)換為請求實體列表，如果轉(zhuǎn)換失敗則說明客戶端的請求數(shù)據(jù)是有問題的則不進行處理，如果轉(zhuǎn)換成功再向下處理。
然后遍歷請求實體列表，根據(jù)請求數(shù)據(jù)的操作類型進行不同數(shù)據(jù)操作，每條數(shù)據(jù)操作完之后設(shè)置對應(yīng)的操作狀態(tài)。
最后所有請求數(shù)據(jù)更新完成之后，新增一個版本，并將版本設(shè)置到響應(yīng)。
被我踩到的那些坑
Pull 數(shù)據(jù)版本合并
從服務(wù)器端拉取數(shù)據(jù)的時候需要考慮到多個版本的提交數(shù)據(jù)合并問題，我們的數(shù)據(jù)比較簡單是直接更新原來的數(shù)據(jù)，因此不會涉及到文本分塊再合并這一類太復(fù)雜的操作，但是也需要將幾個版本的修改進行合并，例如新增數(shù)據(jù)，兩個版本各新增兩條數(shù)據(jù)則應(yīng)返回四條數(shù)據(jù)才對,一個版本新增另一個版本刪除掉的數(shù)據(jù)就不應(yīng)該返回給客戶端。
這就需要考慮如何高效并且準(zhǔn)確的返回客戶端需要更新的數(shù)據(jù)，這里需要提及一下我的版本表的涉及，版本表里除了版本號之外有更新人，更新時間和每次調(diào)用 PushData 接口時的請求參數(shù)和返回給客戶端的操作狀態(tài)集合的響應(yīng)的轉(zhuǎn)換為json字符串存儲在數(shù)據(jù)庫中，每次更新完數(shù)據(jù)之后在版本表中插入一條新的版本數(shù)據(jù)。
解決方案一：
第一種方式，首先我考慮從版本表里取出每次修改成功的數(shù)據(jù)，再將多個版本的修改進行合并到一個List，再去重，如果遇到兩條相同的數(shù)據(jù)需要進行去重操作，需要根據(jù)每條數(shù)據(jù)的操作類型來判斷該如何具體的去重，大致分四種情況：
- 先新增后修改 --> Add
- 先新增最后刪除 -->
null不需要返回給客戶端 - 先修改之后還是修改 --> Update
- 先修改最后刪除 --> Delete
這里不僅操作類型需要修改，數(shù)據(jù)內(nèi)容也是需要進行合并的，需要最新的數(shù)據(jù)返回。
解決方案二：
第二種方式，按照版本的更新時間和數(shù)據(jù)的創(chuàng)建時間和更新時間的關(guān)系來進行篩選數(shù)據(jù)和判斷數(shù)據(jù)的操作類型，如果數(shù)據(jù)刪除的話只是修改數(shù)據(jù)的狀態(tài)并不真正的刪除數(shù)據(jù)。
首先將更新時間大于本地版本對應(yīng)的版本更新時間的數(shù)據(jù)查詢出來，這些數(shù)據(jù)是在本地版本更新之后的所有數(shù)據(jù)，
之后篩選數(shù)據(jù)，按操作類型可分四種情況：
- 創(chuàng)建時間 >= 版本更新時間 && IsDeleted = 0 --> Add
- 創(chuàng)建時間 >= 版本更新時間 && IsDeleted = 1 -->
null先創(chuàng)建后刪除，不需要返回到客戶端 - 創(chuàng)建時間 < 版本更新時間 && IsDeleted = 0 --> Update
- 創(chuàng)建時間 < 版本更新時間 && IsDeleted = 1 --> Delete
篩選并判斷操作類型之后將數(shù)據(jù)返回給客戶端
綜合比較，確定版本合并方案
經(jīng)過分析，第一種方案數(shù)據(jù)操作起來非常麻煩，相對的第二種解決方案數(shù)據(jù)操作會很少，可以在數(shù)據(jù)庫層面進行判斷篩選，至于數(shù)據(jù)準(zhǔn)確度方面兩者差不多，
考慮并發(fā)問題的話可以在 調(diào)用 Push 接口時根據(jù)用戶賬號進行加鎖，綜合一下，最終采用第二種解決方案。
Push接口
調(diào)用Push接口的時候原本沒有判斷本地的版本號，如果出現(xiàn)客戶端沒有按照設(shè)定的順序來調(diào)用接口可能就會出現(xiàn)不可想象的數(shù)據(jù)災(zāi)難，而且作為接口本身是沒辦法控制客戶端的調(diào)用順序的。
所以，修改后的 Push 接口需要客戶端傳遞一個客戶端版本號的參數(shù)，如果不是最新版本的數(shù)據(jù)拒絕提交，并提示客戶端先更新數(shù)據(jù)到最新版本后再提交數(shù)據(jù)。
時間不統(tǒng)一
這個問題算是自己給自己挖的坑，在更新數(shù)據(jù)的時候時間取的都是網(wǎng)站服務(wù)器端時間，但是在新增版本的時候新增的參數(shù)里的更新時間用的卻是數(shù)據(jù)庫服務(wù)器的時間，由于數(shù)據(jù)庫服務(wù)器和網(wǎng)站服務(wù)器不在一臺服務(wù)器上，
數(shù)據(jù)庫服務(wù)器的時間比網(wǎng)站服務(wù)器上的時間慢了幾秒，這導(dǎo)致我在從服務(wù)器端拉取數(shù)據(jù)時出現(xiàn)有的數(shù)據(jù)沒有拉取出來的情況，后來debug從數(shù)據(jù)庫中查詢數(shù)據(jù)確實更新了而且版本也正確插入了，最后一一記錄每一條數(shù)據(jù)的更新時間和每個版本的更新時間，
這才發(fā)現(xiàn)時間有點不太對，再檢查下自己的sql語句，發(fā)現(xiàn)新增版本的sql的更新時間用的是GETDATE(),而更新數(shù)據(jù)的sql都是參數(shù)，用的是網(wǎng)站服務(wù)器的時間。。發(fā)現(xiàn)問題的我頓時想抽死自己...（
In the end
最后，這個設(shè)計一定還存在著不足，希望大神看到能給出自己的看法和意見，有不正確的地方還希望能夠告知。
給自己挖個坑過一段時間再來填，【數(shù)據(jù)校驗】+【數(shù)據(jù)分割】，下一次解決這兩個問題。
