一. 前言

　　上周小千在《記一次OOM問題的解決連載一 流式查詢》中寫到，我在“中通全球創(chuàng)研中心”的學(xué)生為了避免出現(xiàn)OOM問題，把一個(gè)站點(diǎn)一個(gè)月流水的數(shù)據(jù)，用Mybatis流式查詢的方式，把數(shù)據(jù)分批次讀進(jìn)內(nèi)存再寫到硬盤上。這樣處理之后確實(shí)在一定程度上減少了OOM發(fā)生的次數(shù)，但仍然會在月初各個(gè)站點(diǎn)，集中進(jìn)行上個(gè)月份月結(jié)報(bào)表時(shí)出現(xiàn)OOM的現(xiàn)象。

　　究其原因，月結(jié)報(bào)表的制作和上傳是一個(gè)很燒資源的過程，如果全國的中通站點(diǎn)都集中在月初時(shí)并發(fā)地制作月結(jié)報(bào)表，服務(wù)器根本承受不了這樣的壓力。

　　鑒于此，小千的這個(gè)學(xué)生打算利用Redisson分布式鎖結(jié)合信號量進(jìn)行限流。也就是根據(jù)服務(wù)器的實(shí)際承受能力，后臺允許同時(shí)制作10份月結(jié)報(bào)表。如果服務(wù)器正在同時(shí)制作10份月結(jié)報(bào)表，那么其他制作月結(jié)報(bào)表的請求只能排隊(duì)，直到有任務(wù)完成讓出一個(gè)信號量，才能處理一個(gè)新的請求。制作完成的月結(jié)報(bào)表會被上傳到文件服務(wù)器，后臺會通知前端客戶自行下載報(bào)表。

　　那么以上這個(gè)解決思路，到底該怎么實(shí)現(xiàn)呢？

　　二. 實(shí)現(xiàn)過程

　　2.1 實(shí)現(xiàn)原理

　　其實(shí)redisson分布鎖信號量的實(shí)現(xiàn)原理非常簡單，就是在redis中的一個(gè)整數(shù)，當(dāng)有制作報(bào)表的請求時(shí)，我們首先嘗試獲得一個(gè)信號量，如果能夠獲得(也就是信號量的整數(shù)大于0)就執(zhí)行制作報(bào)表的任務(wù)，然后讓信號量總數(shù)減1。制作報(bào)表的任務(wù)完成之后，再調(diào)用release()方法釋放一個(gè)信號量，信號總量+1。

　　2.2 核心代碼實(shí)現(xiàn)

　　接下來小千就把核心代碼給大家展示一下。我們先在redis中初始化一個(gè)信號量，并且設(shè)置為10個(gè)。

　　當(dāng)某個(gè)站點(diǎn)發(fā)出打印報(bào)表的請求時(shí)，先把任務(wù)記錄到數(shù)據(jù)庫中，并把任務(wù)的狀態(tài)設(shè)置為【等待中】。

　　當(dāng)流式查詢把所有的數(shù)據(jù)查出，并生成報(bào)表之后，我們應(yīng)該上傳報(bào)表到文件服務(wù)器，修改任務(wù)的狀態(tài)為【任務(wù)完成】，并釋放一個(gè)信號量出來。

　　三. 后話

　　為了解決此次OOM的問題，我們使用到了流式查詢分頁讀取數(shù)據(jù)，又使用到了分布式鎖的信號量限流，來限制同時(shí)執(zhí)行任務(wù)的個(gè)數(shù)。但小千的這個(gè)學(xué)生發(fā)現(xiàn)，大數(shù)據(jù)讀取、生成excel、文件上傳這些操作，每一個(gè)都非常耗時(shí)，為了不讓這三個(gè)操作彼此影響性能，最后還要使用MQ解耦，把這三個(gè)操作拆分成3個(gè)服務(wù)。至于結(jié)合MQ進(jìn)行具體解決的方案，小千會在以后的文章中繼續(xù)連載，請各位同學(xué)繼續(xù)關(guān)注哦。