繼續(xù)答水友提問。

問題抽象：

• 用戶會員系統;
• 用戶會有分數流水，每個月要做一次分數統計，對不同分數等級的會員做不同業(yè)務處理;

數據假設：

• 假設用戶在100w級別;
• 假設用戶日均1條流水，也就是說日增流水數據量在100W級別，月新增流水在3kW級別，3個月流水數據量在億級別;

常見解決方案：

用一個定時任務，每個月的第一天計算一次。

//(1)查詢出所有用戶 
uids[] = select uid from t_user; 
//(2)遍歷每個用戶 
foreach $uid in uids[]{ 
         //(3)查詢用戶3個月內分數流水 
         scores[]= select score from t_flow 
                   where uid=$uid and time=[3個月內]; 
         //(4)遍歷分數流水 
         foreach $score in scores[]{ 
                   //(5)計算總分數 
                   sum+= $score; 
         } 
         //(6)根據分數做業(yè)務處理 
         switch(sum) 
         升級降級，發(fā)優(yōu)惠券，發(fā)獎勵; 
} 

一個月執(zhí)行一次的定時任務，會存在什么問題?

計算量很大，處理的數據量很大，耗時很久，按照水友的說法，需要1-2天。

畫外音：外層循環(huán)100W級別用戶;內層循環(huán)9kW級別流水;業(yè)務處理需要10幾次數據庫交互。

可不可以多線程并行處理?

可以，每個用戶的流水處理不耦合。

改為多線程并行處理，例如按照用戶拆分，會存在什么問題?

每個線程都要訪問數據庫做業(yè)務處理，數據庫有可能扛不住。

這類問題的優(yōu)化方向是：

• 同一份數據，減少重復計算次數;
• 分攤CPU計算時間，盡量分散處理，而不是集中處理;
• 減少單次計算數據量;

如何減少同一份數據，重復計算次數?

如上圖，假設每一個方格是1個月的分數流水數據(約3kW)。

• 3月底計算時，要查詢并計算1月，2月，3月三個月的9kW數據;
• 4月底計算時，要查詢并計算2月，3月，4月三個月的9kW數據;
• …

會發(fā)現，2月和3月的數據(粉色部分)，被重復查詢和計算了多次。

畫外音：該業(yè)務，每個月的數據會被計算3次。

新增月積分流水匯總表，每次只計算當月增量：

flow_month_sum(month, uid, flow_sum) 

• 每到月底，只計算當月分數，數據量減少到1/3，耗時也減少到1/3;
• 同時，把前2個月流水加和，就能得到最近3個月總分數(這個動作幾乎不花時間);

畫外音：該表的數量級和用戶表數據量一致，100w級別。

這樣一來，每條分數流水只會被計算一次。

如何分攤CPU計算時間，減少單次計算數據量呢?

業(yè)務需求是一個月重新計算一次分數，但一個月集中計算，數據量太大，耗時太久，可以將計算分攤到每天。

如上圖，月積分流水匯總表，升級為，日積分流水匯總表。

把每月1次集中計算，分攤為30次分散計算，每次計算數據量減少到1/30，就只需要花幾十分鐘處理了。

甚至，每一個小時計算一次，每次計算數據量又能減少到1/24，每次就只需要花幾分鐘處理了。

雖然時間縮短了，但畢竟是定時任務，能不能實時計算分數流水呢?

每天只新增100w分數流水，完全可以實時累加計算“日積分流水匯總”。

使用DTS(或者canal)增加一個分數流水表的監(jiān)聽，當用戶的分數變化時，實時進行日分數流水累加，將1小時一次的定時任務計算，均勻分攤到“每時每刻”，每天新增100w流水，數據庫寫壓力每秒鐘10多次，完全扛得住。

畫外音：如果不能使用DTS/canal，可以使用MQ。

總結

對于這類一次性集中處理大量數據的定時任務，優(yōu)化思路是：

• 同一份數據，減少重復計算次數;
• 分攤CPU計算時間，盡量分散處理(甚至可以實時)，而不是集中處理;
• 減少單次計算數據量; 希望大家有所啟示，思路比結論重要。

歡迎大家繼續(xù)提問，有問必答。

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉載請聯系原作者】

戳這里，看該作者更多好文