一. 前言

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

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

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

　　那么以上這個解決思路，到底該怎么實現呢？

　　二. 實現過程

　　2.1 實現原理

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

　　2.2 核心代碼實現

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

　　當某個站點發出打印報表的請求時，先把任務記錄到數據庫中，并把任務的狀態設置為【等待中】。

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

　　三. 后話

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