如何经过任务调度实现百万规则报警

2021年11月25日 阅读数:11
这篇文章主要向大家介绍如何经过任务调度实现百万规则报警,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

简介:报警是一个公司的平常需求,常见的形态除了知足运维过程当中的基础设施监控报警(CPU/内存/磁盘等)以外,部分公司也会在应用指标(如 QPS、RT 等)及业务指标(如 GMV/日活 等)上有相应的报警需求。数据库

做者 | 黄晓萌segmentfault

01 问题背景

报警是一个公司的平常需求,常见的形态除了知足运维过程当中的基础设施监控报警(CPU/内存/磁盘等)以外,部分公司也会在应用指标(如 QPS、RT 等)及业务指标(如 GMV/日活 等)上有相应的报警需求。架构

在业务发展初期,基础设施较少,且应用形态单一,因此处理这一类需求每每会比较粗暴直接,可是随着业务的增加,尤为发展到日活百万甚至上亿级的时候,监控指标也会呈指数级上涨,在这种状况下对于报警体系就提出了巨大的挑战,如何解决这种体量下报警的有效性和时效性就成为了 IT 治理的重中之重。本篇文章,咱们将从监控指标的体量出发,详解各个阶段报警体系中遇到的各个挑战。并发

02 一次常规的报警流程示意图

以下图所示,一次常规意义上的报警流程,主要会包含并发检查、齐全度检查、数据追补、阈值判断等核心环节。同时,为了保证报警的时效性,基本上整个流程会是一个秒级触发的形态,具体以下:负载均衡

image.png

其中,报警后台任务处理系统是咱们此次讨论的重点,几个核心流程的说明以下:运维

  • 并发检查:检查当前告警规则是否是在其余进程或者节点中执行中,避免有些告警规则检查耗时过长,被重复执行了或被其余的任务节点抢占执行。
  • 齐全度检查:获取当前告警规则对应的数据源的齐全度时间,即最新数据上报到什么时间了。由于数据源数据采集和上报必定会有延时的,若是数据不齐就进行检查,很容易漏报和误报。
  • 数据查询:从监控数据中获取该规则的数据,通常会从收集上来的日志服务(如:ElasticSearch 服务等)或者基础监控指标存储服务(如:Zabbix、Prometheus 等)中获取。
  • 数据追补:由某些报警任务设置的策略,没有数据点的状况下怎么处理。有补0,补满和不补三种。如在针对业务数据跌零报警的场景,咱们会更倾向于补 0 ;可是针对 CPU 平均值超 80% 的场景,咱们会倾向于不补。
  • 阈值判断:根据获取的数据和报警条件,判断是否须要触发报警。
  • 告警:将告警信息经过短信、钉钉、邮件等方式通知到配置的人,以便后续有人处理。

03 进程内调度方案

一开始的业务不多的时候,报警任务也趋于少数,这个时候通常的实现都会基于一个进程内的线程池执行相关的操做,架构图以下:分布式

image.png

把上图的“后台任务处理系统”放到一台机器上运行,能很快速的知足小规模的场景。可是等到业务量持续上涨的时候,一台机器就出现了资源瓶颈,这个时候一个下意识的反应就是扩容上面的任务处理系统,让不一样的 Server 处理不一样的报警规则。可是随着报警规则在不断增长,负载的持续上涨会引发 Server 也会重启或者忽然挂掉。因而高可用、任务幂等执行、failover 等分布式问题又是面临的一个复杂的难题。性能

04 分布式调度解决方案

若是任务数达到万级别,寻求一个轻量的分布式的方案是咱们的目标。分布式调度方案的基本思路都是经过单独的任务调度中心来调度任务,报警后台只管执行任务,即任务调度和任务执行隔离的思路,使得两层都能作很好的横向扩容来达到容量上涨的目的。业务实现上,每一个报警规则会生成一个定时任务,这样能够保证每一个报警规则负载均衡地执行。开源市场有挺多产品,好比:Quartz、xxl-job、elastic-job 等。以 quartz 为例,示意图以下:测试

image.png

如上图所示,quartz 的每一个 Server,会加载全量的全部任务,每次任务时间到了,全部 Server 会经过数据库抢锁,抢到锁的 Server 触发该任务给报警中心。阿里云

  • 这个架构解决了任务的分布式调度、幂等执行的问题,而且执行层能够水平扩展,在任务量低的状况下能够稳定运行。
  • 但是从上面的架构图能够看出,Quartz 的调度主要经过轮询 DB 和经过 DB 加锁的方式而实现,这个时候整个系统的吞吐基本上和 DB 的规格和性能息息相关。经测试,若是在任务量调度频率 1 分钟级别的触发达到1万,就会出现比较明显的调度延时。

05 基于 SchedulerX 2.0 的超大规模任务调度方案

一、SchedulerX 2.0 优点

SchedulerX 2.0 是阿里巴巴自研的一款商业化分布式任务调度平台,相对于开源任务调度系统,它有几大优点:

  • 支持海量任务
  • 自研轻量级分布式跑批模型
  • 可视化任务编排
  • 商业化报警
  • 可视化日志服务

image.png
SchedulerX2.0 基础架构图

与常见方案相比,SchedulerX2.0 会将任务分布式到不一样的 Server 调度,每次任务调度也不须要抢锁触发,和数据库无任何交互,没有性能瓶颈。

二、高可用能力

在分布系统中最多见的就是高可用问题,若是 SchedulerX 2.0 的某个 Server 挂了会怎么办?

image.png

如上图所示,每一个应用都会作三备份,经过 zk 抢锁,一主两备,若是某台 Server 挂了,会进行 failover,由其余 Server 接管调度任务。

image.png

三、商业化报警

SchedulerX 2.0 当前支持钉钉、短信、邮件三种报警通道:

image.png

支持任务失败、超时、无可用机器报警:

image.png

以钉钉告警为例,您能够实时收到报警:

image.png

06 总结

SchedulerX 2.0 在阿里巴巴集团内支撑了全部事业群的业务,经历了屡次双十一的考验,当前在公有云已接入1000+家企业,在海量任务和高可用方面有充足的经验。显然,在超大规模任务调度领域,SchedulerX 2.0 已是目前最优解决方案之一。

原文连接
本文为阿里云原创内容,未经容许不得转载。