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

作者：閑魚技術-齊悟

背景

在阿裡巴巴内部“大中台，小前台”的組織和業務體制，使前線業務更加靈活，賦能業務積極迎接未來挑戰和機遇，在阿裡大中台能力建設過程中，同質化中台服務将會合并，小前台需要遷移原來依賴的中台服務到新的中台服務上。閑魚作為小前台，依賴阿裡巴巴大中台能力讓産品快速疊代，其中閑魚币依賴的就是阿裡巴巴積分中台能力。在積分能力大中台建設過程中，原有的積分服務都将合并到“半兩”積分平台，閑魚币原來依賴的積分平台是"KingTower"積分平台，目前"KingTower"即将下線，是以閑魚币需要把資料和依賴的服務遷移到“半兩”積分平台。

現狀

閑魚币存量使用者過億，每日新增閑魚币使用者萬級别，閑魚币操作次數過億。

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

遷移方案

遷移方案主要分為四個步驟，如下圖所示，第一步是前期準備，第二步是資料遷移，第三步是服務雙寫，第四步服務切換，下面将結合閑魚币的遷移詳細介紹這四個步驟：

第一步 前期準備

1.平台能力對齊

新舊平台能力對齊是進行遷移的大前提，如果新的平台能力無法覆寫老的平台的能力，那麼需要做的是1.推動新平台提供老平台已有的能力。2.業務方利用新平台提供的已有能力，從業務層實作老平台特有的能力。

2.平台接口對齊

新舊平台接口在出參和入參上會存在一定的差異，差異點尋找具體的操作如下：1.首先列出在使用的老服務接口入參和出參；2.在新服務中找到對應功能的接口，同樣列出入參和出參的含義以及資料類型；3.對齊相同含義的參數，并梳理出新接口需要補齊的參數。梳理出接口的差異後需要由業務方補齊兩個接口的差異，也就是接下來的業務接口改造。

3.業務接口改造

業務接口改造目的是相容新老服務接口，補齊新服務缺少的入參項，對齊新服務和老服務的出參，同時要注意的是新老服務對入參的檢測，防止可接受參數取值範圍不同，業務接口改造完成後，對調用該業務接口的整個業務鍊路進行改造和驗證，保證對原有的業務和産品邏輯不造成影響。

在閑魚币遷移的場景中，平台能力對齊上，新老積分服務都提供了積分的查詢、增加、扣除的能力，但是老積分平台在這些基礎上封裝了一些通用的玩法，在閑魚币中使用了其提供的簽到能力，是以需要在業務層利用新平台的積分增加能力，實作閑魚币簽到能力。在平台接口對齊上，雖然老服務和新服務入參的參數名不同，但老服務入參可以完全覆寫新服務入參，但是差異點在老服務不接受使用者賬戶扣除到負數，但是新服務中支援。同時為了相容上層的業務，閑魚币秦阿姨過程對兩個服務進行了封裝，保證上層業務無感覺。

第二步 資料遷移

在遷移過程中，分為兩種情況一種是使用者觸發式遷移稱為主動遷移，一種是由系統發起的遷移稱為被動遷移，兩種遷移方式對于使用者來講都是無感覺遷移，具體資料遷移方案如下所示。

1.主動遷移

主動遷移是由使用者觸發，當使用者進行積分增減操作的時候，将先觸發遷移流程，首先使用者讀取遷移标志，如果完成遷移則無需再次遷移；然後擷取全局積分增減操作鎖，目的是防止在遷移過程中有其他增減操作造成資料不一緻；接着讀取老積分，并把讀取的積分寫入到新積分服務，然後遷移完成的标志位，至此一個使用者的賬戶遷移完成；最後釋放全局鎖。

2.被動遷移

被動遷移是由系統觸發，系統首先計算出需要遷移的使用者清單，同時利用分布式任務系統把需要遷移的使用者分發到各個機器上，後續遷移流程與使用者主動遷移一樣，讀取遷移辨別、擷取全局鎖、讀舊寫新、寫入遷移辨別、釋放鎖，完成整個遷移過程。

