背景
最近有個學弟找到我,跟我描述了以下場景:
他們公司內部管理系統上有很多報表,報表數據都有分頁顯示,瀏覽的時候速度還可以。但是每個報表在導出時間窗口稍微大一點的數據時,就異常緩慢,有時候多人一起導出時還會出現堆溢出。
他知道是因為數據全部加載到jvm內存導致的堆溢出。所以只能對時間窗口做了限制。以避免因導出過數據過大而引起的堆溢出。最終拍腦袋定下個限制為:導出的數據時間窗口不能超過1個月。
雖然問題解決了,但是運營小姐姐不開心了,跑過來和學弟說,我要導出一年的數據,難道要我導出12次再手工合並起來嗎。學弟心想,這也是。系統是為人服務的,不能為了解決問題而改變其本質。
所以他想問我的問題是:有沒有什么辦法可以從根本上解決這個問題。
所謂從根本上解決這個問題,他提出要達成2個條件
- 比較快的導出速度
- 多人能並行下載數據集較大的數據
我聽完他的問題后,我想,他的這個問題估計很多其他童鞋在做web頁導出數據的時候也肯定碰到過。很多人為了保持系統的穩定性,一般在導出數據時都對導出條數或者時間窗口作了限制。但需求方肯定更希望一次性導出任意條件的數據集。
魚和熊掌能否兼得?
答案是可以的。
我堅定的和學弟說,大概7年前我做過一個下載中心的方案,20w數據的導出大概4秒吧。。。支持多人同時在線導出。。。
學弟聽完表情有些興奮,但是眉頭又一皺,說,能有這么快,20w數據4秒?
為了給他做例子,我翻出了7年前的代碼。。。花了一個晚上把核心代碼抽出來,剝離干凈,做成了一個下載中心的例子
超快下載方案演示
先不談技術,先看效果,(完整案例代碼文末提供)
數據庫為mysql(理論上此套方案支持任何結構化數據庫),准備一張測試表t_person
。表結構如下:
CREATE TABLE `t_person` (
`id` bigint(20) NOT NULL auto_increment,
`name` varchar(20) default NULL,
`age` int(11) default NULL,
`address` varchar(50) default NULL,
`mobile` varchar(20) default NULL,
`email` varchar(50) default NULL,
`company` varchar(50) default NULL,
`title` varchar(50) default NULL,
`create_time` datetime default NULL,
PRIMARY KEY (`id`)
);
一共9個字段。我們先創建測試數據。
案例代碼提供了一個簡單的頁面,點以下按鈕一次性可以創建5w條測試數據:
這里我連續點了4下,很快就生成了20w條數據,這里為了展示下數據的大致樣子,我直接跳轉到了最后一頁
然后點開下載大容量文件
,點擊執行執行按鈕,開始下載t_person
這張表里的全部數據
點擊執行按鈕之后,點下方刷新按鈕,可以看到一條異步下載記錄,狀態是P
,表示pending
狀態,不停刷新刷新按鈕,大概幾秒后,這一條記錄就變成S
狀態了,表示Success
然后你就可以下載到本地,文件大小大概31M左右
看到這里,很多童鞋要疑惑了,這下載下來是csv?csv其實是文本文件,用excel打開會丟失格式和精度。這解決不了問題啊,我們要excel格式啊!!
其實稍微會一點excel技巧的童鞋,可以利用excel導入數據這個功能,數據->導入數據,根據提示一步步,當中只要選擇逗號分隔就可以了,關鍵列可以定義格式,10秒就能完成數據的導入
你只要告訴運營小姐姐,根據這個步驟來完成excel的導入就可以了。而且下載過的文件,還可以反復下。
是不是從本質上解決了下載大容量數據集的問題?
原理和核心代碼
學弟聽到這里,很興奮的說,這套方案能解決我這里的痛點。快和我說說原理。
其實這套方案核心很簡單,只源於一個知識點,活用JdbcTemplate
的這個接口:
@Override
public void query(String sql, @Nullable Object[] args, RowCallbackHandler rch) throws DataAccessException {
query(sql, newArgPreparedStatementSetter(args), rch);
}
sql就是select * from t_person
,RowCallbackHandler
這個回調接口是指每一條數據遍歷后要執行的回調函數。現在貼出我自己的RowCallbackHandler
的實現
private class CsvRowCallbackHandler implements RowCallbackHandler{
private PrintWriter pw;
public CsvRowCallbackHandler(PrintWriter pw){
this.pw = pw;
}
public void processRow(ResultSet rs) throws SQLException {
if (rs.isFirst()){
rs.setFetchSize(500);
for (int i = 0; i < rs.getMetaData().getColumnCount(); i++){
if (i == rs.getMetaData().getColumnCount() - 1){
this.writeToFile(pw, rs.getMetaData().getColumnName(i+1), true);
}else{
this.writeToFile(pw, rs.getMetaData().getColumnName(i+1), false);
}
}
}else{
for (int i = 0; i < rs.getMetaData().getColumnCount(); i++){
if (i == rs.getMetaData().getColumnCount() - 1){
this.writeToFile(pw, rs.getObject(i+1), true);
}else{
this.writeToFile(pw, rs.getObject(i+1), false);
}
}
}
pw.println();
}
private void writeToFile(PrintWriter pw, Object valueObj, boolean isLineEnd){
...
}
}
這個CsvRowCallbackHandler
做的事就是每次從數據庫取出500條,然后寫入服務器上的本地文件中,這樣,無論你這條sql查出來是20w條還是100w條,內存理論上只占用500條數據的存儲空間。等文件寫完了,我們要做的,只是從服務器把這個生成好的文件download到本地就可以了。
因為內存中不斷刷新的只有500條數據的容量,所以,即便多線程下載的環境下。內存也不會因此而溢出。這樣,完美解決了多人下載的場景。
當然,太多並行下載雖然不會對內存造成溢出,但是會大量占用IO資源。為此,我們還是要控制下多線程並行的數量,可以用線程池來提交作業
ExecutorService threadPool = Executors.newFixedThreadPool(5);
threadPool.submit(new Thread(){
@Override
public void run() {
下載大數據集代碼
}
}
最后測試了下50w這樣子的person數據的下載,大概耗時9秒,100w的person數據,耗時19秒。這樣子的下載效率,應該可以滿足大部分公司的報表導出需求吧。
最后
學弟拿到我的示例代碼后,經過一個禮拜的修改后,上線了頁面導出的新版本,所有的報表提交異步作業,大家統一到下載中心去進行查看和下載文件。完美的解決了之前的2個痛點。
但最后學弟還有個疑問,為什么不可以直接生成excel呢。也就是說在在RowCallbackHandler
中持續往excel里寫入數據呢?
我的回答是:
1.文本文件流寫入比較快
2.excel文件格式好像不支持流持續寫入,反正我是沒有試成功過。
我把剝離出來的案例整理了下,無償提供給大家,希望幫助到碰到類似場景的童鞋們。
關注作者
關注公眾號「元人部落」回復”導出案例“即可獲得以上完整的案例代碼,直接可以運行起來,頁面上輸入http://127.0.0.1:8080就可以打開文中案例的模擬頁面。