结合业务
相信以上说了这么多，大家尘封已久的记忆已经被彻底唤醒。那么，接下来，我将要结合具体的业务场景，来说说，我们在使用过程中需要注意的点。我将分几块进行说明：
一、任务和场景
使用定时任务的场景总结如下：
1、补偿机制：
当我们在处理业务的时候，可能会存在处理无结果的情况。而此时不能用快速失败来处理。
举例：
支付在调用网关的时候，网关调用外部银行渠道存在很多不可控的因素，如网络超时，或者银行没有返回明确结果的情况。这个时候，为了防止资损，我们采用了异步补偿的方式，掉单查询。
这里要说明下，一般这种情况是消息结合定时查询来做的。行业内通俗做法。
那么这里的查询就是定时任务来做的。借助数据库，进行查询并更新的操作。
2、特殊业务要求
这里举个很通俗的例子：对账。
无论是第三方支付公司还是银行，都存在清结算系统，凌晨或者t+1都会进行跑批，对账。
那么这个对账就是定时任务来做的。
所以，这种场景就是业务数据落地后，异步在某个时间点触发，进行特殊的业务操作。那么触发动作就是定时任务的职责了。
总结下
在联机操作没有明确结果的情况下，或者失败的情况下，需要重试或者补偿，保证操作最终成功。那么定时任务就发挥作用了。
另外，某些特殊的业务，如对账等功能，就是异步t+1通过跑批来做的。这个异步跑批就是定时任务的职责。
最后，我们在写一些中间件的时候，少不了的就是心跳机制，心跳机制也是通过定时任务来做的。通俗做法。
二、任务和锁
上面，讲了通用的场景操作。那么定时任务在处理的时候，需要注意些什么。
总结如下几点：
1、任务纬度：哪些机器跑这个任务。
2、任务纬度：任务失败了怎么办？
3、数据纬度：数据会被多个任务执行么？
4、数据纬度：数据可以被多个任务一起处理么？
下面我就来一一解释下：
老早的土鳖做法：
定时任务跟随着应用启动。如何确认数据不被重复执行呢？很简单，就是只在集群的一台机器上启动定时任务。
这个时候，怎么做？
服务启动的时候jvm参数 -Dxxxxx来注入启动参数。
这种做法的缺点显而易见：
服务的启动脚本变成了有状态，或者有差异了。无论对于发布，还是专业度而言，都很low。
我目前在的这家公司，目前负责的系统，就曾经因为这个脚本的问题导致资损。
升级做法：
去除脚本的差异化。那么这个时候可以通过锁机制来实现。下面我就来详细的说说怎么做：
一、每台服务器在启动的时候，都会去抢占一把公共锁。如果抢到，那么他就执行定时任务。任务就是你的了。
这样做的好处是，任务启动无状态，随机，随时。
这样做不好的地方是：依赖锁机制。如果出现死锁，或者第三方依赖异常，那么可能会影响任务，最后影响业务的运行。
当然，有补救的方法，那就是继续补偿喽。这个里面的补偿，并非继续再加一个定时任务。
而是，增加任务的批次和执行结果，配以监控和报警，再加上人工触发的接口。是不是perfect了？回答是必须的。如果这种做法再出问题。我挥刀自刎谢罪。哈哈。
所以，我们在定义定时任务的时候，建议做法如下：
1、建任务的批次表
2、建任务的执行日志表
3、对任务的执行者采用分布式锁机制。
4、增加报警和监控机制。
5、增加手工触发入口，以备不时之需。
OK，这里补充下两种锁机制：
1、悲观锁
2、乐观锁
我们一般会采用悲观锁的方式。悲观锁，顾名思义，就是争抢锁的发起者，很悲观。认为所有人都会和他竞争。所以抢到了立刻把钥匙拿走。
通俗的做法是：用共享存储来做锁。mysql or zookeeper?
对于mysql来说，做悲观锁可能有点麻烦。因为innerdb需要支持悲观锁，那么就要关闭数据库层面的auto commit。且如果没有指定具体的主键，将是表级锁。so,我们慎用。所以，一般推荐用zookeeper来做。或者变相的在数据库层面用乐观锁来实现悲观锁的方式。
二、分布式任务调度系统
对比以上，任务只能由一台执行。数据处理的效率并没有那么高。所以分布式任务调度系统，很好的解决这个问题。对数据进行分片。将条件注入到sql中去。这里就不再赘述了。推荐大家看下tbscheduler和elastic-job。
好了，夜深人静。总结到此。希望对大家对认识和问题的处理有所帮助。
