多終端數(shù)據(jù)同步機(jī)制設(shè)計(jì)

1、多終端數(shù)據(jù)同步機(jī)制設(shè)計(jì)(一)多終端數(shù)據(jù)同步機(jī)制設(shè)計(jì)(一)Intro因?yàn)轫?xiàng)目需要，需要設(shè)計(jì)一個(gè)多終端數(shù)據(jù)同步的機(jī)制，需要滿足以下條件：1.多個(gè)終端數(shù)據(jù)操作及同步2.每次同步的時(shí)候只拉取需要同步的數(shù)據(jù)，且數(shù)據(jù)不能存在丟失3.盡可能少的調(diào)用服務(wù)器端接口同步流程整體同步流程我想仿照Git數(shù)據(jù)同步的方式來進(jìn)行數(shù)據(jù)同步，于是放著Git同步的流程來進(jìn)行設(shè)計(jì)，首先每次提交會(huì)有一個(gè)版本號(hào)，另外每次提交之前應(yīng)盡可能先從服務(wù)器端拉取數(shù)據(jù)，保證客戶端的數(shù)據(jù)是最新的情況下再進(jìn)行提交本地的修改。按照Git的方式來進(jìn)行數(shù)據(jù)同步時(shí)，可能會(huì)存在數(shù)據(jù)沖突，如果存在數(shù)據(jù)沖突需要客戶端解決沖突。也就是總體來說，操作有兩個(gè)大的操作，一

2、個(gè)是從服務(wù)器端拉取數(shù)據(jù)，一個(gè)是向服務(wù)器端推送數(shù)據(jù)更新。在數(shù)據(jù)庫層面有一個(gè)數(shù)據(jù)版本表來存儲(chǔ)每一次提交，每一次更新會(huì)在更新結(jié)束之后將在版本表中加上一條記錄，更新一個(gè)版本，并將版本號(hào)返回給客戶端，每次從服務(wù)器端拉取更新的時(shí)候不僅會(huì)將更新的數(shù)據(jù)返回給客戶端，也會(huì)將最新的版本號(hào)返回到客戶端，用以客戶端下一次同步數(shù)據(jù)。最后服務(wù)器端提供了三個(gè)接口GetCurrentVersion()查詢用戶數(shù)據(jù)的最新版本號(hào)，PullData()從服務(wù)器端拉取更新數(shù)據(jù),PushData()向服務(wù)器端推送本地?cái)?shù)據(jù)更新思慮再三之后最終產(chǎn)出了下面的流程圖：從服務(wù)器端獲取用戶數(shù)據(jù)的最客戶端調(diào)用GetCurrentVersi號(hào),返回到

3、客戶端，客戶端根據(jù)服務(wù)器端的版本號(hào)和本地進(jìn)行比較，如果一致則說明是最新版本之后判斷本地是否有修改有修改則直接提交即可，如果不一致一定不是最新版本則進(jìn)行服務(wù)器端拉取數(shù)據(jù)更新數(shù)據(jù)和版本號(hào)后再提交本地修改(如果有修改)。從服務(wù)器端拉取數(shù)據(jù)流程從服務(wù)器端拉取更新有些麻煩，如從服務(wù)器端拉取數(shù)據(jù)基本流程如下最新版本號(hào)on()接口，需要傳遞一個(gè)標(biāo)識(shí)用戶賬的參數(shù)，這樣才能查詢到某一個(gè)用戶的數(shù)據(jù)信息。根據(jù)用戶賬號(hào)信息查詢數(shù)據(jù)的最新版本上有幾個(gè)版本沒有更新的話，需要考慮將幾個(gè)版本的數(shù)據(jù)合并，具體問題以及流程在后文中會(huì)提及?？蛻舳死?shù)據(jù)后更新本地?cái)?shù)據(jù)流程客戶端調(diào)用PullData接口從服務(wù)器拉取本地需要修改的數(shù)據(jù)

