記錄一次千萬級别資料通過接口線上同步遷移的case
首先描述一下背景：
應大王要求，周邊各個寨子需要像大王統一彙聚本寨子已實名注冊使用者資質資料，雲南寨已注冊自然人使用者總數2800餘萬，陝西寨1500餘萬，皆需要通過線上接口同步至大王的平台，是的 你沒聽錯，總共4300多w的資料，都要通過接口的方式，單條單條的給大王懷裡塞。瘋了？不能通過庫對庫的方式推數嗎？是的，不能，因為不安全。ok，那讓我們先理下思路。
首先，肯定要通過多線程的方式編寫程式，不然單條單條同步的話，估計一個月都不用幹其他的事了，我倒是沒問題，上司能活劈了我。
好的，基于多線程，那麼我們繼續往下走
- 第一，要考慮到任務配置設定的問題，不同的節點各同步哪些資料
- 第二，要考慮到斷點續傳，誰也不能保證伺服器會不會開小差，傳了幾百萬，崩一下子就重新開始了？
- 第三，要考慮到異常暫停，失敗數量到了指定閥值就暫停程式，如果跟國辦之間沒商量好就開始傳，全部傳完了發現國辦那邊一條沒收着！掀桌ing，玩不起玩不起
- 第四，剩下的就是一些使程式更加人性化的功能，添加開關對整個程式的運作加已控制。添加時間控制器，指定每天開始同步的時間和結束同步的時間。添加異常分析日志。
ok，該考慮到的差不多都考慮到了，實際研發中肯定還有各種問題，go on！
包結構
流程圖
大概描述下上傳流程
代碼實作
知道了大概流程，那麼我們一起來分析實作
- 首先進入請求控制，確定目前節點上傳任務不會重複執行
- 然後打開監控，時間監控，開關監控，以及異常閥值監控
監控線程包括目前監控線程，以及主線程工具類，以及目前線程執行動作，該動作在初始化監控時指定為Consumer動作函數
打開監控
Consumer函數舉一個開關的例子吧
- 然後擷取到本節點開始上傳位置以及每批數量後，根據偏移量offset計算出目前節點上傳開始位置
開始上傳
這裡是真正的上傳動作
uploadHandler中包含目前批次的資訊，如下
- 上傳者根據目前批次資訊查到需要上傳的使用者資料後，交由傳輸者進行上傳
這裡是通過循環開始之前開始建立的多線程service來執行上傳的，upload是目前批次單條使用者資料的傳輸者，裡面包含使用者所有資質資訊
為了確定目前批次所有資料上傳完畢再進行下一個批次，這裡使用了一個閉鎖
同步完成後，注意把目前批次的上傳狀态同步到資料庫裡，每批次的上傳結果是放到一個線程安全的list中的（如下圖）,UploadResult儲存着本次上傳使用者的行号以及上傳狀态，在本批次批量同步到資料庫後進行clear清空操作，確定不會與下一批次同步狀态混淆。
uploader是一個用來執行上傳動作的線程，由于架構設計本工程不做網絡互動，是以将上傳動作放到另一個工程裡
另一個工程中就隻有上傳動作了，通過單例擷取上傳client
記得再client連接配接失敗時進行重試
- 然後等所有批次使用者都上傳完畢後，進行最後的收尾動作
收尾主要包括關閉上傳線程池，結束監控線程，重置上傳各項閥值
關閉監控
至此，代碼部分已經講解完畢。
上傳效率
有的同學就要講了，每個伺服器的性能不一樣，怎麼控制上傳的效率呢，效率太高伺服器撐不住，效率太低又跑的很慢。你且聽我慢慢道來
控制上傳的效率有兩個點
- 在打開監聽線程時會初始化本次上傳用到的線程池，這裡我用的是一個固定數量線程時，線程的數量存放再在庫中，根據top(linux)檢視伺服器性能，酌情配置
千萬級多線程接口同步 - 最重要的控制性能的辦法，是在目前批次真正開啟線程執行上傳的時候，通過sleep()适當的對cpu的時間片進行幹擾，設定正在（50-100）之前較為合理。這裡設定為-1就是不幹擾cpu時間片，此時伺服器如一頭兇猛的野獸，cpu飙升至100%，每分鐘上傳10w左右, 2000w資料3小時上傳完畢。
結語
以上就是本次千萬量級資料多線程接口上傳的全部内容，如果有不對的地方，還請大神指出，不勝感激。
天道酬勤