一. 問題概述
老師的一個學生入職了杭州中通全球創研中心，最近他給老師分享一個他們公司解決OOM問題的案例，老師覺得十分有趣，特意把這個案例記錄下來，日后我會做成教學案例分享給學生。這個問題發生的背景如下：
【在物流領域，針對各個下級網點而言，每月1日～9日是進行財務月結的重要時間節點。在這個關鍵節點上，各個網點需要使用導出功能輸出寄派件、費用客戶信息等多種信息進行匯總結算】。也就是說，在月初的時候，每個網點都要統計一個月的各種流水(寄件，收件等)，最后再以excel表格的形式下載給客戶。
那么在這個業務中為什么很容易發生OOM異常呢?這是因為平均1個網點1個月的流水數據大約在30w行左右，根據計算得出大約500行數據就會占用1M內存，而1個站點把30萬行一股腦地讀到內存中，就會占用600M內存。試想一下，如果全國的網點都在月初集中下載報表的話，JVM是很容出現內存溢出的問題的!
二. 解決方案
那么這樣一個棘手的問題，如果我們只用一個單一的解決方案是不夠的，老師根據學生的描述，建議該學生主要采取以下幾種解決方案。
2.1 用硬盤空間置換內存空間
如果我們在接到統計數據請求的時候，一次性把30w條數據從數據庫讀取到一個List集合中，這顯然是不合理的，因為這樣一個List集合就會占用600M內存。所以我們可以進行分頁查詢，每次查詢1000條數據，然后往硬盤里寫，多讀取幾次，一點一點的把所有的數據都讀出來，再一點一點的往硬盤中寫。這樣在這個過程中，占用的內存就會少很多，主要變成了對硬盤空間的占用。而我們操作excel的技術，可以選擇阿里巴巴的easyexcel。
2.2 使用Mybatis的流式查詢
我們可以使用Mybatis的【流式查詢】查詢技術，在查詢成功后返回的是一個迭代器而不是一個集合，應用每次都從迭代器中獲取一條查詢結果，能夠降低內存的使用。試想一下，如果我們不使用流式查詢，而想要一次性從數據庫中讀取30萬條數據，內存是根本不夠用的!這時我們只能選擇分頁查詢，而分頁查詢的性能又取決于表設計以及索引的設計，大量數據分頁查詢的性能是很低的。老師對比了使用流式查詢和分頁查詢的兩種方案，得到的結論是取30萬條數據時，流式查詢的速度大約是分頁查詢的4~5倍左右。
2.3 使用redission信號量限流
生成一個月的流水報表是一個非常耗時的操作，用戶也不可能馬上就要結果，所以我這個學生的公司對同時生成報表的請求數量做了限制，同時只能處理10個報表的生成。在這期間如果再有生成報表的請求，我們將會讓這些請求排隊，等到前面的報表生成完畢后，再處理后面的請求。報表生成成功后，再通知客戶主動去下載，老師建議這里使用redisson分布式鎖的信號量來限制同時創建報表的線程數量。
2.4 MQ解耦+微服務拆分
本次業務中，讀數據庫，編寫excel文件，上傳到文件服務器這三個操作都非常耗時，學生的公司使用了MQ解耦，并把這次請求拆分成3個微服務，這樣讀、寫、上傳就不會相互影響了。
三. 流式查詢
在這篇文章中，老師只給大家分享一下Mybatis流式查詢的實現方法，其他的解決方案以后會在其他的文章中給大家呈現。
3.1 概念
流式查詢就是查詢成功后返回的是一個迭代器而不是一個集合，應用每次都從迭代器中獲取一條查詢結果，這樣能夠降低內存的使用。
3.2 Mybatis實現流式查詢
接下來就是實現流失查詢的具體過程。
在mapper映射文件中，編寫流式查詢的邏輯。
<!--
1: fetchSize： 官方文檔建議設置成Integer.MIN_VALUE
2: resultSetType="FORWARD_ONLY" 返回一個只向前的游標
3：注意我把表一次性查出，并沒有使用分頁邏輯，依靠流式查詢一行一行得到結果
-->
<select id="selectFetchSize" fetchSize="-2147483648" resultSetType="FORWARD_ONLY" resultType="com.qf.shop.cms.entity.TContent">
select * from t_content
</select>
在mapper接口文件中添加selectFetchSize方法。
// 參數 ResultHandler 是一個回調接口，也就是從游標中獲得一條數據就會回調接口中的方法
void selectFetchSize(ResultHandlerhandler);
自己編寫一個類實現ResultHandler接口，在該接口中定義從游標獲得一條數據后的回調邏輯。
/**
* 通過流式查詢每獲得一條數據的回調類
*/
public class TContentResultHandler implements ResultHandler{
/**
* 這里每集滿1000條數據 往硬盤的excel文件中追加一次數據
*/
private final static int BATCH_SIZE = 1000;
/**
* 計數器
*/
private int size=0;
/**
* 存儲每批數據的臨時容器
*/
private ListtContents = new ArrayList<>();
/**
* 每從流式查詢中獲得一行結果，就會調用一次這個方法
* @param resultContext
*/
@Override
public void handleResult(ResultContext resultContext){
// 這里獲取流式查詢每次返回的單條結果
TContent resultObject = resultContext.getResultObject();
// 你可以看自己的項目需要分批進行處理或者單個處理，這里以分批處理為例
tContents.add(resultObject);
size++;
if (size == BATCH_SIZE) {
// 如果集滿1000條就往文件中寫一次
handle();
}
}
/**
* 集滿1000條 執行一次的邏輯
*/
private void handle() {
try {
// 在這里可以對你獲取到的批量結果數據進行需要的業務處理
// 這里的業務是 往文件中寫一次
} finally {
// 處理完每批數據后后將臨時清空
size = 0;
tContents.clear();
}
}
/**
* 這個方法給外面調用，用來完成最后一批數據處理
*/
public void end(){
handle();// 處理最后一批不到BATCH_SIZE的數據
}
}
在業務邏輯(service)層調用流式查詢方法。
@Autowired
private TContentMapper contentMapper;
public void streamQuery(){
// 生成流式查詢的回調對象
TContentResultHandler tContentResultHandler = new TContentResultHandler();
// 調用流式查詢
contentMapper.selectFetchSize(tContentResultHandler);
// 執行完最后一批數據的邏輯
tContentResultHandler.end();
}
四. 后話
老師前面已經說到，為了解決本次產生的OOM問題，老師給大家列舉了非常多的解決方案，但本篇文章介紹的流式查詢只是其中的方案之一。至于其他的解決方案，老師將在后續的文章中為大家一一揭曉，敬請各位繼續關注本公眾號，如有問題，可以在評論區給我們留言哦。
京公網安備 11010802030320號