4、同時(shí)每一條數(shù)據(jù)都對(duì)應(yīng)一個(gè)操作狀態(tài)來更新本地?cái)?shù)據(jù)，從服務(wù)器端返回?cái)?shù)據(jù)的同時(shí)返回?cái)?shù)據(jù)對(duì)應(yīng)的操作狀態(tài)，客戶端根據(jù)返回的操作狀態(tài)對(duì)數(shù)據(jù)進(jìn)行相應(yīng)的處理，返回?cái)?shù)據(jù)時(shí)也需要將最新數(shù)據(jù)的版本號(hào)也返回用以客戶端更新本地?cái)?shù)據(jù)版本。円|曲朋荻敗Tr1客戶端向服務(wù)器推送更新客戶端調(diào)用PushData接口向服務(wù)器端推送更新，將需要提交的修改提交到服務(wù)器端，服務(wù)器端返回客戶端每一個(gè)需要進(jìn)行修改的數(shù)據(jù)的操作狀態(tài)，是否修改成功。服務(wù)器端更新數(shù)據(jù)客戶端向服務(wù)器端推送更新之后，服務(wù)器端需要進(jìn)行處理。首先需要判斷客戶端的版本是否是最新版本，如果不是最新則提示客戶端先更新本地?cái)?shù)據(jù)到最新版本再更新數(shù)據(jù)，如果是最新的再向下處理。之后需要

5、將客戶端的請(qǐng)求數(shù)據(jù)（一個(gè)son字符串）反序列化轉(zhuǎn)換為請(qǐng)求實(shí)體列表，如果轉(zhuǎn)換失敗則說明客戶端的請(qǐng)求數(shù)據(jù)是有問題的則不進(jìn)行處理，如果轉(zhuǎn)換成功再向下處理。然后遍歷請(qǐng)求實(shí)體列表，根據(jù)請(qǐng)求數(shù)據(jù)的操作類型進(jìn)行不同數(shù)據(jù)操作，每條數(shù)據(jù)操作完之后設(shè)置對(duì)應(yīng)的操作狀態(tài)。最后所有請(qǐng)求數(shù)據(jù)更新完成之后，新增一個(gè)版本，并將版本設(shè)置到響應(yīng)。潔先史斯；tMSWePlSiSffiEJfc判z詢用廣的忌新謝:?坯新楓屯旅睫ISiJl底.牛咸河皮的遊裁更列磚里Sffifcts?挺,rz對(duì)應(yīng)艷為吏礪扶態(tài)被我踩到的那些坑Pull數(shù)據(jù)版本合并從服務(wù)器端拉取數(shù)據(jù)的時(shí)候需要考慮到多個(gè)版本的提交數(shù)據(jù)合并問題，我們的數(shù)據(jù)比較簡單是直接更新原來的

6、數(shù)據(jù)，因此不會(huì)涉及到文本分塊再合并這一類太復(fù)雜的操作，但是也需要將幾個(gè)版本的修改進(jìn)行合并，例如新增數(shù)據(jù)，兩個(gè)版本各新增兩條數(shù)據(jù)則應(yīng)返回四條數(shù)據(jù)才對(duì)一個(gè)版本新增另一個(gè)版本刪除掉的數(shù)據(jù)就不應(yīng)該返回給客戶端。這就需要考慮如何高效并且準(zhǔn)確的返回客戶端需要更新的數(shù)據(jù)，這里需要提及一下我的版本表的涉及，版本表里除了版本號(hào)之外有更新人，更新時(shí)間和每次調(diào)用PushData接口時(shí)的請(qǐng)求參數(shù)和返回給客戶端的操作狀態(tài)集合的響應(yīng)的轉(zhuǎn)換為son字符串存儲(chǔ)在數(shù)據(jù)庫中，每次更新完數(shù)據(jù)之后在版本表中插入一條新的版本數(shù)據(jù)。解決方案一：第一種方式，首先我考慮從版本表里取出每次修改成功的數(shù)據(jù)，再將多個(gè)版本的修改進(jìn)行合并到一個(gè)-is

