多終端數(shù)據(jù)同步機制設計（二）
Intro
如果您沒有看上一篇文章，建議您先移步到這里查看 第一部分
上一次主要解決了基本的數(shù)據(jù)增量同步的問題，但仍然存在一些問題。
可能存在的主要問題：
- 大數(shù)據(jù)量傳輸時，數(shù)據(jù)在傳輸過程出現(xiàn)部分丟失，數(shù)據(jù)不完整
- 超大數(shù)據(jù)量需要同步，導致響應時間過長而導致連接超時
針對以上可能出現(xiàn)的這兩個問題，需要對數(shù)據(jù)進行校驗并且數(shù)據(jù)量超過一定量時進行分批量傳輸，
本文將著手解決 數(shù)據(jù)校驗 和 數(shù)據(jù)分批次傳輸 這兩個問題。
同步流程概覽
結合之前的同步流程，加上數(shù)據(jù)校驗和分批次傳輸數(shù)據(jù)，大概流程如下：
客戶端調(diào)用服務器端的 Pull 接口從服務器端拉取數(shù)據(jù)，
如果本地版本號等于服務器端最新版本號，則已更新的最新版本，
如果本地版本小于服務器端最新的版本號，則拉取需要更新的數(shù)據(jù)，服務器端返回數(shù)據(jù)的同時會返回本地傳輸?shù)臄?shù)據(jù)的一個校驗值，
客戶端獲取到服務器端響應時先根據(jù)接收到的數(shù)據(jù)計算校驗值，計算出來之后與服務器端返回的校驗值進行比較，
如果本地計算的校驗值與服務器端返回的校驗值一致則進行更新客戶端本地數(shù)據(jù)，不一致則視為無效數(shù)據(jù)，重新請求 Pull 接口。
更新到最新版本之后，判斷本地是否存在未提交的版本，如果本地不存在修改則本次數(shù)據(jù)同步完成，如果本地存在修改，則提交本地修改，提交本地數(shù)據(jù)的之前要先計算傳輸數(shù)據(jù)的校驗值，校驗值和本地數(shù)據(jù)一起傳給服務器端 Push接口。
服務器端 Push 接收到客戶端請求之后需要進行數(shù)據(jù)校驗，根據(jù)傳輸?shù)臄?shù)據(jù)計算校驗值并與客戶端傳的校驗值比較，
如果兩個值不一致，則視為數(shù)據(jù)在傳輸過程中發(fā)生丟失或是異常數(shù)據(jù)，則不處理并返回客戶端，本次請求屬于異常請求。
如果兩個值一致，再進行數(shù)據(jù)處理，處理結束之后，數(shù)據(jù)會有一個返回狀態(tài)和其他必要的屬性，根據(jù)數(shù)據(jù)計算校驗值，與從服務器拉取數(shù)據(jù)時類似，不再贅述，
客戶端數(shù)據(jù)校驗通過之后，根據(jù)服務器端處理狀態(tài)進行本地數(shù)據(jù)的更新。
下面展示添加數(shù)據(jù)校驗后的主要流程圖：
服務器端獲取數(shù)據(jù)：
客戶端拉取數(shù)據(jù)：
服務器端更新數(shù)據(jù)：
客戶端推送更新數(shù)據(jù)：
數(shù)據(jù)校驗
數(shù)據(jù)校驗，我們用的是MD5進行校驗，取傳輸數(shù)據(jù)的MD5，使用MD5有兩方面的考慮：
一方面因為MD5生成的字符串不算太長，不會影響傳輸?shù)臄?shù)據(jù)量，
另一方面也是因為MD5比較通用一些，APP端實現(xiàn)起來也比較方便。
數(shù)據(jù)分批傳輸
數(shù)據(jù)分批次傳輸，自己感覺這里實現(xiàn)的比較 LOW ，這里類似于網(wǎng)站上的分頁，沒想到更好的解決方案，期待大神分享更好的解決方案。
返回客戶端 當前請求數(shù)據(jù)頁碼索引 和 本次數(shù)據(jù)傳輸總頁數(shù)，如果頁碼索引小于總頁數(shù)，則頁碼索引+1，再請求一次接口知道返回的頁碼索引等于總頁數(shù)。
End
最后，這個設計一定還存在著不足，希望大神看到能給出自己的看法和意見，有不正確的地方還希望能夠告知。
整個同步流程設計的流程圖，點我下載
另如果你有別的方案歡迎共同討論，希望大神看到能給出自己的看法和意見，有不正確的地方還希望能夠告知。
