结合业务
相信以上说了这么多,大家尘封已久的记忆已经被彻底唤醒。那么,接下来,我将要结合具体的业务场景,来说说,我们在使用过程中需要注意的点。我将分几块进行说明:
一、任务和场景
使用定时任务的场景总结如下:
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。
好了,夜深人静。总结到此。希望对大家对认识和问题的处理有所帮助。
网友评论