如何设计一个海量任务调度系统

得得地

作者：timgc背景在日常开发中会经常遇到一些需要异步定时执行的业务诉求，典型的使用场景如：超时未支付订单关单、每隔2h更新好友排行榜、3.22日17点《xx》剧上线等。目前业务侧多基于以下思路来快速搭建一个调度系统，mysql或者redis队列存储待执行任务，通过crontab定时触发应用完成“捞取、计算、执行等操作”。不难看出存在几类亟待解决问题：1）缺少统一的调度平台导致各业务重复开发；2）简易版调度实现在任务吞吐、调度时效上缺少保障；3）业务和调度数据强耦合存储给线上稳定性引入大key、慢sql风险。目前存在多类开源解决方案如XXL-Job、Elastic-Job、quartz调度等，但这些都属于进程级调度平台，很难满足更细粒度的业务调用。基于上述的业务诉求和司内现状，我们准备搭建一套通用的分布式任务调度平台（以下统称为tjobs平台）以满足业务高可靠、低延迟的海量任务调度诉求。整体设计设计目标旨在提供一个易用、可靠、高性能、低时延的海量任务管理、调度平台，帮助开发工程师专注于面向业务编码设计，而不再担心定时任务的吞吐量、可靠性等非功能需求。由此衍生的功能和非功能诉求分别为：功能性诉求：任务管理：包括任务注册、任务启停、任务更新等，任务查询：主要用于任务追踪、问题排查、调度统计等，任务回调：由业务提供spi回调实现，tjobs平台定时调用触发非功能性诉求tjobs定位为高可靠、高性能、低延迟、简单易用的任务调度平台，在满足核心功能的基础上提供以下非功能性保障：平台化：支持多业务接入、百亿级任务注册易用性：自助化接入、运维，使用成本远低自建高可靠：全年3个9可用性、p99(时延)99.95%任务触达率>99.99%p99(触达延时)99.99%。HA支持作为一个任务调度平台，系统的高可用性和功能的完整性同样重要，所以对外承诺三个核心SLA（全年可用性>99.95%、任务触达率>99.99%、p99(延迟)99.99%，并且任务RPO=0满足不丢任务SLA，主备切换分钟级RTO基本满足全年P99(延迟)30'')，最多影响单机上30‘’任务的调度延迟，降低延迟概率但不能彻底解决问题，且缩短周期会和调度平台交互更强（有悖减少调度平台依赖）服务器支持主备failover，每个任务组派发到多个服务器上，通过etcd选主一台服务器执行，如果服务器宕机自动failover到备机执行，max延迟就是选主耗时综合上述分析看，要提升保障平台整体的P99(延迟)、和99.95%的可用性SLA，最优方案是“基于调度平台+应用服务器主备failover”，具体的实现思路（如下图所示），每个周期内待调度的jobGroup分被分配到三个不同应用svr上，应用层一主两备的部署运行时，然后三个应用svr链接etcd，利用etcd的选主和自动failover能力，既保障了任务运行的onlyonce又能保障单机故障时该机上待执行任务的准时触发Misfire策略tjobs平台会有兜底的misfire策略以防止任务不能被准时调度时兜底调度过期任务，以保障所有任务触达率不低于99.99%，目前提供两类Misfire策略：1.马上触发一次，已过期任务马上触发一次业务回调（默认用于singleTask）2.尽快触发一次，忽略已过期任务触发回调，本周期内尽快执行一次业务回调（默认用于cronTask和intervalTask）部署落地部署架构非容灾模式线上运行快照（如上图所示），针对常见的单机宕机或者重启在HA章节已经介绍过，比如svr-2宕机或重启时g_3这个跑批任务组会自动failover到svr-12或者svr-3上继续断点执行，从而保障高可用性。针对常见的单机房故障，在任务dispatch环节会将一个任务jobGroup的主备执行机器分配到不同的set，从而保障单机房故障时从应用到DB都能自动failover到其他可用区机房；针对日常的停机发布，由于应用支持分set主备failover，因此发布时按a、bset依次发布即可。性能压测详细的压测执行过程不在展开，这里只同步一下压测结论压测摸高峰值：任务注册1.5w/s、任务触发2.2w/s应用&DB峰值：机型配置机器数量峰值负载说明应用服务器4C8G2045%支持横向扩展，通过扩容保留20倍容量空间数据库服务8C32G875%目前合并部署，通过调整部署保留4倍空间通过DB升配保留8倍的容量空间峰值SLA：可用性>99.99%、1s内触发占比>99.95%、任务触达率~100%。总结tjobs作为一个高性能、低延迟的分布式任务调度平台，在满足通用的任务注册、查询、触发等基本功能同时，也通过可伸缩的架构、HA能力、体系化可用性建设保障系统在百亿任务量、百万TPM触发能力下满足系统可用性、延迟、触达率SLA。支持将任务划分到不同的分片分配到不同的应用机器上执行，既保留了高峰时百万TPM的触发能力、也支持低峰时合并部署以节省成本；通过任务前置使用定时任务扫描、内存时间轮保证任务及时触发，保证了任务执行的低延迟；通过主备热活、自动failover能力建设保证系统整体从存储层到应用的全栈高可用。附录层级时间轮的Golang实现|RussellLuoetcd选主实现故障主备秒级切换高可用架构|KL博客概览::ElasticJob