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

　　我們的一個底單數據庫，存儲了大量淘寶賣家和買家的訂單打印，申請單號，發貨，回收單號等等操作的日誌，大概有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張表也要加密。具體的代碼邏輯和遷移數據差不多，只是稍微復雜了一些流程而已。

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

isv大規模數據遷移和加密