前言

服務重構，老版系統為php程式碼，新版系統改為Java。
資料層面沿用之前老版服務的資料庫結構，部分庫欄位進行修改。

最終目的：服務實現切換，資料實現切換(老庫到新庫)，不能停機升級，儘量減小對使用者影響。

實現方案：日誌追加
下面具體說一下自己的實現方案，可能會有紕漏的地方，僅做參考。

日誌追加法

1. 步驟一
   通過使用者執行的新增、修改、刪除操作，記錄到日誌檔案中，old_db不再寫入新資料。
   日誌的格式統一為被修改的庫、被修改的表、被修改的欄位等資訊。
   保證日誌的統一性，方便日誌同步服務同步資料。
   

2. 步驟二
   開發一個數據同步服務syn-data-service，將舊庫的資料同步到新庫中。
   

3. 步驟三
   當資料同步完畢後，將new-service設定為暫不可寫資料(日誌同步很快，會犧牲部分使用者體驗)。 且開發一個日誌同步工具syn-log-service，將日誌同步到新庫中
   

4，步驟四
開發一個compare-service，進行資料校驗

5，步驟五
資料沒有問題後切換為new-db，使用者執行的新增、修改、刪除 雙寫到日誌和new_db中。

6，步驟六
兜底策略：如果發現數據有大規模不一致或者大規模資料丟失的情況，可以通過日誌回寫到old_db中，然後切換服務到old_server。

大致步驟如上所示，可能有考慮不周全的地方，這裡只是短時間的犧牲了使用者的體驗來完整資料同步的一致性。
步驟六是我多加的一個步驟，做任何事情都要想一個兜底策略，這也是我最近感觸最深的一點體驗。用於不要過分相信依賴的呼叫方，做好plan b。