处理赏罚亿级数据的“按时使命”，怎样收缩执行时刻？

继承答水友提问。

题目抽象：

• 用户会员体系;
• 用户会有分数流水，每个月要做一次分数统计，对差异分数品级的会员做差异营业处理赏罚;

数据假设：

• 假设用户在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。

总结

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!