公司的核心業務合做夥伴淘寶網,最近出現泄漏用戶信息的現象,找了很久找不到根源,因而乎,淘寶那邊決定對全部敏感數據進行加密,從出口和入口都走密文,因而乎,咱們的工做量就來了。數據庫
咱們的一個底單數據庫,存儲了大量淘寶賣家和買家的訂單打印,申請單號,發貨,回收單號等等操做的日誌,大概有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億,來防止這個問題出現。blog
最後落實的遷移數據方案:因爲數據比較多,就算天天半夜12點之後大規模遷移,也不現實,應用服務器不可能同時更新,因此最後決定細水長流模式,以業務服務器和用戶爲外循環,來操做遷移,每臺業務服務器的用戶的用戶不規律的操做日誌數據存在不一樣的底單庫表中,也就是說一個老底單庫的51-148(咱們老底單庫分表分了148張)的表中可能都會有當前服務器用戶的數據,我以每一個表啓動一個線程來分別跑當前表的用戶數據,,寫的是每一個業務服務器,固定開98個線程,去跑不一樣的底單表用戶數據,跑了幾臺服務器後,發現個嚴重問題,因爲每用戶可跑的線程,也會循環查一次獨立庫的服務器,開2臺服務器同時跑數據,就會形成獨立庫服務器的CPU飆升到100%,計算加上各類延遲,也不可避免,還影響效率。因此,最後在當前業務服務器的站點啓動的時候,計算當前服務器的用戶具體分佈到哪幾張底單表中,而後就單獨開這幾個線程,極大的下降了獨立庫的數據庫壓力,改完以後,同時更新10臺服務器同時跑數據,毫無壓力,由於不少服務器的用戶數據分佈的底單表比較少,都是10之內張。這樣在獨立庫建立一個用戶狀態表,裏面字段:接口
再加一個字段host,當前用戶對應的應用服務器。事務
這樣,每臺應用服務器每一個線程的任務就是,不斷的取當前線程(表)的底單數據,我是每次取1000條,往新庫對應表裏經過事務導入,而且在狀態表記錄logid,當前1000條數據最小的id,下次循環,再查數據的時候只查比這個logid小的數據的1000條,這麼作的緣由是,防止中間程序未知問題掛掉,不知道從哪裏開始繼續導入,防止重複數據,當循環取當前用戶數據爲0的時候,跳出當前用戶的循環,更改狀態表的status爲1,線程休眠自定義時間,繼續下一個用戶。作好日誌記錄。思惟導圖就不畫了。
通過2周時間,用戶數據所有遷移完畢,過程也不是那麼一番順利,有個別用戶,出現問題,重新跑的數據。接下來開始數據加密了。
數據加密,由於還有一個純打印日誌表,這個表也須要進行加密,也就是1個用戶須要加密的是底單數據和打印日誌數據,爲了可讓全部服務器能夠同時更新加密數據,每臺服務器只開兩個線程,1個線程加密用戶底單數據,一個線程加密打印日誌數據。打印日誌表,跟每臺業務服務器數據庫放在一塊兒,,下圖是咱們公司對這幾個數據存儲的架構圖:
加密數據,老底單庫的前50張表也要加密。具體的代碼邏輯和遷移數據差很少,只是稍微複雜了一些流程而已。
最後落實的工具,導用戶到用戶遷移/加密狀態表頁面,用戶數據遷移/加密的監控頁面,業務數據庫鏈接層的擴展。
說實話,年後回來就搞這事情,我仍是處於過年的懵逼+放羊狀態,強行拉昇狀態作這些,好在目前數據所有成功遷移完成,數據庫底層擴展也完成,加密正在高速奔跑中,整個流程沒搞出大新聞,終於能夠鬆口氣了,第一次搞這麼大量的數據,值得記錄下來,留下回憶。。。。嗯嗯嗯。。