java 定时杀进程_定时任务 独立跑一个JVM进程

1: 因为定时任务不是核心功能,所以可能会需要经常发布 ,介于这种情况,把定时任务独立开来一个单独的模块,

然后依赖 订单,行程等等模块的service.

2:为什么不放到tomcat里面跑呢,基于以下几个原因

1: 以后类似的功能模块独立,都会依赖一个tomcat,在运维上带来麻烦

2:放到tomcat比较吃内存,加上tomcat的一些不需要的依赖,会变得臃肿.

3:定时任务既然独立开了一个模块去跑单独的进程, 那么以后可能也会对外提供服务, 可能会变成既是服务提供者,又是服务消费者.(现在的这种任务调度的方式,还算是比较传统,

昨天想了一下,能不能自己实现一个中间件, 然后集成进去我们的业务代码, 由业务代码主动去调用定时服务)

还是举个例子吧:比如我们一旦下单成功,  按照现在的定时任务策略, 是每隔多久去数据库轮训一次所有的订单查询,然后 再把满足条件的订单设置为超时 .

这样有一个问题就是, 每次查询数据库全表扫描,一旦数据库数据量比较大的话,   就会因为一些不相关的数据影响了性能,比如查询只是查询超时的订单,却扫描了整个订单表

所以 ,是不是可以这样,如果一旦有人下单成功,  我们就将它加入超时任务的中间件当中 ,   然后中间件的线程池去轮训所有加入定时任务的任务 .  这样一来定时任务的目的性就比较强了.

还有一个好处就是:现在定时任务,只能单台机器跑,否则可能会出现重复执行的情况,  一旦用一个中间件来实现的话, 就可以实现多台跑,  而且不会重复跑, 虽然现在不是很有必要,

但是,如果一旦性能跟不上,的时候就要做集群.  如果需要稳定性比较高的情况下,就需要做主备

但是这样 一来 也会出现一个弊端, 你说对了,那就是我们的业务代码 ,依赖了中间件. 一旦需求需要加一个定时任务的时候,就需要修改业务代码 ,增加一个超时需求. 这样一来,我们就不能

随心所欲的想自己发布自己的定时任务了.

但是别急, 刚刚不是说了吗, 为了考虑到2种情况的弊端,现在把这个定时任务单独出来,即是生产者,也是消费者.   一旦业务想随心所欲的加任务,那么就把当成消费者好了 .只依赖别人.

如果想用中间件的话,那么就把他当成生产者对外提供服务. 这样就一举两得了