今天群里有人問起，剛好做過相關的工作，特此分享一下當時的工作內容和感受。
背景
大概說一下這個事情的背景。在2013年大概4月份，人人網打算做一次大規模的數據遷移——評論服務。所謂評論就是指各種資源下的“評論文字”，比如照片的評論、Blog的評論、分享的評論、音樂的評論…… 早期人人網的各個開發小組各自為政，每個團隊幾乎都實現了一個評論服務，有各自不同的功能和數據結構，但是大體上還算相似。當時，業務部門希望能夠集中這些數據做一些統一的管理，比如權限管理（控制誰能看什么評論）、比如數據內容推薦（基于用戶評論人和評論的內容計算關系的緊密性等等）。而這一切的基礎是評論內容的基礎數據結構必須一致。
而同時，UGC這邊的評論內容（數據量最大的評論服務）之前使用Mongo DB開發，有很多維護上的問題。MongoDB雖然當時乘著NoSQL的東風呼風喚雨，但是據當時的維護同事講，維護負擔不小，不如MySQL穩定。而人人當時具有國內頂級的MySQL數據團隊（順便拜一下劉啟榮、周彥偉兩位大佬）。于是當時高層的意見是將整個服務遷移到MySQL架構下。
此外，架構組當時正在推行新一代的SOA架構，基于Thrift開發。需要一個服務作為“參考實現”，給整個公司的研發團隊做一個參照。
當時我剛剛工作2年半，進入人人的架構組不久。在做了一些“沒有什么人在意”的基礎架構后實在是有些無聊，就接了這個活。
問題規模
涉及到的團隊是13個。
涉及到的總數據量大約在10T的量級。
訪問的總量大概在10億PV/日（因為評論在首頁feed上就有）。
除了數據遷移，這個項目還需要解決
- 用新的SOA架構開發應用服務
- 重新設計一個全新的服務，大致可以照顧13個團隊的不同的評論服務的全部功能（比如點贊、回帖），重新設計評論的基礎服務
- 與13個團隊交涉、排期、聯測
- 需要與首頁Feed關聯，涉及到與C++互操作（因為Feed用C++，而其他組大多用Java）
- 整個開發期間不得中斷服務
- 大并發訪問量，所以要做嚴格的壓測
- 熱門主題的評論可能多大幾萬到十幾萬條，分頁、計數都不能用常規做法實現
限于主題，本文就不敘述這些設計和開發的細節，只說數據遷移本身。
數據遷移要考慮的問題
抱歉廢話了一番才說到重點。這里簡單列舉一些遷移時要考慮的問題。
平滑過渡
平滑過渡，即如何做到不同格式數據服務可以在用戶無感知的情況下做到平滑遷移。答案是雙寫和可控讀取路徑。當用戶寫入評論時，每個涉及的要做遷移的服務在保持寫自己的數據之外，都必須通過新版本的SOA客戶端訪問新的評論服務。
而雙寫一旦開始，我們就定義了數據遷移的時間范圍。即，只遷移雙寫之前的數據。注意一點，這里因為只是評論，所以少許的雙寫不一致（造成用戶評論丟失）是可以接受的。如果這里遷移的是交易記錄，就得保證絕對的一致性，那么必須額外開發WAL保證一致性。
而等到數據全部遷移完畢，通過線上配置中心的開關，統一切換評論的讀取路徑，全部落在新的服務上。這樣就徹底避免了用戶可見的問題。
海量數據設計
10T的數據不是小數目，是4～5年積攢下的數據量。對于新的評論系統，容量設計必須將容量設計為“3年內不需要擴容”的。所以設計的數據量大概是在30T左右。為此，我們設計了partition方案，實現了100個虛擬的分庫。這100各分庫被動態的分片在10 * 3臺主機上。如果未來性能無法撐住，可以增加更多的磁盤和更多的主機，最多可以達到100 * 3臺主機的容量。
所謂10 * 3個主機是指每組機器組成一個3節點的replica set互為備份。人人的數據組有非常強大的工具。在沒有percona等工具時，這些備份，熱切機制都是人人數據組自己開發的。同時，主從切換等機制對業務開發都是完全透明的（當然，代價就是業務代碼不可以有復雜SQL，都必須是簡單的單表SQL）。
partition采用雙重設計——主要的partition的id是評論的資源ID，比如一個照片的ID，一個Blog的ID等。因為80%的評論查詢都是查詢一個資源的評論列表。這樣partition的好處是使得這樣的查詢總是只會落到一個分片上。而部分業務提供了“一個用戶“的評論列表查詢。所以對于這樣的數據，就需要冗余一份數據重新做partition——按照”評論作者ID“進行分片。
上面說的這些其實跟數據遷移關系并不大，只不過在編寫遷移數據腳本時，必須考慮到這些地方，而非僅僅是簡單的往一個數據源里插入。
評論ID
原有的評論系統數據量有大有小。部分數據的ID簡單的用auto increment實現，部分系統則簡單的用uuid，而部分系統使用了全局序列產生器（使用Postgres sequence)。
為了保證新系統的效率，新系統采用snowflake算法來產生分布式ID，既保證新的數據的ID“大致有序”，有利于插入效率，又避免了因入中心化的ID產生機制。
出錯處理
這么浩大的開發過程，不出錯時完全不可能的。所以必須提前設計出錯時如何追蹤錯誤。而我們的處理是一定要把一條評論的新老兩個ID在新系統都要記錄下來。一旦發現數據有問題，可以立刻反查原始數據。
Emoji
新的評論服務支持emoji，對應于MySQL的utf8_mb4編碼。在數據遷移時必須留意這一點。當年的MySQL中utf8_mb4并不是默認編碼，必須經過配置和重啟才可以。這是個小坑，要留意。
限流
遷移說白了就是把老的數據讀出來，寫入到新的數據源。但對于訪問量極大的系統，絕對不能無節制的對數據進行讀寫。任何系統的帶寬都是有限的，磁盤的IO也是有限的，所以一定要限流。我們的遷移腳本在讀取和寫入數據時都都會監控所消耗的時間。如果超過閾值就開始短暫的等待。比如讀取100條數據花100ms以上，腳本機會停頓1s；如果超過200ms，腳本就會停頓5s。超過一定閾值，腳本會發郵件通知我：“遷移暫時中斷，需要人工重啟”等等。
這樣的限流腳本，一旦開啟后，大部分時間我就不用盯著，不用操心生產系統被壓垮。只用每天花點時間看看進度就行了。
進度控制
我們在遷移的第一周大概估算了大概的遷移速度。然后讓遷移腳本每隔一定的進度就將當前的已遷移數據比例記錄在一個數據表里。因為做的比較糙，所以沒有開發UI，而僅僅是做了個小腳本每天發送進度郵件給相關人員。如果有任何異常，都可以引起我們的警覺。因為這個工具我們還發現了幾個組的程序的bug……
遷移冪等
遷移腳本會出錯，而遷移本身是并不是原子的——因為業務的復雜性，我們無法用transaction。所以，我們的遷移必須是冪等的。我們利用了原始數據的服務名稱+ID作為冪等key（比如PHOTO:12345)，以及INSERT IGNORE INTO，配合進度控制可以實現簡單的重啟數據遷移。這樣即便遷移腳本被強行的kill掉，同時又沒有記錄下精確的動作。我也可以放心大膽的隨意重啟它。
如果原來的評論數據變了……
盡管理論上評論時不會變的，但是有些業務的評論的確可以編輯（盡管數量很小）。這樣在遷移過程中，我們不得不考慮怎么去重新同步這些變化。我用了最簡單的辦法，對每條記錄的updated_at做索引和排序。感謝公司良好的數據表設計規范，每個表都有created_at和updated_at(或者created_on和updated_on，大家英文不統一，但只要有就足夠了）。一旦發現新的數據變更，就排在一個隊列里進行特別的同步。這解決了絕大部分的問題。還是那句話，好在是評論，不需要特別嚴格一致，所以就算是丟了那么幾條的改動，也是可以接受的。
激勵和進度管理
這個其實是整個項目里最難的。因為我是一個普通的研發。雖然我來自架構組，但是這并不代表別的組的人會按我所得做。每個組都有自己的KPI，有自己的排期和優先級。我想把我的工作目標插入到他們的安排中，真是各種招都用了。有的普及技術、有的找項目負責人談合作、還有的直接吃飯KTV。但不論如何，在相對短的時間內，這項工作真真切切的落實了。現在想想覺得還是很NB。
另外這么多事情，包括數據設計、功能開發、聯測、壓測、不同組的溝通排期、數據遷移、切換開關在13個組里進行。現在想想，目前的項目管理和文檔能力都是在那時候鍛煉成的。
最后
經過2個半月的遷移和開發，這個事情終于告一段落。業務的頭頭們得到了統一的評論數據，用戶沒有罵娘，架構組的SOA基礎框架也有了第一個使用樣板（其實我被坑了好幾次，所以架構組也沒少請我吃飯撫慰我的心靈）。通過這個過程也得到了一幫好哥們，和第一次季度S績效（后邊還順便升了個title，但是沒過多久就離開了人人）。我很感謝這個經歷和幫助我的團隊。
收一收，通過這件事情總結一下關于數據遷移的重點：
- 精心的進度管理和控制
- 開發“低心智負擔”的工具
- 平滑過渡，讓用戶開心和滿意
最后說一句：做業務真心容易出績效啊！
