做矢量图的网站seo项目培训
目录
一、技术架构
二、业务挑战
2.1 调度任务量大
2.2 运维复杂
2.3 SLA要求高
三、调度优化实践
3.1 重复调度
3.2 漏调度
3.3 Worker服务卡死
3.4 任务重复运行
四、服务监控
4.1 方法耗时监控
4.2 任务调度链路监控
五、用户收益
原文大佬的这篇调度系统案例有借鉴意义，这里直接摘抄下来用作学习和知识沉淀。
一、技术架构
在我们公司的大数据离线任务调度架构中，调度平台处于中间层，通过数据集成平台、数据开发平台将工作流提交给调度平台。
二、业务挑战
2.1 调度任务量大
目前每天调度的工作流实例在3万多，任务实例在14万多。每天调度的任务量非常庞大，要保障这么多任务实例稳定、无延迟运行，是一个非常大的挑战。
2.2 运维复杂
因为每天调度的任务实例非常多，经历了几次调度机器扩容阶段，目前2个调度集群有6台Master、34台Worker机器。
2.3 SLA要求高
由于业务的金融属性，如果调度服务稳定性出问题，导致任务重复调度、漏调度或者异常，损失影响会非常大。
三、调度优化实践
我们在过去一年，对于调度服务稳定，我们做了如下2个方向的优化。第一，调度服务稳定性优化。第二、调度服务监控。
3.1 重复调度
用户大规模迁移工作流时，遇到了工作流重复调度问题。现象是同一个工作流会在同一个集群同一时间，生成2个工作流实例。经过排查，基于从A项目迁移到B项目的需求，在工作流上线时，用户通过提交工单，修改了调度数据库中工作流的项目ID，进行迁移。这么做会导致该工作流所对应的quartz（分布式调度器）元数据产生2条数据，进而导致该工作流重复调度。如图3所示，JOB_NAME为’job_1270’的记录，有2条数据，而JOB_GROUP不一样。查询源码job_name对应工作流的定时器ID，JOB_GROUP对应项目ID。因此修改工作流对应的项目ID，会导致quartz数据重复和重复调度。正确迁移工作流项目的方式是，先下线工作流，然后再修改项目ID。
SELECT count(1)FROM (SELECT TRIGGER_NAME, count(1) AS num FROM QRTZ_TRIGGERS GROUP BY TRIGGER_NAME HAVING num > 1 )t3.2 漏调度
凌晨2点调度太集中，有些工作流发生漏调度。因此优化了quartz参数，将org.quartz.jobStore.misfireThreshold从60000调整为600000。
如何监控和避免此问题，监控sql摘要如下：
select TRIGGER_NAME,NEXT_FIRE_TIME ,PREV_FIRE_TIME,NEXT_FIRE_TIME-PREV_FIRE_TIME from QRTZ_TRIGGERS where NEXT_FIRE_TIME-PREV_FIRE_TIME=86400000*2
sql逻辑是：根据quartz（分布式调度器）的元数据表QRTZ_TRIGGERS的上一次调度时间PREV_FIRE_TIME和下一次调度时间NEXT_FIRE_TIME的差值进行监控。如果差值为24小时就正常，如果差值为48小时，就说明出现了漏调度。
如果已经发生了漏调度如何紧急处理？ 我们实现了漏调度补数逻辑通过自定义工作流进行http接口调用。如果监控到发生了漏调度情况，可以立即运行此工作流，就能把漏调度的工作流立即调度运行起来。
3.3 Worker服务卡死
这个现象是凌晨调度Worker所在机器内存占用飙升至90%多，服务卡死。
思考产生该问题的原因是，调度worker判断本机剩余内存时，有漏洞。假设设置了worker服务剩余内存为25G时，才不进行任务调度。但是，当worker本机剩余内存为26G时，服务判断本机剩余内存未达到限制条件，那么开始从zk队列中抓取任务，每次抓取10个。而每个spark的driver占用2G内存，那么本地抓取的10个任务在未来的内存占用为20G。我们可以简单计算得出本机剩余内存为26G-20G为6G，也就是说抓取了10个任务，未来的剩余内存可能为6G，会面临严重不足。
为了解决这个问题，我们参考Yarn，提出了”预申请”机制。预申请的机制是，判断本机剩余内存时，会减去抓取任务的内存，而不是简单判断本机剩余内存。
如何获取将要抓取任务的内存大小呢？ 有2种方式，第一种是在创建工作流时指定本任务driver占用的内存，第二种是给一个固定平均值。
综合考虑，采用了第二种方式，因为这种方式对于用户来说，是没有感知的。我们对要抓取的每个任务配置1.5G（经验值）内存，以及达到1.5G内存所需要的时间为180秒，抓取任务后，会放入缓存中，缓存过期时间为180（经验值）秒。剩余内存计算公式，本机剩余内存 = 【本机真实物理剩余内存】—【缓存中任务个数*1.5G】
还是同样的场景，本机配置的剩余内存为25G，本机实际剩余内存为26G，要抓取的任务为10个。每个任务未来占用的driver内存为1.5G。简单计算一下，本机剩余内存=26G-10*1.5G。在“预申请”机制下，本机剩余内存为1G，小于25G，不会抓取，也就不会导致Worker机器的内存占用过高。那么会不会导致Worker服务内存使用率过低呢，比如shell、python、DataX等占用内存低的任务。结论是不会，因为我们有180秒过期机制，过期后，计算得到的本机剩余内存为变高。
实施上文的内存预申请机制后，最近半年没有遇到由于内存占用过高导致worker服务卡死的问题。以下是我们加上内存预申请机制后，worker内存使用率情况，可以看见worker最大内存使用率始终稳定保持在80%以下。
3.4 任务重复运行
在worker服务卡死时，我们发现yarn上的任务没有被杀死，而master容错时导致任务被重复提交到yarn上，最终导致用户的数据异常。
我们分析后发现，任务实例有一个app_link字段，该字段存放用户提交的yarn任务的app id，而第一次调度的任务的app id为空。排查代码发现worker在运行任务时，只有完成的yarn 任务，才会更新app_link字段。这样导致master在容错时，拿不到app id，导致旧任务没有被杀死，最终导致任务重复提交。
我们进行的第一个改进点为，在worker运行yarn任务时，从log中实时过滤出app id，然后每隔5秒将app id更新到app_link字段中。 这样yarn任务在运行时，也就能获取到app id，master容错时就能杀死旧任务。
第二个改进点为，在worker服务卡死从而自杀时，杀死本机上正在运行的调度服务，这样可能master就不需要进行容错了。 实施改进点后，最近半年没有遇到重复调度的yarn任务了。
四、服务监控
一个稳定的系统，除了代码上的优化，一定离不开完善的监控。DolphinScheduler 对外提供了 Prometheus 格式的基础指标，我们新增了一些高优指标，并集成到公司内部的监控系统。通过监控大盘来查看调度系统的健康状况，并针对不同级别的prometheus指标和阈值，配置电话 / 钉钉报警。
4.1 方法耗时监控
我们通过byte-buddy、micrometer等，实现了自定义轻量级java agent框架。这个框架实现的目标是监控java方法的最大耗时、平均耗时、qps、服务的jvm健康状况等。并把这些监控指标通过http暴露出来，通过prometheus抓取，再通过grafana进行可视化展示，并针对不同级别的prometheus指标和阈值，配置电话 / 钉钉报警。
例如以下是master访问zk和quartz的最大耗时，平均耗时，qps等。
以下是master服务的jvm监控指标
通过该java agent，我们实现了api、master、worekr、zookeeper等服务方法耗时监控，提前发现问题并解决，避免将问题扩大到用户感知的状况。
4.2 任务调度链路监控
为了保障调度任务的稳定性，有必要对任务调度的生命周期进行监控。DolphinScheduler服务调度任务的全流程是先从quartz（分布式调度器）中产生Command（待调度指令），然后将Command转化为工作流实例，再从工作流实例生成一系列对应的任务实例，需要对该任务链路的生命周期进行监控。
- 监控quartz元数据
前面已经讲了我们通过监控quartz元数据，发现漏调度和重复调度问题。
- 监控command表积压情况
通过监控command表积压情况，从而监控master是否服务正常，以及master服务的性能是否能够满足需求。
- 监控任务实例
通过监控任务实例等待提交时间，从而监控worker服务是否正常，以及worker服务的性能是否能够满足需求。
综上，通过上述的全生命周期监控，可以提前感知到worker服务的性能问题，并及时解决。
五、用户收益
通过对DolphinScheduler代码的优化，获得的最大收益是近半年没有因为调度服务故障导致用户的SLA受影响，当调度系统出现问题时，能及时感知并解决。
参考文章：
Apache DolphinScheduler 在奇富科技的首个调度异地部署实践