支付宝定时任务怎么做?三层分发任务处理框架介绍 | 您所在的位置:网站首页 › odd定制 › 支付宝定时任务怎么做?三层分发任务处理框架介绍 |
本文将从单机定时调度开始,循序渐进地带领大家了解五福定制三层分发任务处理框架。
一、背景介绍 技术同学对定时任务肯定不陌生。定时任务一般用来定时批量进行业务处理。支付宝卡包券到期提醒、删除过期失效券,五福大促批量给用户发放添福红包等场景,都是通过定时任务触发来完成的。 作者有幸参与了2023兔年五福大促的开发,主导完成了福气乐园分会场平分5000万大奖需求。通过学习并运用五福定制三层分发任务处理框架,最终平稳丝滑的完成了平分大奖需求任务。本文将从单机定时调度开始,循序渐进地带领大家了解五福定制三层分发任务处理框架。二、定时任务分类 2.1、单机任务 单机定时任务毫无疑问是在单台机器上运行的定时任务。在业务量级不大,没有进行分库分表时,往往单机定时任务即可满足业务需求。 从复杂度上来说,单机定时任务又可分为简单的定时调度和定时调度+批处理两种。 1、定时调度在Spring中可以通过@Scheduled 来启用定时任务。触发的方式有两种,分别是:cron 表达式和 fixedRated类配置参数。常用的案例: // cron表达式 @Scheduled(cron="0 0/30 9-17 * * ?") //按cron规则执行,朝九晚五工作时间内每半小时 @Scheduled(cron="0 0 12 ? * WED") //按cron规则执行,表示每个星期三中午12点 // fixedRated类配置 @Scheduled(fixedRate=5000) //上一次开始执行时间点后5秒再次执行; @Scheduled(fixedDelay=3000) //上一次执行完毕时间点后3秒再次执行; @Scheduled(initialDelay=1000, fixedDelay=2000) //第一次延迟1秒执行,然后在上一次执行完毕时间点后2秒再次执行;定时调度往往用于业务处理流程比较简单的场景,比如定时生成简单报表,发送通知。对于复杂耗时的场景,处理效率不高,业务高峰期会积压大量待处理数据,影响业务。 2、定时调度+批处理为了解决复杂耗时场景下定时调度效率不高的问题,可以引入批处理框架。定时调度与批处理框架相结合,可以大幅提高数据处理的效率,提升系统稳定性,保障业务稳定运行。 以Spring Batch批处理框架为例,任务处理流程如下: Spring Batch批处理框架将任务拆分成多个Step,同时每个Step里面又分为itemReader,itemProcessor, itemWriter。通过将任务分层细化,能够让多个阶段并行处理,提高任务处理效率。批处理框架结合定时调度框架,可以在单机情况下,对大量复杂的业务进行高效的批处理。
2.2、集群任务 在分库分表大业务流量情况下,单机定时任务已无法满足业务需求了,这时就产生了集群定时任务。在支付宝技术架构下,用户数据按照eid进行分库分表,同时进行Zone维度的隔离。此时单机定时任务无法对全量数据做处理,于是支付宝便有了自己的分布式任务调度中间件Antscheduler,配合三层分发任务处理框架,就可以对大量数据进行定时批量处理。 1、三层分发![]() 通过代码可知,推送任务配置时,将A组机器的值推成“ODD”,B组机器的值推成“EVEN”,即可实现A/B组的所有机器同时执行定时任务的效果。 2、平滑的任务处理 默认的三层分发通过Loader层获取待处理的任务,然后交由Executor来执行,无法保证整个集群任务处理的量级。在待处理任务变多,或者集群机器扩缩容变化频繁的情况下,任务处理的峰值量级无法保证。同时由于各个层级之间的调用是TR oneway调用,是感知不到调用结果的,也就更难保证任务的平滑调用。为了达到任务平滑调用的目的,五福场景对Loader捞取任务数和单机任务qps做了优化调整,保证了集群任务处理效率在预期范围之内。优化的步骤如下: 1.新增任务配置。核心配置信息包括期望集群执行任务总的qps、任务调度间隔,集群参与任务机器数。 2.计算单机qps和每次DB捞取任务的数量。 3.单机执行时,根据计算好的qps来进行限流调用。 上面三步做好之后,整个集群就能够按照预期的qps进行平滑的任务处理。 为什么这三步做完了之后就能达到预期的效果呢? 重点看下任务配置的解析代码: /** * 计算定时任务的相关配置 * * 主要计算: * scheduleSingleLimit 单机限流值 * scheduleLoaderCount loader捞取条数 * * @param scheduleConfig */ public static SchedulerConfig calculateScheduleConfig(SchedulerConfig scheduleConfig) { final int qpsLimit = scheduleConfig.getScheduleWholeLimit(); final int machineCounts = scheduleConfig.getScheduleMachineCounts(); MtLogger.info(LOGGER, "【计算定时任务配置】-开始 任务名称:{0},机器数量:{1},任务吞吐量:{2}.", scheduleConfig.getScheduleType(), machineCounts, qpsLimit); //定时任务的调度频率是scheduleRate 秒执行一次 所以scheduleRate秒中内集群的整体吞吐量=qps限制*scheduleRate final int scheduleRate = scheduleConfig.getScheduleRatePerSec(); long totalLoaderCounts = qpsLimit * TimeUnit.SECONDS.toSeconds(scheduleRate); //定时任务捞取的表数量为1000 所以到每个表的限制=totalLoaderCounts/1000 long loaderCountPerTask = totalLoaderCounts / 1000; if (loaderCountPerTask < 1) { loaderCountPerTask = 1; } scheduleConfig.setScheduleLoaderCount((int) loaderCountPerTask); //整体限流通过单机限流实现 整体限流=单机限流*machineCounts final double singleQps = ((double) qpsLimit / machineCounts); //创建的限流需要1秒的预热 scheduleConfig.setScheduleSingleLimit(RateLimiter.create(singleQps, 1, TimeUnit.SECONDS)); MtLogger.info(LOGGER, "【计算定时任务配置】-结束 任务名称:{0},捞取条数:{1},单机限流:{2}.", scheduleConfig.getScheduleType(), scheduleConfig.getScheduleLoaderCount(), scheduleConfig.getScheduleSingleLimit().getRate()); return scheduleConfig; }通过代码可知,推送的任务配置最终会生成两个重要的配置信息: 1.单个Loader捞取的任务数。集群qps和调度间隔确定了一个调度间隔内要处理的任务数,结合eid分片数量(五福是千库千表)确定每个Loader要捞取的任务数。 2.单机Executor执行任务时的qps。预期集群qps和集群机器数确定了单机执行任务时的qps,单机上通过Guava的RateLimit来达到限流的效果。如果请求超过了限制的qps,请求将会被阻塞。 下面以福气乐园平分5000万大奖的任务配置作为样例来计算:相比通常情况下指定Loader每次捞取的任务数,五福是通过集群qps和任务调度间隔来确定Loader需要捞取的任务数。因此一个调度间隔内的任务数和集群能够执行的任务数是匹配上的,加上通过单机qps限制达到集群qps限制的效果,从而让整个定时任务做到了平滑调用。简而言之,优化后的调度逻辑,能够让定时调度任务在机器维度和时间维度都能均匀平稳的执行。 三、结语 从单机到集群,再到五福定制集群定时任务,本文逐步做了一个框架设计上的原理介绍。每种定时任务都有自己的优点和缺陷,也都有自己的应用场景。在工作中,要结合当前的业务情况,选择合适的定时任务进行业务处理,避免设计上的失误导致业务受损。以五福定制三层分发任务处理框架为例,虽然日常业务中,因为机器数量不固定,依旧无法做到任务的平滑调用,但我们可以借鉴最大化利用集群机器资源这一点,同时开启A/B组的定时任务,从而实现任务调度真正的负载均衡,提高系统整体的稳定性。
作者|金盛杰(司旭) 本文来自博客园,作者:古道轻风,转载请注明原文链接:https://www.cnblogs.com/88223100/p/How-to-do-Alipay-timed-tasks-Introduction-to-the-three-layer-distribution-task-processing-framework.html |
CopyRight 2018-2019 实验室设备网 版权所有 |