1: 因为定时任务不是核心功能,所以可能会需要经常发布 ,介于这种情况,把定时任务独立开来一个单独的模块,
然后依赖 订单,行程等等模块的service.
2:为什么不放到tomcat里面跑呢,基于以下几个原因
1: 以后类似的功能模块独立,都会依赖一个tomcat,在运维上带来麻烦
2:放到tomcat比较吃内存,加上tomcat的一些不需要的依赖,会变得臃肿.
3:定时任务既然独立开了一个模块去跑单独的进程, 那么以后可能也会对外提供服务, 可能会变成既是服务提供者,又是服务消费者.(现在的这种任务调度的方式,还算是比较传统,
昨天想了一下,能不能自己实现一个中间件, 然后集成进去我们的业务代码, 由业务代码主动去调用定时服务)
还是举个例子吧:比如我们一旦下单成功, 按照现在的定时任务策略, 是每隔多久去数据库轮训一次所有的订单查询,然后 再把满足条件的订单设置为超时 .
这样有一个问题就是, 每次查询数据库全表扫描,一旦数据库数据量比较大的话, 就会因为一些不相关的数据影响了性能,比如查询只是查询超时的订单,却扫描了整个订单表
所以 ,是不是可以这样,如果一旦有人下单成功, 我们就将它加入超时任务的中间件当中 , 然后中间件的线程池去轮训所有加入定时任务的任务 . 这样一来定时任务的目的性就比较强了.
还有一个好处就是:现在定时任务,只能单台机器跑,否则可能会出现重复执行的情况, 一旦用一个中间件来实现的话, 就可以实现多台跑, 而且不会重复跑, 虽然现在不是很有必要,
但是,如果一旦性能跟不上,的时候就要做集群. 如果需要稳定性比较高的情况下,就需要做主备
但是这样 一来 也会出现一个弊端, 你说对了,那就是我们的业务代码 ,依赖了中间件. 一旦需求需要加一个定时任务的时候,就需要修改业务代码 ,增加一个超时需求. 这样一来,我们就不能
随心所欲的想自己发布自己的定时任务了.
但是别急, 刚刚不是说了吗, 为了考虑到2种情况的弊端,现在把这个定时任务单独出来,即是生产者,也是消费者. 一旦业务想随心所欲的加任务,那么就把当成消费者好了 .只依赖别人.
如果想用中间件的话,那么就把他当成生产者对外提供服务. 这样就一举两得了