產品此前的資料備份方案，存在不少問題，所以需要設計一個新的方案。本文總結一下新舊方案的優劣

首先APP是一個支援離線的應用。本地資料儲存在sqlite，在離線環境下，在本地資料庫裡讀寫記錄，在有網路的時候，再將資料備份到伺服器；同時，也可以隨時將資料從伺服器恢復到本地

舊方案

此前的備份方案是基於內容的，每一條記錄都有create_date和modify_date欄位，同時APP儲存有latest_backup_date（上次備份時間）。然後開始備份的時候，就對所有表進行掃描，根據這3個時間的對比，直接生成sql語句，發到伺服器執行，寫入服務端的mysql資料庫；收到伺服器的成功響應之後，又重新整理latest_backup_date

而恢復邏輯，則是從伺服器的mysql資料庫裡，遍歷找到所有的記錄，也生成sql語句，發回客戶端，客戶端再執行sql進行恢復。當發生衝突的時候，以客戶端的資料為準，違反主鍵約束的時候，插入資料就會失敗。比如客戶端將一個賣品的價格改為200，而伺服器mysql裡的記錄還是100，那麼下發的insert語句就無法執行

這個方案有幾個問題：

1、客戶端的備份邏輯，散落在業務模組裡，因為涉及到業務操作的地方，都需要記得修改modify_date和create_date，容易造成資料備份不上去的BUG

2、備份邏輯依賴客戶端本地時間，而客戶端時間總是不可靠的

3、服務端缺少客戶端資料庫的完整映象，也就是說，一旦有BUG導致部分資料沒有備份上來，那麼如果使用者解除安裝了APP或者PAD丟失，這部分資料就永遠找不回來了

4、生成恢復檔案之前，需要遍歷mysql表，資料量大的時候，容易使客戶端超時而恢復失敗

5、恢復邏輯以客戶端資料為準，在某些場景下不滿足需求，比如做不到在服務端對客戶端的資料進行干預校正

6、sql是純文字，當資料量大的時候，在網路間傳輸的資料太多

新方案

新的方案准備這樣做：備份和恢復不再基於內容，而是基於檔案。每次備份都把本地的資料庫檔案上傳到伺服器。但是在傳輸上有特別處理，只傳檔案的差量；在伺服器利用差量檔案，合併得到完整的客戶端資料庫檔案副本。同時在資料庫增加一個差量表，配合trigger，將每次的insert，update，delete操作，寫到差量表中。在伺服器遍歷差量表，將有變化的資料寫到mysql裡

恢復的時候，就直接把資料庫檔案發到客戶端，替換掉客戶端的資料庫檔案

在這個過程中，當然需要在服務端增加專門的表，來控制整個流程，比如記錄檔案在OSS裡的路徑，最後備份的時間等，本文不展開

這個方案相比老方案的優勢：

1、客戶端業務程式碼不再需要關注資料同步的邏輯，減少了出錯的機會

2、不依賴客戶端時間

3、服務端始終有客戶端資料庫的完整映象，即使有BUG，也只是沒有寫到mysql裡，對彙總統計有影響，但是不會造成客戶端資料直接丟失

4、恢復檔案不需要每次生成，速度快

5、可以在服務端直接修改資料庫檔案，校正客戶端的錯誤；版本升級時如果需要做資料遷移，也可以在服務端統一處理

6、由於每次備份的差異量小，生成的差量檔案也很小，需要在網路間傳輸的檔案一般也比較小

新方案的侷限性

總的來說，新方案的優勢比較明顯。但是，這個方案也只能解決單個客戶端操作的場景，對於多終端同時操作就無能為力了。比如說，2個PAD同時修改一個會員的餘額，那先備份的那條資料將會被覆蓋，造成資料錯誤。所以，還需要保證同時只有一個終端操作資料，這樣才能放心地替換檔案。因為這種場景下，是不存在資料衝突的

如果要支援離線環境下，多終端同時操作的場景，則還需要在這個方案的基礎上更進一步，識別出終端差異，將各終端的資料merge到中心檔案，此外還需要保證檔案合併的先後順序等。這種場景比單客戶端的場景要複雜很多，不在本文討論範圍，有空單獨再寫