一. 前言

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

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

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

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

　　二. 實現(xiàn)過程

　　2.1 實現(xiàn)原理

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

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

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

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

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

　　三. 后話

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