這次回答星球內粉絲的提問。問題抽象：

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

數據假設：

• 假設用戶在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)根據分數做業務處理
         switch(sum)
         升級降級，發優惠券，發獎勵;
}

一個月執行一次的定時任務，會存在什么問題？

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

畫外音：外層循環100W級別用戶；內層循環9kW級別流水；業務處理需要10幾次數據庫交互。

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

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

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

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

這類問題的優化方向是什么？

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

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

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

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

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

…

會發現，2月和3月的數據（粉色部分），被重復查詢和計算了多次。畫外音：該業務，每個月的數據會被計算3次。

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

flow_month_sum(month, uid, flow_sum)

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

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

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

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

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

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

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

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

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

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

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

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

總結，對于這類一次性集中處理大量數據的定時任務，優化思路是：

• 同一份數據，減少重復計算次數；
• 分攤CPU計算時間，盡量分散處理（甚至可以實時），而不是集中處理；
• 減少單次計算數據量；

大數據量定時任務執行時間優化，你學廢了嗎？

知其然，知其所以然。

思路比結論更重要。