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

背景

在阿里巴巴內部“大中臺，小前臺”的組織和業務體制，使前線業務更加敏捷，賦能業務積極迎接未來挑戰和機遇，在阿里大中臺能力建設過程中，同質化中臺服務將會合並，小前臺需要遷移原來依賴的中臺服務到新的中臺服務上。閒魚作為小前臺，依賴阿里巴巴大中臺能力讓產品快速迭代，其中閒魚幣依賴的就是阿里巴巴積分中臺能力。在積分能力大中臺建設過程中，原有的積分服務都將合併到“半兩”積分平臺，閒魚幣原來依賴的積分平臺是"KingTower"積分平臺，目前"KingTower"即將下線，所以閒魚幣需要把資料和依賴的服務遷移到“半兩”積分平臺。

現狀

閒魚幣存量使用者過億，每日新增閒魚幣使用者萬級別，閒魚幣操作次數過億。

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

遷移方案

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

前期準備

平臺能力補齊

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

平臺介面補齊

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

業務介面改造

業務介面改造目的是相容新老服務介面，補齊新服務缺少的入參項，對齊新服務和老服務的出參，同時要注意的是新老服務對入參的檢測，防止可接受引數取值範圍不同，業務介面改造完成後，對呼叫該業務介面的整個業務鏈路進行改造和驗證，保證對原有的業務和產品邏輯不造成影響。在閒魚幣遷移的場景中，平臺能力對齊上，新老積分服務都提供了積分的查詢、增加、扣除的能力，但是老積分平臺在這些基礎上封裝了一些通用的玩法，在閒魚幣中使用了其提供的簽到能力，所以需要在業務層利用新平臺的積分增加能力，實現閒魚幣簽到能力。在平臺介面對齊上，雖然老服務和新服務入參的引數名不同，但老服務入參可以完全覆蓋新服務入參，但是差異點在老服務不接受使用者賬戶扣除到負數，但是新服務中支援。同時為了相容上層的業務，閒魚幣秦阿姨過程對兩個服務進行了封裝，保證上層業務無感知。

資料遷移

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

主動遷移

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

被動遷移

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

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

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

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

服務雙寫

雙寫新舊平臺

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

對賬服務

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

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

服務切換

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

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

總結

本文介紹了閒魚幣從老積分平臺遷移到新積分平臺整個過程，總結了基於服務的資料遷移方案，同時在介紹了閒魚幣遷移時候遇到的問題以及解決方案，整個遷移過程從方案制定到最終的遷移完成持續約一個月時間，最終在使用者沒有感知的情況下完成閒魚幣的遷移。

與資料庫遷移相比，從服務介面對資料遷移有如下優勢：

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

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

但是也有如下的不足：

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

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

無論是利用資料庫工具還是利用服務對資料進行遷移，目標都是一致的那就是資料無差異，使用者無感知，異常可監控，方案可回滾。

閒魚技術團隊不僅是阿里巴巴集團旗下閒置交易社群的創造者，更是移動與高併發大資料應用新技術的引導者與創新者。我們與Google Flutter/Dart小組密切合作，為社群貢獻了多個高star的專案和大量PR。我們正在積極探索深度學習和視覺技術在互動、交易、社群場景的創新應用。閒魚技術與集團中介軟體團隊共同打造的FaaS平臺每天支援數以千萬級使用者的高併發訪問場景。 

就是現在！客戶端／服務端java／架構／前端／質量工程師面向社會+校園招聘，base杭州阿里巴巴西溪園區，一起做有創想空間的社群產品、做深度頂級的開源專案，一起擴充技術邊界成就極致！