7、t，再去重，如果遇到兩條相同的數(shù)據(jù)需要進(jìn)行去重操作，需要根據(jù)每條數(shù)據(jù)的操作類型來判斷該如何具體的去重，大致分四種情況：先新增后修改-Add先新增最后刪除-null不需要返回給客戶端先修改之后還是修改-Update先修改最后刪除-Delete這里不僅操作類型需要修改，數(shù)據(jù)內(nèi)容也是需要進(jìn)行合并的，需要最新的數(shù)據(jù)返回。解決方案二：第二種方式，按照版本的更新時(shí)間和數(shù)據(jù)的創(chuàng)建時(shí)間和更新時(shí)間的關(guān)系來進(jìn)行篩選數(shù)據(jù)和判斷數(shù)據(jù)的操作類型，如果數(shù)據(jù)刪除的話只是修改數(shù)據(jù)的狀態(tài)并不真正的刪除數(shù)據(jù)。首先將更新時(shí)間大于本地版本對(duì)應(yīng)的版本更新時(shí)間的數(shù)據(jù)查詢出來，這些數(shù)據(jù)是在本地版本更新之后的所有數(shù)據(jù)，之后篩選數(shù)據(jù)，按操作類

8、型可分四種情況：創(chuàng)建時(shí)間=版本更新時(shí)間&IsDeleted=0-Add創(chuàng)建時(shí)間=版本更新時(shí)間&IsDeleted=1-null先創(chuàng)建后刪除，不需要返回到客戶端創(chuàng)建時(shí)間Update創(chuàng)建時(shí)間Delete篩選并判斷操作類型之后將數(shù)據(jù)返回給客戶端綜合比較，確定版本合并方案經(jīng)過分析，第一種方案數(shù)據(jù)操作起來非常麻煩，相對(duì)的第二種解決方案數(shù)據(jù)操作會(huì)很少，可以在數(shù)據(jù)庫層面進(jìn)行判斷篩選，至于數(shù)據(jù)準(zhǔn)確度方面兩者差不多，考慮并發(fā)問題的話可以在調(diào)用Push接口時(shí)根據(jù)用戶賬號(hào)進(jìn)行加鎖，綜合一下，最終采用第二種解決方案。Push接口調(diào)用Push接口的時(shí)候原本沒有判斷本地的版本號(hào)，如果出現(xiàn)客戶端沒有按照設(shè)定的順序來調(diào)用接口

9、可能就會(huì)出現(xiàn)不可想象的數(shù)據(jù)災(zāi)難，而且作為接口本身是沒辦法控制客戶端的調(diào)用順序的。所以，修改后的Push接口需要客戶端傳遞一個(gè)客戶端版本號(hào)的參數(shù)，如果不是最新版本的數(shù)據(jù)拒絕提交，并提示客戶端先更新數(shù)據(jù)到最新版本后再提交數(shù)據(jù)。時(shí)間不統(tǒng)一這個(gè)問題算是自己給自己挖的坑，在更新數(shù)據(jù)的時(shí)候時(shí)間取的都是網(wǎng)站服務(wù)器端時(shí)間，但是在新增版本的時(shí)候新增的參數(shù)里的更新時(shí)間用的卻是數(shù)據(jù)庫服務(wù)器的時(shí)間，由于數(shù)據(jù)庫服務(wù)器和網(wǎng)站服務(wù)器不在一臺(tái)服務(wù)器上，數(shù)據(jù)庫服務(wù)器的時(shí)間比網(wǎng)站服務(wù)器上的時(shí)間慢了幾秒，這導(dǎo)致我在從服務(wù)器端拉取數(shù)據(jù)時(shí)出現(xiàn)有的數(shù)據(jù)沒有拉取出來的情況，后來debug從數(shù)據(jù)庫中查詢數(shù)據(jù)確實(shí)更新了而且版本也正確插入了，最后一一記錄每一條數(shù)據(jù)的更新時(shí)間和每個(gè)版本的更新時(shí)間，這才發(fā)現(xiàn)時(shí)間有點(diǎn)不太對(duì)，再檢查下自己的Sql語句，發(fā)現(xiàn)新增版本的sql的更新時(shí)間用的是GET