-
springboot+异步任务(五)
正文
1.springboot 整合异步任务
与定时任务的套路相同,通过注解来实现。
@EnableAsync,类注解。启动类中,添加该注解,表示开启异步任务。
@Component,类注解。异步任务类中,添加该注解,能让容器扫描到异步任务。
@Async,方法注解。添加到异步任务类的任务方法中,表示该方法是异步方法。
具体实现:
首先,启动类
1
2
3
4
5
6
7
|
@EnableAsync public class ThriftdemoApplication { public static void main(String[] args) { SpringApplication.run(ThriftdemoApplication. class , args); } } |
然后,异步任务类:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
@Component public class AsyncTask { @Async public Future<Boolean> doTask11() throws InterruptedException { long start = System.currentTimeMillis(); Thread.sleep( 1000 ); long end = System.currentTimeMillis(); System.out.println( "任务1耗时:" +(end - start)+ "毫秒" ); return new AsyncResult<>( true ); } @Async public Future<Boolean> doTask22() throws InterruptedException { long start = System.currentTimeMillis(); Thread.sleep( 700 ); long end = System.currentTimeMillis(); System.out.println( "任务2耗时:" +(end - start)+ "毫秒" ); return new AsyncResult<>( true ); } @Async public Future<Boolean> doTask33() throws InterruptedException { long start = System.currentTimeMillis(); Thread.sleep( 600 ); long end = System.currentTimeMillis(); System.out.println( "任务6耗时:" +(end - start)+ "毫秒" ); return new AsyncResult<>( true ); } } |
最后,测试异步任务是否实现:
新建异步任务的controller类,通过浏览器访问,计算总的访问耗时时间
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
|
@RestController @RequestMapping ( "tasks" ) public class AsyncController { @Autowired private AsyncTask asyncTask; @RequestMapping ( "test1" ) public String test1() throws InterruptedException { long start = System.currentTimeMillis(); Future<Boolean> a = asyncTask.doTask11(); Future<Boolean> b = asyncTask.doTask22(); Future<Boolean> c = asyncTask.doTask33(); while (!a.isDone()||!b.isDone()||!c.isDone()){ if (a.isDone()&&b.isDone()&&c.isDone()){ break ; } } long end = System.currentTimeMillis(); String items = "任务全部完成,总耗时:" +(end -start)+ "毫秒" ; return items; } } |
会发现,整个访问耗时为“任务全部完成,总耗时:1019毫秒”。
如果是同步任务,那么整个耗时应该是1000+700+600> 1019的。同时,我们将同步任务耗时打印一下,应证一下这个结论(去掉注解@Async,就可实现同步任务),可见“任务全部完成,总耗时:2305毫秒”。
同时,也可以发现,不管是异步还是同步,task11,task22,task33这三个子任务的耗时,几乎是不变的。
2.异步任务的使用场景
1.发短信,IM消息,发邮件,运维凌晨发布任务。比如我现在要做一次运营推广任务。任务的内容是向白名单用户通过短信(其实IM消息也是这个道理)方式推广一个运营活动,此时我通过业务注册来源,已经获取到这批白名单用户的手机号,如果我发完一条短信,再接着发第二条,那等我把白名单用户挨个发完短信,这个活动的活动期说不定都过去了。所以,我们要做的是,将这批白名单用户加入到多个消息队列中,通过定时任务,触发处理消息队列的发短信任务,消息就可以批量发出去了。这样就能解决挨个同步发送导致的问题。
2.需要等待回调的且包含多个子任务的项目,可以将该项目的架构设计为异步消息处理系统。(打个比方,可能博客园不是这样实现的)比如审核博客园的博主身份,我在提交一系列证件后,我的博主身份需一段时间查证,因此会通过标识位,让身份状态进入待验证状态。
后台会将提交的证件做分类,再作为多任务,加入到异步队列中,再推给平台审核,从提交到到推审这个过程是异步的,推审到平台,这个过程也是异步的,平台回调,也是各个证件审查平台各自发起各自的回调,不会管其他证件平台是否回调,这个也是异步的。因为不可能等一类证件提交推审了,另外一类证件才能提交推审,也不是一类证件推给平台了,另外一类才能推,这样,任务之间就增加了不必要的耦合了,真正的处理就是,所有待审核证件绑定的子任务都各干各的。
同时,每个平台审核的时长不同,有的审的快,有的审查的慢,送去审查后,后台就将送审的任务挂起,等待平台回调,这个过程叫异步回调。
回调后,就涉及到了状态检查的设计逻辑。有的证件有结果,有的证件没结果,如何知道审查结束了没?可以就像controller中写的while逻辑一样,得等,得轮训检查,等所有子任务都isDone了,这时候才能算整个审核任务结束了。
但是这个做法,在这个案例中并不聪明。就这个案例来说,我们在真正设计业务的时候,没必要while轮询,只要在每类证件(每个子任务)推审平台之后,在数据库对子任务状态做标记,等平台异步回调的时候,修改该证件的标识位状态(从检查中到检查结束),再去检查每类证件的标识位是不是检查结束状态,就可以知道整个审核是否结束。
原文:https://www.cnblogs.com/ansonwan/p/15480790.html