一. 前言
上周小千在《記一次OOM問題的解決連載一 流式查詢》中寫到，我在“中通全球創(chuàng)研中心”的學生為了避免出現(xiàn)OOM問題，把一個站點一個月流水的數(shù)據(jù)，用Mybatis流式查詢的方式，把數(shù)據(jù)分批次讀進內(nèi)存再寫到硬盤上。這樣處理之后確實在一定程度上減少了OOM發(fā)生的次數(shù)，但仍然會在月初各個站點，集中進行上個月份月結(jié)報表時出現(xiàn)OOM的現(xiàn)象。
究其原因，月結(jié)報表的制作和上傳是一個很燒資源的過程，如果全國的中通站點都集中在月初時并發(fā)地制作月結(jié)報表，服務(wù)器根本承受不了這樣的壓力。
鑒于此，小千的這個學生打算利用Redisson分布式鎖結(jié)合信號量進行限流。也就是根據(jù)服務(wù)器的實際承受能力，后臺允許同時制作10份月結(jié)報表。如果服務(wù)器正在同時制作10份月結(jié)報表，那么其他制作月結(jié)報表的請求只能排隊，直到有任務(wù)完成讓出一個信號量，才能處理一個新的請求。制作完成的月結(jié)報表會被上傳到文件服務(wù)器，后臺會通知前端客戶自行下載報表。
那么以上這個解決思路，到底該怎么實現(xiàn)呢？
二. 實現(xiàn)過程
2.1 實現(xiàn)原理
其實redisson分布鎖信號量的實現(xiàn)原理非常簡單，就是在redis中的一個整數(shù)，當有制作報表的請求時，我們首先嘗試獲得一個信號量，如果能夠獲得(也就是信號量的整數(shù)大于0)就執(zhí)行制作報表的任務(wù)，然后讓信號量總數(shù)減1。制作報表的任務(wù)完成之后，再調(diào)用release()方法釋放一個信號量，信號總量+1。
2.2 核心代碼實現(xiàn)
接下來小千就把核心代碼給大家展示一下。我們先在redis中初始化一個信號量，并且設(shè)置為10個。
當某個站點發(fā)出打印報表的請求時，先把任務(wù)記錄到數(shù)據(jù)庫中，并把任務(wù)的狀態(tài)設(shè)置為【等待中】。
當流式查詢把所有的數(shù)據(jù)查出，并生成報表之后，我們應(yīng)該上傳報表到文件服務(wù)器，修改任務(wù)的狀態(tài)為【任務(wù)完成】，并釋放一個信號量出來。
三. 后話
為了解決此次OOM的問題，我們使用到了流式查詢分頁讀取數(shù)據(jù)，又使用到了分布式鎖的信號量限流，來限制同時執(zhí)行任務(wù)的個數(shù)。但小千的這個學生發(fā)現(xiàn)，大數(shù)據(jù)讀取、生成excel、文件上傳這些操作，每一個都非常耗時，為了不讓這三個操作彼此影響性能，最后還要使用MQ解耦，把這三個操作拆分成3個服務(wù)。至于結(jié)合MQ進行具體解決的方案，小千會在以后的文章中繼續(xù)連載，請各位同學繼續(xù)關(guān)注哦。
京公網(wǎng)安備 11010802030320號