下载文档原格式
Quartz任务调度原理解析1. 什么是Quartz任务调度Quartz是一个开源的、功能强大的作业调度库，可以用于创建基于时间表的作业调度。
它允许开发人员能够编写灵活和可靠的作业，并将其安排在特定的时间或间隔内执行。
Quartz提供了丰富的API和灵活的配置选项，使得任务调度变得简单易用。
2. Quartz任务调度原理Quartz任务调度的基本原理可以分为以下几个方面：2.1 Job和Trigger在Quartz中，Job代表一个要执行的具体任务，而Trigger则定义了这个任务何时被执行。
Trigger可以基于时间表达式（cron表达式）来定义执行时间，也可以根据一些特定的规则来触发执行。
2.2 调度器（Scheduler）Scheduler是Quartz任务调度器的核心组件，负责管理所有Job和Trigger，并根据配置进行作业调度。
Scheduler可以创建、暂停、恢复和删除Job以及相关联的Trigger。
它还负责记录所有Job的状态信息，并在需要时触发相关事件。
2.3 JobDetailJobDetail是定义一个特定Job实例的详细信息，包括Job类名、Job名称、所属组等属性。
每个JobDetail都关联一个唯一标识符（JobKey），用于在Scheduler中唯一标识该Job。
2.4 TriggerTrigger是定义一个作业何时执行的组件。
它可以基于时间表达式来定义执行时间，也可以根据一些特定的规则来触发执行。
每个Trigger都关联一个唯一标识符（TriggerKey），用于在Scheduler中唯一标识该Trigger。
2.5 JobExecutionContextJobExecutionContext是Job在执行时的上下文信息，包括当前执行时间、上次执行时间、下次执行时间等。
Job可以通过获取JobExecutionContext中的信息来进行任务处理。
2.6 JobFactoryJobFactory负责创建Job实例，当Scheduler需要调度一个Job时，会通过JobFactory创建一个新的实例，并将其交给Scheduler管理。
Golang开源定时任务调度框架robfigcron优化项⽬中需要使⽤⼀个简单的定时任务调度的框架，最初直接从GitHub上搜了⼀个star⽐较多的，就是这个，⽬前有8000+ star。
刚开始使⽤的时候发现问题不⼤，但是随着单机需要定时调度的任务越来越多，⾼峰期差不多接近500QPS，随着业务的推⼴使⽤，可以预期增长还会⽐较快，但是已经遇到CPU使⽤率偏⾼的问题，通过pprof分析，很多都是在做排序，看了下这个项⽬的代码，整体执⾏的过程⼤概如下：1. 对所有任务进⾏排序，按照下次执⾏时间进⾏排序2. 选择数组中第⼀个任务，计算下次执⾏时间减去当前时间得到时间t，然后sleep t3. 然后从数组第⼀个元素开始遍历任务，如果此任务需要调度的时间<now，那么就执⾏此任务，执⾏之后重新计算这个任务的next执⾏时间4. 每次待执⾏的任务执⾏完毕之后，都会重新对这个数组进⾏排序5. 然后再循环从排好序的数组中找到第⼀个需要执⾏的任务去执⾏。
代码如下：for {// Determine the next entry to run.sort.Sort(byTime(c.entries))var timer *time.Timerif len(c.entries) == 0 || c.entries[0].Next.IsZero() {// If there are no entries yet, just sleep - it still handles new entries// and stop requests.timer = time.NewTimer(100000 * time.Hour)} else {timer = time.NewTimer(c.entries[0].Next.Sub(now))}for {select {case now = <-timer.C:now = now.In(c.location)("wake", "now", now)// Run every entry whose next time was less than nowfor _, e := range c.entries {if e.Next.After(now) || e.Next.IsZero() {break}c.startJob(e.WrappedJob)e.Prev = e.Nexte.Next = e.Schedule.Next(now)("run", "now", now, "entry", e.ID, "next", e.Next)}case newEntry := <-c.add:timer.Stop()now = c.now()newEntry.Next = newEntry.Schedule.Next(now)c.entries = append(c.entries, newEntry)("added", "now", now, "entry", newEntry.ID, "next", newEntry.Next)case replyChan := <-c.snapshot:replyChan <- c.entrySnapshot()continuecase <-c.stop:timer.Stop()("stop")returncase id := <-c.remove:timer.Stop()now = c.now()c.removeEntry(id)("removed", "entry", id)}break}}问题就显⽽易见了，执⾏⼀个任务（或⼏个任务）都重新计算next执⾏时间，重新排序，最坏情况就是每次执⾏1个任务，排序⼀遍，那么执⾏k个任务需要的时间的时间复杂度就是O(k*nlogn)，这⽆疑是⾮常低效的。
Quartz任务调度原理详解1. 什么是Quartz任务调度？Quartz是一个功能强大的开源任务调度框架，可以用于创建基于时间的触发器来执行作业。
它提供了灵活的配置选项和丰富的功能，使得开发人员能够轻松地编写和管理复杂的任务调度应用程序。
2. Quartz任务调度的基本概念在深入探讨Quartz任务调度原理之前，我们先来了解一些基本概念：•作业（Job）：作业是需要被调度执行的任务。
它可以是一个实现了Job接口的类，也可以是一个方法。
•触发器（Trigger）：触发器定义了作业何时执行的规则。
它可以基于时间、日期、间隔等进行配置。
•调度器（Scheduler）：调度器负责管理和控制作业和触发器的执行。
它根据预定的规则触发作业，并将作业交给执行线程池处理。
•执行线程池（Executor Thread Pool）：执行线程池用于处理作业的实际执行。
它负责从调度器中获取待执行的作业，并分配线程进行处理。
3. Quartz任务调度原理Quartz任务调度框架由多个组件协同工作，实现了高效、可靠的任务调度。
下面是Quartz任务调度的基本原理：3.1 调度器初始化当应用程序启动时，调度器需要进行初始化设置。
这涉及到创建和配置调度器实例、触发器和作业等。
•创建调度器实例：通过SchedulerFactory类的getScheduler()方法获取调度器实例。
•配置调度器：可以设置线程池大小、任务存储方式、作业并发性等参数。
•创建触发器：通过TriggerBuilder类创建触发器实例，并设置触发规则。
•创建作业：通过JobBuilder类创建作业实例，并指定要执行的作业类或方法。
3.2 触发器与作业关联在Quartz中，触发器与作业是一一对应关系，即一个触发器对应一个作业。
当触发条件满足时，触发器会将相应的作业交给调度器执行。
•将触发器与作业关联：通过调用scheduler.scheduleJob(jobDetail, trigger)方法将作业和触发器关联起来。
DolphinScheduler是一个开源的分布式任务调度系统，它基于DAG（有向无环图）的工作流调度模型。
下面是DolphinScheduler的调度原理：1. DAG任务调度：DolphinScheduler使用DAG任务调度模型来管理任务之间的依赖关系。
用户可以通过定义DAG任务，将多个任务以有向无环图的方式组织起来。
每个节点代表一个任务，边表示任务之间的依赖关系。
2. 任务队列和优先级：DolphinScheduler支持多个任务队列，每个队列都有一个优先级。
当任务提交时，可以指定任务所属的队列和优先级。
调度器根据队列和优先级来决定任务的调度顺序。
3. 调度策略：DolphinScheduler提供了多种调度策略，包括FIFO、FAIR、DEADLINE等。
不同的调度策略可以根据任务的特性和优先级来决定任务的调度顺序和资源分配。
4. 多线程调度：DolphinScheduler采用多线程调度方式，可以同时调度和执行多个任务，提高任务的并发性和效率。
调度器根据任务的依赖关系，按照拓扑排序算法进行调度，保证任务的正确执行顺序。
5. 弹性扩展：DolphinScheduler支持水平扩展，可以通过增加调度服务器和工作节点来实现系统的弹性扩展。
调度服务器负责任务的调度和监控，工作节点负责任务的执行。
6. 高可用性：DolphinScheduler通过主备模式实现高可用性。
主节点负责任务的调度和监控，备节点处于热备状态，当主节点故障时，备节点会自动接管主节点的工作。
7. 监控和告警：DolphinScheduler提供了丰富的监控指标和告警功能。
用户可以通过监控界面查看任务的运行状态和统计信息，还可以配置告警规则，及时发现和解决问题。
总体而言，DolphinScheduler通过DAG任务调度模型、任务队列和优先级、调度策略、多线程调度、弹性扩展、高可用性以及监控和告警等机制，实现了高效、稳定和可靠的分布式任务调度。
调度系统方案1. 引言调度系统是指对计算资源进行有效管理和分配的系统，旨在优化资源利用率、提高计算效率和降低成本。
本文将介绍一种调度系统方案，包括系统架构、调度算法和实施步骤等内容。
2. 系统架构调度系统的架构是其设计和实施的基础，一个良好的架构能够保证系统的稳定性和可扩展性。
下面是我们提出的调度系统的架构方案：2.1 Master-Slave 架构调度系统采用Master-Slave架构，包括一个主节点（Master）和多个从节点（Slave）。
Master负责整体调度和资源管理，而Slave负责执行具体的任务。
Master和Slave之间通过网络进行通信。
2.2 模块划分调度系统可以划分为以下几个模块：•任务管理模块：负责任务的创建、调度和监控。
•资源管理模块：负责资源的管理和分配。
•调度算法模块：负责制定调度策略和算法。
•通信模块：负责Master和Slave之间的通信。
3. 调度算法调度算法是调度系统的核心，它决定了任务如何被分配给Slave，并且需要考虑各种约束条件和优化目标。
以下是常用的调度算法之一：3.1 最短作业优先（SJF）最短作业优先是一种基于任务执行时间的调度算法，它会优先执行预计执行时间最短的任务。
这种算法适用于任务执行时间波动较小的场景，能够提高计算效率。
3.2 时间片轮转（RR）时间片轮转是一种基于时间片分配的调度算法，每个任务被分配一个固定的时间片，当时间片用完后，任务会被挂起，等待下一个时间片。
这种算法适用于多任务并发执行的场景。
3.3 其他调度算法除了上述算法，还存在很多其他调度算法，如先进先出（FIFO）、最高响应比优先（HRRN）等。
根据实际需求，可以选择合适的调度算法。
4. 实施步骤实施一个调度系统需要经过以下几个步骤：4.1 确定需求首先需要明确调度系统的需求和目标，包括任务类型、系统规模、计算资源等。
4.2 设计架构根据需求确定调度系统的架构方案，包括主节点和从节点之间的通信方式、模块划分等。
登录https://localhost:8443注意是https，采用的是jetty ssl链接。
输入账号密码azkaban/azkanban（如果你之前没有更改的话）首页首页有四个菜单∙projects：最重要的部分，创建一个工程，所有flows将在工程中运行。
∙scheduling:显示定时任务∙executing:显示当前运行的任务∙history:显示历史运行任务主要介绍projects部分首先创建一个工程，填写名称和描述，比如o2olog。
o2olog工程Flows：工作流程，有多个job组成Permissions:权限管理Project Logs:工程日志创建工程：创建之前我们先了解下之间的关系，一个工程包含一个或多个flows，一个flow包含多个job。
job是你想在azkaban中运行的一个进程，可以是简单的linux命令，可是java程序，也可以是复杂的shell脚本，当然，如果你安装相关插件，也可以运行插件。
一个job可以依赖于另一个job，这种多个job和它们的依赖组成的图表叫做flow。
job创建创建job很简单，只要创建一个以.job结尾的文本文件就行了,例如我们创建一个工作，用来将日志数据导入hive中（关于大数据方面的东西，不在重复，可以理解为，将日志所需数据导入的mysql中），我们创建o2o_2_hive.jobtype=commandcommand=echo "data 2 hive"一个简单的job就创建好了，解释下，type的command，告诉azkaban用unix原生命令去运行，比如原生命令或者shell脚本，当然也有其他类型，后面说。
一个工程不可能只有一个job，我们现在创建多个依赖job，这也是采用azkaban的首要目的。
flows创建我们说过多个jobs和它们的依赖组成flow。
怎么创建依赖，只要指定dependencies参数就行了。
Gearman-Java 用法简介:Gearman-Java是Gearman任务分发系统的Java客户端库，用于实现分布式任务处理。
本文将深入探讨Gearman-Java的用法，包括基本原理、功能特点以及在Java应用中的实际应用。
1. 基本原理:- Gearman框架: Gearman是一个开源的分布式任务处理框架，允许将任务分发到多个工作服务器上执行。
Gearman-Java作为其客户端，通过Gearman协议与Gearman服务器通信，实现任务的提交和结果的获取。
- 任务分发模型: Gearman-Java采用任务分发模型，将任务提交到Gearman服务器，由服务器将任务分发到可用的工作服务器上。
这种模型有效地实现了任务的并发处理和分布式计算。
2. 功能特点:- 异步任务提交: Gearman-Java支持异步任务提交，允许应用程序在提交任务后继续执行其他操作，而不必等待任务完成。
这有助于提高应用的响应速度和吞吐量。
- 任务优先级: Gearman-Java允许为任务设置优先级，确保重要任务在工作服务器上得到更高的处理优先级，保证任务的及时和有序处理。
3. 实际应用:- 分布式计算: 在大规模计算任务中，Gearman-Java可用于将任务分发到多台计算机上进行并行处理，提高计算效率。
- 异步任务处理: 对于一些需要异步处理的业务场景，比如邮件发送、数据处理等，可以通过Gearman-Java提交异步任务，减少用户等待时间。
4. 使用方法与代码示例:- 任务提交:javaGearman gearman = Gearman.createGearman();GearmanClient client = gearman.createGearmanClient();GearmanJobResult result =client.submitJob("taskFunction", "taskData");- 异步任务提交:javaGearmanJobEventListener listener = new MyGearmanJobEventListener(); 自定义事件监听器GearmanJobFuture future =client.submitJob("asyncT askFunction", "asyncTaskData", listener);继续执行其他操作等待异步任务完成future.get();5. 注意事项与常见问题:- Gearman服务器配置: 在使用Gearman-Java时，需要确保正确配置Gearman服务器的地址和端口，以便客户端能够与服务器正常通信。
slurm的原理Slurm是一种用于管理超级计算机集群的开源作业调度系统。
它的设计目标是在多用户、多任务的环境中高效地分配计算资源，以实现最佳的系统利用率和作业性能。
Slurm的核心原理是基于作业调度和资源管理。
它通过一个中央控制节点（controller）和多个计算节点（compute nodes）之间的协作，实现对作业的提交、调度和执行的管理。
在Slurm中，用户可以通过向控制节点提交作业描述文件来请求计算资源，包括指定需要的节点数量、运行时间、内存需求等。
控制节点根据预定义的调度策略和系统资源状况，将作业分配给计算节点进行执行。
Slurm的调度算法是其原理的核心部分。
它采用了先进的资源分配算法，如Backfilling和负载平衡算法，以最大程度地减少作业的等待时间和系统的负载不均衡。
Backfilling算法允许较短的作业在等待队列中插队执行，以便更好地利用系统资源。
负载平衡算法则根据节点的负载情况，动态地将作业分配给最适合的节点，以实现整个集群的负载均衡。
Slurm还具有高可用性和容错性的特性。
它支持多个控制节点的冗余配置，以防止单点故障导致的系统中断。
当一个控制节点失效时，其他节点会接管其功能，保证系统的持续运行。
此外，Slurm还提供了详细的日志记录和错误处理机制，以便管理员对系统进行监控和管理。
除了基本的作业调度和资源管理功能，Slurm还提供了丰富的扩展功能和插件机制。
用户可以通过自定义插件来扩展Slurm的功能，如添加新的调度策略、资源限制规则等。
这使得Slurm能够适应不同的应用场景和需求，满足各种复杂的计算任务的要求。
Slurm作为一种高效灵活的作业调度系统，通过合理的资源分配和调度算法，实现了对超级计算机集群的有效管理。
它的原理基于作业调度和资源管理，通过中央控制节点和计算节点的协作，实现作业的提交、调度和执行。
同时，Slurm还具有高可用性和容错性的特性，支持插件扩展，使其适用于各种复杂的计算任务。
dolphinscheduler原理DolphinScheduler：开源分布式任务调度系统随着大数据处理的普及，任务调度显得越来越重要。
在这样的背景下，DolphinScheduler应运而生，成为当前任务调度领域的一颗新星。
本文将从以下几个方面介绍DolphinScheduler的原理和功能。
1. DolphinScheduler概述DolphinScheduler是一款由Apache开源基金会孵化的分布式任务调度系统。
它是由腾讯开发的一款开源、易扩展的任务调度系统，能够满足数据处理的各种需求，如离线数据处理、流式计算、数据管道等。
2. DolphinScheduler核心原理DolphinScheduler的核心原理包括任务调度模型、主从模型、任务流模型、监控报警模型等。
2.1 任务调度模型基于CRON表达式，DolphinScheduler可以实现常见的定时任务调度，如定时周期性任务、每月特定日期执行任务等。
此外，DolphinScheduler还支持手动触发任务，使开发人员不必等待定时任务执行才能检查代码。
2.2 主从模型DolphinScheduler采用主从模型，即有一个或多个主节点和多个从节点。
主节点负责分配任务，而从节点则执行任务。
这种主从模型可以实现任务的负载均衡、高可用以及扩展性。
2.3 任务流模型DolphinScheduler将多个任务组合成一个任务流，任务流中的任务可以并行或串行执行。
这种任务流模型可以实现多个任务的协同处理，提高数据处理的效率。
2.4 监控报警模型DolphinScheduler具有完善的监控报警系统，可以实时监控任务的执行情况，并以邮件、短信等方式进行告警通知。
这种监控报警模型可以及时发现任务执行问题，并及时解决。
3. DolphinScheduler功能介绍DolphinScheduler的功能非常丰富，主要包括以下几个方面。
3.1 权限管理DolphinScheduler支持用户和角色的权限管理，可以为不同的用户分配不同的角色，并配置各个角色的任务访问权限、数据访问权限等。
gearman分布式任务调度系统方少森@百度一、总体介绍gearman是一个分布式任务分发调度框架，支持多语言、并发的任务执行，支持负载均衡。
gearman具有如下特点：1、开源2、支持多语言接口：php、perl、python、C 等；3、灵活：不必拘泥与特定的模式，可以灵活使用分布式框架，如map/reduce；4、速度快，开销小5、可嵌入，很轻6、无单点。
二、gearman运行机制简介gearman包含3个基本组件：client、worker和job server。
client - 创建要运行的任务，并提交给job server。
job-server - 寻找最合适的worker，并提交任务给worker。
worker - 接收job server的任务，执行并返回结果，结果通过job server返回给client。
从图中可以看出，client和worker均为gearman提供的api。
三、一个简单的实例一个基于P HP的实例，功能是用于反转字符串，client代码：job server收到任务请求后，会寻找一个能够运行“reverse”的worker执行该任务。
worker上的代码如下：上述事例的运行时序图如下：四、三角色的工作流程一次正常的Gearman任务执行流程如上图所示：1. worker向Gearman Server注册自身可以执行的功能2. worker尝试获取一个任务3. server通告worker暂无任务4. worker通告server：“我先睡会，有活干时再叫醒我”5. client向server发起任务请求6. server唤醒可以完成这项工作的worker（可能会唤醒多个woker）7. worker向server发起“饥饿”请求，尝试获得一个任务8. server选定一个worker，将该任务分配下去9. 通告client：“我安排别人处理你的请求了，耐心等待吧”10. worker辛苦工作一段时间后，向server通告“干完了”11. server将结果反馈给用户说明：1. 任务分类：按优先级分：普通（SUBMIT_JOB），高（SUBMIT_JOB_HIGH），低（SUBMIT_JOB_LOW）∙按执行方式分：普通（_JOB_HIGH,_JOB_LOW）,后台（_JOB_HIGH_BG,_JOB_LOW_BG）——最大区别在于，client可以跟踪前台任务的工作状态，而不能跟踪BG任务2. 任务工作状态的通告（worker-->server-->client）：∙WORK_DATA:∙WORK_WARNING∙WORK_STATUS对于长任务，worker应该每隔一段时间通告任务状态∙WORK_COMP LETE∙WORK_FAIL∙WORK_E XCEPTION3. Server监控Gearman有“Administrative P rotocol”专门用于对Gearman Server的监控，主要涉及以下几方面：status：所注册职能分类，worker总数目，处于工作状态的worker数目，可用worker数目等w orker的详细信息：所注册功能、IPserver的缓存任务最大队列长度：可以被查询也可以被设定五、通信协议1、二进制packet格式所有请求和返回均为二进制数据包，包含header和可选的数据。
header包含如下字段：4 byte magic code - This is either "\0REQ" for requests or "\0RES" for responses.4 byte type - A big-endian (network-order) integer containingan enumerated packet type. Possible values are:# Name Magic Type1 CAN_DO REQ Worker2 CANT_DO REQ Worker3 RESET_ABILITIES REQ Worker4 PRE_SLEEP REQ Worker5 (unused) - -6 NOOP RES Worker7 SUBMIT_JOB REQ Client8 JOB_CREATED RES Client9 GRAB_JOB REQ Worker10 NO_JOB RES Worker11 JOB_ASSIGN RES Worker12 WORK_STATUS REQ WorkerRES Client13 WORK_COMPLETE REQ WorkerRES Client14 WORK_FAIL REQ WorkerRES Client15 GET_STATUS REQ Client16 ECHO_REQ REQ Client/Worker17 ECHO_RES RES Client/Worker18 SUBMIT_JOB_BG REQ Client19 ERROR RES Client/Worker20 STATUS_RES RES Client21 SUBMIT_JOB_HIGH REQ Client22 SET_CLIENT_ID REQ Worker23 CAN_DO_TIMEOUT REQ Worker24 ALL_YOURS REQ Worker25 WORK_EXCEPTION REQ WorkerRES Client26 OPTION_REQ REQ Client/Worker27 OPTION_RES RES Client/Worker28 WORK_DATA REQ WorkerRES Client29 WORK_WARNING REQ WorkerRES Client30 GRAB_JOB_UNIQ REQ Worker31 JOB_ASSIGN_UNIQ RES Worker32 SUBMIT_JOB_HIGH_BG REQ Client33 SUBMIT_JOB_LOW REQ Client34 SUBMIT_JOB_LOW_BG REQ Client35 SUBMIT_JOB_SCHED REQ Client36 SUBMIT_JOB_EPOCH REQ Client4 byte size - A big-endian (network-order) integer containingthe size of the data being sent after the header.data域中的参数之间通过一个字节的NULL分割，最后一个参数的界定范围为NULL分隔符之后到data域总长度之间的数据。
参数的长度不能超过64字节（包括NULL分隔符）。
client/w orker 与job server交互packet格式如下：Client/Worker Requests----------------------These request types may be sent by either a client or a worker:ECHO_REQWhen a job server receives this request, it simply generates aECHO_RES packet with the data. This is primarily used for testingor debugging.Arguments:- Opaque data that is echoed back in response.Client/Worker Responses-----------------------These response types may be sent to either a client or a worker:ECHO_RESThis is sent in response to a ECHO_REQ request. The server doesn't look at or modify the data argument, it just sends it back.Arguments:- Opaque data that is echoed back in response.ERRORThis is sent whenever the server encounters an error and needsto notify a client or worker.Arguments:- NULL byte terminated error code string.- Error text.Client Requests---------------These request types may only be sent by a client:SUBMIT_JOB, SUBMIT_JOB_BG,SUBMIT_JOB_HIGH, SUBMIT_JOB_HIGH_BG,SUBMIT_JOB_LOW, SUBMIT_JOB_LOW_BGA client issues one of these when a job needs to be run. Theserver will then assign a job handle and respond with a JOB_CREATED packet.If on of the BG versions is used, the client is not updated withstatus or notified when the job has completed (it is detached).The Gearman job server queue is implemented with three levels:normal, high, and low. Jobs submitted with one of the HIGH versions always take precedence, and jobs submitted with the normal versions take precedence over the LOW versions.Arguments:- NULL byte terminated function name.- NULL byte terminated unique ID.- Opaque data that is given to the function as an argument.SUBMIT_JOB_SCHEDJust like SUBMIT_JOB_BG, but run job at given time instead ofimmediately. This is not currently used and may be removed.Arguments:- NULL byte terminated function name.- NULL byte terminated unique ID.- NULL byte terminated minute (0-59).- NULL byte terminated hour (0-23).- NULL byte terminated day of month (1-31).- NULL byte terminated month (1-12).- NULL byte terminated day of week (0-6, 0 = Monday).- Opaque data that is given to the function as an argument.SUBMIT_JOB_EPOCHJust like SUBMIT_JOB_BG, but run job at given time instead ofimmediately. This is not currently used and may be removed.Arguments:- NULL byte terminated function name.- NULL byte terminated unique ID.- NULL byte terminated epoch time.- Opaque data that is given to the function as an argument.GET_STATUSA client issues this to get status information for a submitted job.Arguments:- Job handle that was given in JOB_CREATED packet.OPTION_REQA client issues this to set an option for the connection in thejob server. Returns a OPTION_RES packet on success, or an ERROR packet on failure.Arguments:- Name of the option to set. Possibilities are:* "exceptions" - Forward WORK_EXCEPTION packets to the client.Client Responses----------------These response types may only be sent to a client:JOB_CREATEDThis is sent in response to one of the SUBMIT_JOB* packets. Itsignifies to the client that a the server successfully receivedthe job and queued it to be run by a worker.Arguments:- Job handle assigned by server.WORK_DATA, WORK_WARNING, WORK_STATUS, WORK_COMPLETE, WORK_FAIL, WORK_EXCEPTIONFor non-background jobs, the server forwards these packets fromthe worker to clients. See "Worker Requests" for more information and arguments.STATUS_RESThis is sent in response to a GET_STATUS request. This is used byclients that have submitted a job with SUBMIT_JOB_BG to see if the job has been completed, and if not, to get the percentage complete.Arguments:- NULL byte terminated job handle.- NULL byte terminated known status, this is 0 (false) or 1 (true).- NULL byte terminated running status, this is 0 (false) or 1(true).- NULL byte terminated percent complete numerator.- Percent complete denominator.OPTION_RESSuccessful response to the OPTION_REQ request.Arguments:- Name of the option that was set, see OPTION_REQ for possibilities.Worker Requests---------------These request types may only be sent by a worker:CAN_DOThis is sent to notify the server that the worker is able toperform the given function. The worker is then put on a list to bewoken up whenever the job server receives a job for that function.Arguments:- Function name.CAN_DO_TIMEOUTSame as CAN_DO, but with a timeout value on how long the jobis allowed to run. After the timeout value, the job server willmark the job as failed and notify any listening clients.Arguments:- NULL byte terminated Function name.- Timeout value.CANT_DOThis is sent to notify the server that the worker is no longerable to perform the given function.Arguments:- Function name.RESET_ABILITIESThis is sent to notify the server that the worker is no longerable to do any functions it previously registered with CAN_DO orCAN_DO_TIMEOUT.Arguments:- None.PRE_SLEEPThis is sent to notify the server that the worker is about tosleep, and that it should be woken up with a NOOP packet if ajob comes in for a function the worker is able to perform.Arguments:- None.GRAB_JOBThis is sent to the server to request any available jobs on thequeue. The server will respond with either NO_JOB or JOB_ASSIGN, depending on whether a job is available.Arguments:- None.GRAB_JOB_UNIQJust like GRAB_JOB, but return JOB_ASSIGN_UNIQ when there is a job.Arguments:- None.WORK_DATAThis is sent to update the client with data from a running job. Aworker should use this when it needs to send updates, send partialresults, or flush data during long running jobs. It can also beused to break up a result so the worker does not need to buffer the entire result before sending in a WORK_COMPLETE packet.Arguments:- NULL byte terminated job handle.- Opaque data that is returned to the client.WORK_WARNINGThis is sent to update the client with a warning. It acts justlike a WORK_DATA response, but should be treated as a warning instead of normal response data.Arguments:- NULL byte terminated job handle.- Opaque data that is returned to the client.WORK_STATUSThis is sent to update the server (and any listening clients)of the status of a running job. The worker should send theseperiodically for long running jobs to update the percentagecomplete. The job server should store this information so a client who issued a background command may retrieve it later with a GET_STATUS request.Arguments:- NULL byte terminated job handle.- NULL byte terminated percent complete numerator.- Percent complete denominator.WORK_COMPLETEThis is to notify the server (and any listening clients) thatthe job completed successfully.Arguments:- NULL byte terminated job handle.- Opaque data that is returned to the client as a response.WORK_FAILThis is to notify the server (and any listening clients) thatthe job failed.Arguments:- Job handle.WORK_EXCEPTIONThis is to notify the server (and any listening clients) thatthe job failed with the given exception.Arguments:- NULL byte terminated job handle.- Opaque data that is returned to the client as an exception.SET_CLIENT_IDThis sets the worker ID in a job server so monitoring and reporting commands can uniquely identify the various workers, and different connections to job servers from the same worker.Arguments:- Unique string to identify the worker instance.ALL_YOURSNot yet implemented. This looks like it is used to notify a jobserver that this is the only job server it is connected to, soa job can be given directly to this worker with a JOB_ASSIGN andno worker wake-up is required.Arguments:- None.Worker Responses----------------These response types may only be sent to a worker:NOOPThis is used to wake up a sleeping worker so that it may grab apending job.Arguments:- None.NO_JOBThis is given in response to a GRAB_JOB request to notify theworker there are no pending jobs that need to run.Arguments:- None.JOB_ASSIGNThis is given in response to a GRAB_JOB request to give the workerinformation needed to run the job. All communication about thejob (such as status updates and completion response) should usethe handle, and the worker should run the given function withthe argument.Arguments:- NULL byte terminated job handle.- NULL byte terminated function name.- Opaque data that is given to the function as an argument.JOB_ASSIGN_UNIQThis is given in response to a GRAB_JOB_UNIQ request and actsjust like JOB_ASSIGN but with the client assigned unique ID.Arguments:- NULL byte terminated job handle.- NULL byte terminated function name.- NULL byte terminated unique ID.- Opaque data that is given to the function as an argument.2、管理协议job server支持文本的命令，用于获取信息和执行管理任务。
