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