隨著業務發展，我們的系統可能面臨著改造升級。改造過程中往往避免不了數據模型的變動，這時候需要將老表老模型遷移到新表新模型，並且還要保證歷史數據的遷移以及映射。

這就帶來了一個問題，老表老模型如何遷移到新表新模型，以下是常用的兩種方案

數據同步很少有隻同步單向的。除非是資料庫的壓力大了要將表拆分出，這時候存在表模型一樣的情況。更常見的是在灰度階段，新老系統同時都在運行，這時候就需要同時維護新老數據，因此需要採取雙向同步的策略。

雙寫

數據同步又分為增量數據同步、存量數據同步。一般來說我們會在老系統中所有更新表的地方將數據同步邏輯開發好，先上線，同步幾天存量數據，然後選擇某上線後的一天作為存量數據的截止時間，這是為了防止存量數據和增量數據中間有數據空洞，造成數據丟失的情況

增量數據

同步增量數據有幾個步驟

1. 將老系統中所有新增、更新的地方都寫上數據同步邏輯
2. 在同步數據的時候，除了新老模型欄位的映射邏輯以外，當操作是新增的時候，直接新增新表數據，當操作是更新的時候，如果新表沒有對應信息，那麼查一下老表的數據，然後映射到新模型數據結構再新增到新表
3. 更新新模型的時候可能存在併發問題，這時候我們插入的時候要檢查時間戳或者版本號，如果庫內數據早於自己，就更新，否則就丟棄。

存量數據

存量數據一般就是取數，取數有兩種比較常見的方式

1. 通過sql掃表，如果表比較大可以按月或者按天掃，優點是操作簡單，缺點是需要人工一直介入，且掃表會對資料庫造成一定壓力，影響業務功能的穩定性
2. 同步離線表取數，將離線表的數據發送到mq或者kafaka，消費後進行數據同步

存量數據同步的時候也需要註意的是數據的版本問題，如果不存在就新增，如果存在就判斷時間戳或版本號，總之就是將最新的數據更新進去，老版本數據拋棄。

總結

從上面我們可以看出雙向同步的問題就是同步代碼的復用性差，業務代碼內部維護的增量邏輯和存量同步的邏輯不能復用，需要重覆開發。還有一個問題就是當新老模型差距較大或者新數據源的變動比較大的時候，比如從一種存儲介質同步到另一種存儲介質，這些複雜邏輯維護到了每個更新介面處，開發成本不可預估，因此此方案只適合公司沒有中間件支持並且又要做改造的情況下使用。

ps：如果存量數據有時效性，比如一個月以前的數據不要了，並且改造的周期比較長，那麼可以不需要同步存量數據，讓增量數據跑一個月即可。

binlog，數據雙向同步

我們都知道當數據變更的時候(新增、更新、刪除)，db 都會記錄變更日誌，並且同步到各個從庫中，這個日誌就是我們耳聞能詳的 binlog。開源的工具主要有：Canal、otter等，基本原理就是解析binlog日誌，然後發送到消息中間件，客戶端消費後進行處理。

由於我們是線上新老系統一起在跑，因此我們需要進行數據雙向同步，也就是正向同步：老表到新表；逆向同步：新表到老表。

老表到新表增量同步

當老系統進行DML（insert、update，由於大部分業務都是採用邏輯刪的情況也就是update，因此這裡不考慮delete情況）操作的時候，老表會吐出相應的binlog，binlog 經過我們的數據同步工具會將對應的消息投遞到kafka或者mq，在我們的 convert 數據同步邏輯內將對應的消息映射成新數據模型後，會將消息是 insert 還是 update 進行不同處理

insert

經過 convert 將消息轉化成對應的新數據模型後，直接進行插入操作。這裡可能會出現一些異常場景，比較常見的是 insert 操作還沒插入新表，老系統就對該記錄操作了一次更新，然後也吐出了一條 binlog，這時候這條 binlog 先被客戶端消費，由於更新的時候如果新表內沒有數據，會更新失敗，更新失敗後會走數據訂正邏輯，數據訂正的時候如果新表沒有數據則會新增。這時候再操作 insert 操作就會報主鍵衝突。新增失敗的時候也會走數據訂正邏輯。

這裡可能有個疑問，直接在消費到的時候根據數據的主鍵ID加一把分散式鎖能不能解決問題。答案是不能解決，因為更新操作可能會更先被消費到，這時候還是會報主鍵重覆，並且如果數據量大的情況下，加鎖還會導致數據同步性能問題。

正常流程：

異常流程：

update

客戶端收到 update 的binlog消息後，會將消息體內容經過 convert 邏輯轉化成新模型，也就是資料庫PO對象，然後進行 update 操作。但是不是無腦更新的，需要加個樂觀鎖（where update_time < #{updateTime}），如果表裡數據已經比你新了，那麼就不更新，更新失敗，走數據訂正邏輯。如果表裡數據比較老，那麼更新成功。

正常流程：

異常流程：

數據訂正

不管是 insert 操作還是 update 操作，當操作失敗了以後，我們都要進行數據訂正，這是為了保證最終數據一致性。

數據訂正的整個過程都需要根據主鍵ID來進行加分散式鎖，這是因為數據訂正的時候是拿主鍵ID去新老表查數據，然後進行比對後才決定如何進行訂正，這裡如果不加鎖的話會導致併發問題，從而訂正失敗。由於絕大多數的數據都是在同步流程中同步完畢，走入到數據訂正的數據其實是少部分的，因此在這裡加分散式鎖其實是沒太大影響的。

ps：新老表的主鍵ID要保持一致。

整體流程圖

新表到老表增量同步

新表到老表也是一樣的操作，無非就是雙方角色互換下。新系統DML操作後，同步到老表，具體的同步邏輯還是一樣的。

ps

我們都註意到，當老表同步到新表，新表同步完成後，新表也會吐出相應的 binlog，這時候客戶端監聽後如果按照上面的流程走下去，那麼會陷入一個死迴圈，無限消費，那麼客戶端怎麼監聽這部分數據並且拋棄掉呢。

我們可以在新老表加個flag欄位，所有業務dml操作將該欄位置為1，那麼數據同步客戶端監聽到binlog消息就進行數據同步。如果是數據同步的dml操作，將該欄位置為0，那麼數據同步客戶端監聽到binlog消息就直接拋棄掉即可。

存量同步

為了降低資料庫壓力，我們取存量數據是取的離線表，離線表具有延遲性，離線表存儲的一半是t-1天的數據。為了防止丟數據，我們會先將老到新的增量同步邏輯先上線一兩天，然後再從離線表取數，這樣所有的數據都不會丟。假如我們先同步存量數據，再同步增量數據，或者增量數據同步邏輯一上線立馬同步存量數據，那麼t-1到t這中間就會有1天的數據缺口。

存量同步如果insert失敗或者update失敗和增量同步的邏輯一樣，都會走數據訂正邏輯，保證數據的最終一致性。

優缺點

採用binlog同步的優點就是針對所有的dml操作集中處理，解耦業務、可發揮空間大；缺點就是需要中間件支持，並且具有一定的延遲性。

當我們老系統多張表，融合到新系統只有一張表；或者老系統一張表，拆到新系統多張表；那麼這種場景就很適合用這種方式來同步，只需要在數據同步邏輯根據關聯的欄位查出對應的信息進行insert或者update即可。

最後

同步的一定要做好監控！