实战录 | 基于redis的分布式HA调度器解决方案

实战录》导语

云端卫士的新栏目《实战录》将会定期分享一些我们的工程师伙伴们在产品研发的过程中总结的实践经验，希望对于热爱技术且关注安全领域的受众有所裨益。本期分享人为云端卫士大数据工程师王国伟，将带来基于redis的分布式HA调度器解决方案。

1 项目背景

由于云端卫士的安全大数据平台的离线、实时数据处理以及其他业务均有大量的定时任务的场景需求，要求定时任务器做到高可用、高并发。

具体的功能性需求如下：

1.高并发的支持：避免部分模块(比如关系库)形成性能瓶颈
2.分布式HA：要求多活节点，且保证分布式一致性，且保证同类节点的负载均衡
3.fail-over(故障转移)：要求对于调度任务能够支持故障转移，保证任务调度的可靠性
4.轻量级且业务无关
5.支持网络穿透：部分任务访问目标地址会有独立安全域，并不对所有分布式节点开放
6.支持个性化jobclas代码热加载：避免更新时部分节点的服务中断

  针对以上功能点，我们团队针对现有的定时器的实现方案作了一个对比：

基于以上考虑，团队决定自己开发一个基于redis存储的HA的分布式任务调度系统。

2 项目架构

项目采用分布式的方式，各功能节点拓扑结构：

各节点角色

•quartz-proxy：作为本项目的核心调度器,proxy集群为无中心的设计，支持负载均衡，支持group级别的负载均衡以及fail-over
•redis：主要用于proxy端的jobstore以及分布式协调
•client：作为任务的CURD的发起端，与proxy进行交互实现任务的CURD的操作
•manger web console：除了兼具普通client端具有的CURD还包括了任务的web端的展现以及操作

3 实现细节

基于以上设计，这里介绍下我们在具体开发遇到的以下几点技术关键点或是难点，给大家提供下技术参考。

分布式锁

由于proxy设计上为无中心设计，需要通过分布式锁才保证集群状态的一致性，这里没有采用zookeeper作为分布式锁的支持，是由于本项目原则上坚持轻量化，且尽量保证较少的依赖组件，所以采用了redis为分布式锁的实现。

实现分布式锁,我认为分布式锁需要支持以下三个基本的特性：
•原子的非共享资源的占用
 采用redis的setnx这个原子操作来标志非共享资源的归属，实现原子的非共享资源的占用
•极端情况下锁占用(死锁)的抢占
 如果超过一定时间锁依然未释放成功，其他节点可以强行抢占当前锁
•锁释放通知，保证锁再次参与竞争的及时性
由于基于轮询的方式对于实时性以及性能无法保证，所以这里借用redis的PubSub模型实现消息的通知，当节点未能获取锁时，subscribe锁释放消息channel，当当前锁释放之后，向channel publish消息通知其他节点继续参与锁竞争。

jobstore(任务的分布式存储)

由于本项目的是基于quartz实现，自定义quartz任务的持久化端需要实现org.quartz.spi.JobStore接口，这里不再罗列所有方法，需要实现的主要的方法如下：

//*jobstore初始化
public void initialize(ClassLoadHelper loadHelper,SchedulerSignaler signaler)
//任务存储
public void storeJobAndTrigger(JobDetail newJob, OperableTrigger newTrigger)
//任务触发
List<TriggerFiredResult> triggersFired(List<OperableTrigger> triggers) throws JobPersistenceException;
//任务完成后的回调
void triggeredJobComplete(OperableTrigger trigger, JobDetail jobDetail, CompletedExecutionInstruction triggerInstCode);
List<OperableTrigger> acquireNextTriggers(long noLaterThan, int maxCount, long timeWindow)

由于存储采用redis，这里基于分桶策略实现任务的优先级存储，采用redis的有序队列实现：

waiting_triggers：等待调度的任务队列，所有刚加入到任务都会在计算下一次的调度时间之后按照时间顺序加入此队列
acquired_triggers：quartz会基于quartz自身任务加载策略，调用acquireNextTriggers方法load需要近期调度的任务到内存中，将任务从waiting_triggers加入到acquired_triggers队列中
completed_triggers：当任务调度完成，会调用triggeredJobComplet,此方法将acquired_triggers转移到此队列中。

paused_triggers：暂停的触发器
blocked_triggers：阻塞的触发器
error_triggers：任务出错时将触发器移到此队列中进行任务的错误处理

网络穿透，支持子安全域的负载均衡以及fail-over

各个proxy在配置时会设置各个proxy的group属性，添加任务时可以指定此字段(比如此任务只有group1的proxy网络可达) Job信息再添加时Proxy在领取当前proxy的调度任务时需要检查当前任务所属的group，如果不为空且不属于当前proxy，则放弃领取此任务,具备相应group条件的公平竞争此任务调度权限。

个性化jobclas代码热加载

实现ClassLoader来支持自定义的jobsclass的热加载。

可视化

4 建议

以上为我们团队在分布式调度器的基于redis的实践，此调度器已经在我们项目中稳定运行1年以上，性能以及稳定性经过实践的检验，满足了我们项目组对分布式调度器的需求。

如果需要重量级的实现，大家可以参考当当最近开源的分布式调度器的实现：https://github.com/dangdangdotcom/elastic-job