關於億級賬戶資料遷移，你應該試試這種方法...

一般資料遷移是透過資料庫相關工具進行操作，具體可以參考《21世紀了還愚公移山？資料庫這麼遷移更快！》。但閒魚幣資料遷移卻不同，首先“KingTower”平臺的資料結構和“半兩”平臺的資料結構不同；其次出於對資料安全和穩定性的考慮，兩個積分平臺只對外提供服務介面，不允許業務方直接操作平臺資料庫。這就意味著閒魚幣遷移無法利用資料庫工具，只能透過兩個平臺提供的服務介面完成遷移工作。本文將結合閒魚幣遷移過程，提供一種基於服務介面的資料遷移方案，在使用者無感知的情況下完成遷移目標。

主動遷移和被動遷移最終目的都是把使用者資料從老積分賬戶資料遷移到新積分上，兩種方式各有自己的應用場景，主動遷移主要適用於遷移活躍使用者和新增使用者，被動遷移主要適用於遷移存量使用者。兩種遷移遇到的技術難點是一樣的。第一併發處理，在上面兩種方案只展示了遷移過程中要獲取全域性分散式鎖，對於未遷移的使用者在進行加減操作時候同樣也要獲取全域性鎖，具體如下圖所示，這樣才能保證遷移過程中不產生髒資料，本文中的全域性鎖使用的是Redis實現，這裡不再贅述。

第二操作事務性，本文的遷移方案中只有當寫入遷移完成標記才算是遷移成功，在這一步前的其他每一步都有可能由於RPC呼叫產系統異常或超時錯誤，所以為了保證操作事務性，對於任何一步出錯本次遷移都算失敗，失敗的使用者將會進行下面的遷移重試流程。

切換過程採用逐步放量的形式，灰度方式很多我們採用的是先白名單驗證，然後使用者ID取模1000逐步放量的方式。值得注意的一點是讀灰度和灰度要分開進行，當對賬沒有問題的時候就可以開啟讀灰度了，在讀灰度過程中仍舊保持雙寫，此時如果讀灰度發現問題，仍舊可以回滾會老的服務。但是單寫新服務開始後就無法進行回滾，所以在寫灰度前需要充分白名單驗證。

• 無需關心底層資料儲存，只需做好上層業務邏輯相容即可。

• 遷移過程可控，透過多維度的遷移監控及早發現問題。

• 遷移過程受到服務方QPS限制，遷移週期長

• 遷移過程都是RPC呼叫，需要處理多種異常情況。