產品此前的資料備份方案，存在不少問題，所以需要設計乙個新的方案。本文總結一下新舊方案的優劣
而恢復邏輯，則是從伺服器的mysql資料庫裡，遍歷找到所有的記錄，也生成sql語句，發回客戶端，客戶端再執行sql進行恢復。當發生衝突的時候，以客戶端的資料為準，違反主鍵約束的時候，插入資料就會失敗。比如客戶端將乙個賣品的**改為200，而伺服器mysql裡的記錄還是100，那麼下發的insert語句就無法執行
這個方案有幾個問題：
1、客戶端的備份邏輯，散落在業務模組裡，因為涉及到業務操作的地方，都需要記得修改modify_date和create_date，容易造成資料備份不上去的bug
2、備份邏輯依賴客戶端本地時間，而客戶端時間總是不可靠的
4、生成恢復檔案之前，需要遍歷mysql表，資料量大的時候，容易使客戶端超時而恢復失敗
5、恢復邏輯以客戶端資料為準，在某些場景下不滿足需求，比如做不到在服務端對客戶端的資料進行干預校正
6、sql是純文字，當資料量大的時候，在網路間傳輸的資料太多
新的方案準備這樣做：備份和恢復不再基於內容，而是基於檔案。每次備份都把本地的資料庫檔案上傳到伺服器。但是在傳輸上有特別處理，只傳檔案的差量；在伺服器利用差量檔案，合併得到完整的客戶端資料庫檔案副本。同時在資料庫增加乙個差量表，配合trigger，將每次的insert，update，delete操作，寫到差量表中。在伺服器遍歷差量表，將有變化的資料寫到mysql裡
恢復的時候，就直接把資料庫檔案發到客戶端，替換掉客戶端的資料庫檔案
在這個過程中，當然需要在服務端增加專門的表，來控制整個流程，比如記錄檔案在oss裡的路徑，最後備份的時間等，本文不展開
這個方案相比老方案的優勢：
1、客戶端業務**不再需要關注資料同步的邏輯，減少了出錯的機會
2、不依賴客戶端時間
3、服務端始終有客戶端資料庫的完整映象，即使有bug，也只是沒有寫到mysql裡，對匯**計有影響，但是不會造成客戶端資料直接丟失
4、恢復檔案不需要每次生成，速度快
5、可以在服務端直接修改資料庫檔案，校正客戶端的錯誤；版本公升級時如果需要做資料遷移，也可以在服務端統一處理
6、由於每次備份的差異量小，生成的差量檔案也很小，需要在網路間傳輸的檔案一般也比較小
總的來說，新方案的優勢比較明顯。但是，這個方案也只能解決單個客戶端操作的場景，對於多終端同時操作就無能為力了。比如說，2個pad同時修改乙個會員的餘額，那先備份的那條資料將會被覆蓋，造成資料錯誤。所以，還需要保證同時只有乙個終端運算元據，這樣才能放心地替換檔案。因為這種場景下，是不存在資料衝突的
如果要支援離線環境下，多終端同時操作的場景，則還需要在這個方案的基礎上更進一步，識別出終端差異，將各終端的資料merge到中心檔案，此外還需要保證檔案合併的先後順序等。這種場景比單客戶端的場景要複雜很多，不在本文討論範圍，有空單獨再寫
離線檔案與資料同步
1.服務端的離線檔案設定 為了使共享網路資源可以離線使用，離線檔案 將這些共享資源的乙個版本儲存在客戶端計算機中稱為檔案系統快取的保留的磁碟空間部分中。不管是否連線到網路，客戶端計算機都可以訪問這種快取。建立新的共享資源時，預設情況下允許離線訪問，這意味著可以在有潛在的不安全因素的計算機中離線儲存安...
資料同步方案
作為業務系統的開發設計人員，資料及資料同步是非常重要的工作之一。在日常的軟體開發過程中，經常會碰到推送和拉取等業務。那麼一開始如何選用推送或拉取這兩個方案呢？這是由實際業務決定 雙方系統的技術實現 雙方系統的架構和效能，看日後是否此業務會經常修改等多方面決定的。下面本文就從實際的兩個業務情況來討論。...
資料同步方案
三 軟體選擇 同步分為 實時同步和離線同步 實時同步，一般是通過監控源資料變更操作，通過在目標端實時重放操作，從而達到實時同步的目的 離線同步，相當於某個時候對源資料做乙個快照。mysql自帶功能 一般針對的是整個資料庫 參考 主主同步 同步型別 實時同步 簡介 kafka是訊息中介軟體的一種 開發...