主動遷移和被動遷移最終目的都是把使用者資料從老積分賬戶資料遷移到新積分上，兩種方式各有自己的應用場景，主動遷移主要适用于遷移活躍使用者和新增使用者，被動遷移主要适用于遷移存量使用者。兩種遷移遇到的技術難點是一樣的。

第一并發處理，在上面兩種方案隻展示了遷移過程中要擷取全局分布式鎖，對于未遷移的使用者在進行加減操作時候同樣也要擷取全局鎖，具體如下圖所示，這樣才能保證遷移過程中不産生髒資料，本文中的全局鎖使用的是Redis實作，這裡不再贅述。

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

在閑魚币遷移過程中采用了被動遷移和主動遷移兩種方式，被動遷移用來解決遷移存量使用者，主動遷移用來解決遷移新增使用者，在被動遷移過程中通過控制計算離線人群來實作逐漸遷移，在主動遷移過程中通過白名單和控制使用者尾号逐漸放量的方式控制遷移過程，逐漸放量可以保證遷移出現的問題早發現早解決。

第三步 服務雙寫

1.雙寫新舊平台

當使用者資料遷移完成後，需要即刻對新老服務進行雙寫，雙寫邏輯如下圖所示，首先驗證使用者是否已是遷移的使用者，如果是遷移的使用者，那麼先寫老積分，寫老積分成功後寫新積分，完成雙寫邏輯。在雙寫過程中為了防止寫老服務寫入成功傳回逾時和寫新積分失敗的情況，在老積分服務中定制了異步邏輯，即老積分系統中在使用者操作積分加減成功後會發出成功的消息，消息中會有幂等Key，業務方接收到消息後，根據幂等Key判斷新積分服務中是否已對該Key進行過相關操作，如果沒有操作過那麼将會在新積分服務中操作，實作資料的最終一緻性

2.對賬服務

對賬是遷移的重要一步，通過對賬可以驗證出遷移資料在新老平台上是否一緻，對賬流程如下圖所示，通過定時任務輪詢執行已經完成遷移的使用者在新老平台的資料一緻性。需要注意的是由于讀取新老平台有先後順序，是以産生瞬時的資料不一緻，對于這種問題可以采用對賬重試，隻要保證最終一緻即可。

閑魚币遷移過程中資料遷移和雙寫是同步進行的，遷移成功的标志也是開始雙寫的标志，按照正常的業務邏輯在對賬環節不會出現大面積對賬不一緻情況，如果出現大面積對賬不一緻并且對賬重試後無法解決，那麼就是在資料遷移和雙寫的過程出現了問題，此時需要停止遷移排查問題，同時整個遷移過程提供了可復原能力能力，閑魚币遷移中的遷移标志和新積分平台資料都是可以進行重置的，重置後即可從頭開始二次遷移，不會對使用者造成影響。

第四步 服務切換

完成以上三個步驟基本完成了資料的遷移工作，下面要做的就是停掉老服務，切換到新的服務上去。具體方式如下圖所示：

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

總結

本文介紹了閑魚币從老積分平台遷移到新積分平台整個過程，總結了基于服務的資料遷移方案，同時在介紹了閑魚币遷移時候遇到的問題以及解決方案，整個遷移過程從方案制定到最終的遷移完成持續約一個月時間，最終在使用者沒有感覺的情況下完成閑魚币的遷移。與資料庫遷移相比，從服務接口對資料遷移有如下優勢：1.無需關心底層資料存儲，隻需做好上層業務邏輯相容即可。2.遷移過程可控，通過多元度的遷移監控及早發現問題。但是也有如下的不足：1.遷移過程受到服務方QPS限制，遷移周期長 2.遷移過程都是RPC調用，需要處理多種異常情況。無論是利用資料庫工具還是利用服務對資料進行遷移，目标都是一緻的那就是資料無差異，使用者無感覺，異常可監控，方案可復原。