由于一些代码遗留问题，决定重构定时任务，中间出了一些问题，希望能够帮助到大家。
定时任务
业务中经常会有一些需要定时任务或者任务调度系统的场景，例如：数据备份,订单超时,数据统计以及一些特殊业务需求。往往这也是最容易出问题的地方。说一下代码重构的时候对定时任务的一些见解，欢迎大家批评指正！
下面说的单机或是一台物理机或者是跨进程的应用。
- 分布式下使用分布式锁
大多数情况下，服务都是多机部署的，对于数据有并发限制的情况，一定要使用分布式锁，确保任务是在单机运行的。 - 禁止单任务并发进行，多任务可并行
这条适用的情况和分布式锁大概相同，目前定时任务调度框架多是默认并发的，可能相同的任务同时进行，但是任务内部又未做并发处理，会造成最终数据的不准确；对于不同类型且不产生关联的任务可以采用并行处理。 - 使用quartz而非Spring Task
Task虽然更加轻量化，但是很多高级特性并不支持，同时对于任务失败的情况并不会进行处理，不能确保任务不可控中断时会自动重启任务。 - 任务内部多线程的使用
这里不讨论并发的处理，任务中一些不需要同步或者耗时的操作交由线程池或者forkjoin执行的时候，执行结果应该与schedule线程同步，这里说的同步并非严格意义上的线程同步，举个例子说，在分布式环境中，如果任务必须需要获取分布式锁来保证单机执行，任务可以交由线程池异步处理，定时器线程可以处理一些其他的事情，但是定时器线程必须等待异步处理的结果，来决定是否释放分布式锁，或者采用守护线程监听的方式来决定锁的状态，因为一旦锁释放，极其有可能被别的机器获取，而此时本机还在执行任务，从而导致并发问题。使用线程池仅仅是为了加快任务处理速度或者不阻塞一些辅助操作，线程池要使用自定义抛弃策略和异常策略，不允许线程池向外抛出异常，被schedule线程捕获之后，即使schedule线程拥有处理能力，也有可能会导致定时任务提前结束。 - 执行粒度与容错性
举个简单的例子，一家十个部门，每个部门有100个人，每个月10号要定时发工资，有很多种处理的方式，可以对一个部门的100人批处理发工资，也可以一个人一个人的发，可能一批人同时发因为一个人有问题导致所有人都发不了，对于这种上下级数据以及同级数据间无关联性的情况，下级异常不能影响上级 同级异常不影响后续，即一个人出问题，不能影响别人，更不能影响部门。 - 补救
定时任务处理失败的情况经常会发生，但是对于能考虑到异常的情况要制定一定的补救措施，能够自动恢复，也可以增加人工补救的措施。
