计划任务的常见错误写法

浅浅的花香味﹌ 2022-06-07 06:11 68阅读 0赞

最近遇到的schedule问题总结

# **获取大量的数据逐条处理** #

许多计划任务是用于统计或者批处理的，经常需要遍历某个列表

比如：

//查找所有将要过期的用户，逐个发送邮件

Iterable<UserEntity> users = userDAO.findExpireUser();  
**for** (UserEntity user : users) \{

//发送逻辑  
Thread.*sleep*(5000);  
\}  
\}

上面的这个例子里，开发者可能认为同时过期的用户可能不多，不过如果系统里的用户是同一天批量创建的，他们中的大多数会在同一天过期，于是就可能出现几万，几十万用户都需要发邮件的壮观场面。。。。上面这个例子里，一次来了两百万。

正确做法：

取数据要分页取，分页处理，处理了立即释放，除非你非常确定不会增长的列表，都不许用listAll，getAll，因为生产环境的行为永远出乎你的意料。

Iterable<UserEntity> users = userDAO.findExpireUserbyPage(i,pagesize);  
**for** (UserEntity user : users) \{

//发送逻辑  
Thread.*sleep*(5000);  
\}  
\}

从团队方面来讲，凡是DAO里面有listAll，getAll,无条件search的都是问题高发区，团队应该限制对这些方法的调用。

# **在循环里Sleep一会儿** #

还是上面的例子，每次发送邮件等待5秒。假如有200w用户同时过期，还不算发送逻辑本身的时间，大概是115.7天的时间，关键是在这大概4个月的时间里，users这个列表妥妥的无法被回收，轻松吃掉一两个G内存呢，而且OutOfMemory可等不了4个月，分分钟在来的路上呢。

正确做法：

在循环里千万不要sleep或者调用太费时的任务，比如上面的逻辑，应该把邮件放到发送列表，然后立刻返回,这些耗时的操作，比如发送邮件这些事情，应该交给另外的进程去完成。术业有专攻，不要越俎代庖

Iterable<UserEntity> users = userDAO.findExpireUserbyPage(i,pagesize);  
**for** (UserEntity user : users) \{

//发送逻辑  
MailBox.put(new ExpireMail(user.mail))  
\}  
\}

# 被直觉带节奏 #

产品：请写一个schedule统计出所有用户每天的登录次数

程序猿的设计：分页获取所有用户，查找该页用户今天的登录日志条数

UserEntity users=GetAllUser(page，pageSize);

For(UserEntity user in users)\{

List<Log> logs=getLoginLogForToday(user.username);

System.out.println(“username:”+user.username+” logintimes:”+logs.size);

上面的需求、设计、代码看起来简洁有效，需要让统计用户，所以我就循环所有用户，但是你肯定就上当了。这个实现是个坑，因为用户不会都登录，设想一个网站有1000万用户，每天登录的用户可能就100w人次，按照上面的实现，一定会循环1000万次，但是如果反过来，从日志入手，就只用循环100w次

正确做法：

找到循环最少的路径，不要被语言表面的意思所干扰，不是需求的主语一定是程序的主题

# 1次循环就能完成？不，让我多来几次 #

比如每分钟我们要把登录日志取出来，分析下有没有异常情况，比如有没有ip重复登录啦，有没有应用访问量超标啊，有没有人在危险的地区登录啊，然后把危险情况产生预警，通知管理员。于是产生了这样的代码

IpLoginAnalyzer implements Analyzer\{

> Public void process（）\{ 
> 
> List<log> logs=getLog(Now,lastCheckTime)
> 
> > 。。。分析逻辑
> 
> \}

AppVisitBarrierAnalyzer implements Analyzer\{

> Public void process（）\{ 
> 
> > List<log> logs=getLog(Now,lastCheckTime)
> > 
> > 。。。分析逻辑
> 
> \}

DangerLocationAnalyzer implements Analyzer\{

> Public void process（）\{ 
> 
> > List<log> logs=getLog(Now,lastCheckTime)
> > 
> > 。。。分析逻辑
> 
> \}

。。。。。

//处理日志逻辑

For（analyzer in AnalyerList）\{

> Analyzer.process()

乍一看很顺眼，每个analyzer干自己的事情，但是具体执行起来，会多次查询和循环日志，考虑下假如有100个分析器，就会遍历日志100次，加上执行process本身需要时间，非常可能造成这分钟的还没有执行完，下次的分析又开始了，一波波最终叠加成海啸，让应用歇菜。

正确做法：

日志分析，如果至少要遍历一遍，那么最好也就只遍历一遍，写个遍历器，负责逐条遍历，把每条交给各个处理器处理,一次遍历解决所有问题。

List<log> logs=getLog(Now,lastCheckTime)

For(log in logs)\{

> For（analyzer in AnalyerList）\{ 
> 
> > if(analyzer.canProcess(log))
> > 
> > analyzer.process(log)
> 
> \}

可能你会问，如果每个处理器处理的日志类型不同怎么办呢，比如有的处理器处理登录，有的处理创建用户，有的要处理所有日志，其实只要有处理所有日志的情况，其他的处理就可以一起做了，反正都要循环一次，就不要再浪费cpu循环多次了，对开发团队来说，日志处理应该有统一的框架，有统一的人审核，处理类似数据，执行频率相同的要归并，否则各自为政就会出现上面的情况。