isv大規模數據遷移和加密

公司的核心業務合作伙伴淘寶網，最近出現泄漏用戶信息的現象，找了好久找不到根源，於是乎，淘寶那邊決定對所有敏感數據進行加密，從出口和入口都走密文，於是乎，我們的工作量就來了。

　　我們的一個底單資料庫，存儲了大量淘寶賣家和買家的訂單列印，申請單號，發貨，回收單號等等操作的日誌，大概有10億左右數據(自動刪除2個月之前的數據),哎呦我的fuck啊，也就是說，我們這邊要對10億數據做加密處理。。。。。。。。。

　　很榮幸，整個數據的操作過程由我來寫工具，其中的考慮和過程，我來這裡大致的記錄一下，以便留下深的記憶。

　　好吧，先上一張我們用戶與底單庫的數據架構圖。

圖上，我大致說一下，我們這一個獨立庫存儲用戶的獨立信息，有一張總用戶表，用戶id/5000取int值，也就是5000個用戶的底單數據插入到底單庫中對應的一張表中。

　　底單庫的伺服器是阿裡聚石塔最高級別的專用資料庫伺服器，容量2T，由於表的欄位很多，數據占用磁碟空間的限制，我們保存用戶2個月的數據，勉強維持2T的數據容量，但是，表中的例如用戶手機，收件人，買家旺旺等欄位需要加密，加密都是走阿裡提供的加密解密介面方式，本來一個欄位就20個字元最多，加密後就要200以內字元，這樣不用全部加密硬碟空間就沒了，經過討論，確定方案是，加資料庫，增加兩台新的底單庫，存儲邏輯下圖：

上圖顯示，加了新庫，所以，在加密之前，首先要遷移用戶數據。

　　要把底單1庫（老庫）中的51-100的表數據遷移到底單2庫，101以上的表數據遷移到底單3庫。為了保存老數據，底單2和3庫新建的表要分別是51-100,101+，這裡註意一點，新庫的新表的起始自增id千萬不要從0開始，因為，當你開始遷移數據的時候，對應的應用伺服器一定會更新程式，這時候51表以上的用戶的數據不會再往老庫插，而是對應的入到新庫裡面，由於要把老庫數據遷移過來，如果自增id從0開始，就會導致新數據的id和老數據的id產生唯一約束衝突。所以，看了下所有的舊表數據最大自增id,最多的在8000多W，所以，再程式上線前，我們給新表的自增id設置成1億，來防止這個問題出現。

　　最後落實的遷移數據方案:由於數據比較多，就算每天半夜12點以後大規模遷移，也不現實，應用伺服器不可能同時更新，所以最後決定細水長流模式，以業務伺服器和用戶為外迴圈，來操作遷移，每台業務伺服器的用戶的用戶不規律的操作日誌數據存在不同的底單庫表中，也就是說一個老底單庫的51-148（我們老底單庫分表分了148張）的表中可能都會有當前伺服器用戶的數據，我以每個表啟動一個線程來分別跑當前表的用戶數據，，寫的是每個業務伺服器，固定開98個線程，去跑不同的底單表用戶數據，跑了幾台伺服器後，發現個嚴重問題，由於每用戶可跑的線程，也會迴圈查一次獨立庫的伺服器，開2台伺服器同時跑數據，就會造成獨立庫伺服器的CPU飆升到100%，計算加上各種延遲，也不可避免，還影響效率。所以，最後在當前業務伺服器的站點啟動的時候，計算當前伺服器的用戶具體分佈到哪幾張底單表中，然後就單獨開這幾個線程，極大的降低了獨立庫的資料庫壓力，改完之後，同時更新10台伺服器同時跑數據，毫無壓力，因為很多伺服器的用戶數據分佈的底單表比較少，都是10以內張。這樣在獨立庫創建一個用戶狀態表，裡面欄位：

再加一個欄位host,當前用戶對應的應用伺服器。

這樣，每台應用伺服器每個線程的任務就是，不斷的取當前線程（表）的底單數據，我是每次取1000條，往新庫對應表裡通過事務導入，並且在狀態表記錄logid,當前1000條數據最小的id,下次迴圈，再查數據的時候只查比這個logid小的數據的1000條，這麼做的原因是，防止中間程式未知問題掛掉，不知道從哪裡開始繼續導入，防止重覆數據，當迴圈取當前用戶數據為0的時候，跳出當前用戶的迴圈，更改狀態表的status為1，線程休眠自定義時間，繼續下一個用戶。做好日誌記錄。思維導圖就不畫了。

　　經過2周時間，用戶數據全部遷移完畢，過程也不是那麼一番順利，有個別用戶，出現問題，從新跑的數據。接下來開始數據加密了。

　　數據加密，因為還有一個純列印日誌表，這個表也需要進行加密，也就是1個用戶需要加密的是底單數據和列印日誌數據，為了可以讓所有伺服器可以同時更新加密數據，每台伺服器只開兩個線程，1個線程加密用戶底單數據，一個線程加密列印日誌數據。列印日誌表，跟每台業務伺服器資料庫放在一起，，下圖是我們公司對這幾個數據存儲的架構圖：

加密數據，老底單庫的前50張表也要加密。具體的代碼邏輯和遷移數據差不多，只是稍微複雜了一些流程而已。

　　最後落實的工具，導用戶到用戶遷移/加密狀態表頁面,用戶數據遷移/加密的監控頁面，業務資料庫連接層的擴展。