Quartz Job Scheduling Framework[翻译]第十一章. Quartz 集群 (第三部分)

三. 配置 Quartz 使用集群

为 Quartz 配置集群环境的步骤比设置类似的 J2EE 集群环境容易的多:

1.  配置每个节点的 quartz.properties 文件。

2.  配置 JDBC JobStore

3.  使用 Scheduler 信息(Job 和 Trigger) 装载数据库。

4.  启动每个 Quartz 节点。

·配置节点的 quartz.properties 文件

就像是运行 Quartz 在非集群环境中那样,每个 Quartz 应用需要一个 quartz.properties 文件。在第三章,“Hello, Quartz” 中提到过,假如你不指定它,会使用默认的 quartz.properties 文件(存在于 quartz.jar 文件中)。最好是指定这个文件,因为你终究是需求修改一个或多个的设置项。

当使用 Quartz 的集群特性,你需要为每个节点修改 quartz.properties 文件。代码 11.1 显示了一个用于集群实例的 quartz.properties 文件的例子。属性将在之后讨论。

代码 11.1. 集群实例的 quartz.properties 文件示例

·配置主要的 Scheduler 属性

在这一节中有两个属性应该配置

    ·org.quartz.scheduler.instanceName

    ·org.quartz.scheduler.instanceId

这两属性用于多处,用在 JDBC JobStore 中和数据库来唯一标识实例。

集群时为实例 ID 使用 AUTOAUTO 为专门为集群准备的。不幸的是,在某些早期的版本,1.4.5 版所用的机制任何情况下都不会清理旧的实例 ID。1.5.1 版中有一些插入式的实例 ID 生成器,其中一个是基于节点的 IP 地址来生成 ID;只要你在一台给定的机器上仅有一个 Quartz 集群节点时这个生成器工作的很好。集群时应当使用 AUTO,因为很多人把 Quartz 放在 EAR 中,分布部署在集群的应用服务器上。这时候,EAR 中必然只有一个 quartz.properties 文件,因此它在所有的节点上是相同的。假如实例 ID 是硬编码的,Quartz 集群将不能正常工作,因为所有的节点有着一样的 ID。AUTO 就是为解决这个问题的。

一些其他严重的集群问题在 Quartz 1.5.1 被引入。如果你需要对 Quartz 集群,你或许该避免这个版本。

·配置 JobStore

为使用 Quartz 的集群,你需要用到 JobStoreTX 或者 JobStoreCMT 作为 Scheduler 的 JobStore。第六章,“Job 存储和持久化” 详细说明了如何设置和使用所提供的这两个 JDBC JobStore。从代码 11.1 中,你能发现和第六章所显示的设置是一样的,还有两个附加的属性:

    ·org.quartz.jobStore.isClustered

    ·org.quartz.jobStore.clusterChedkinInterval

通过设置 org.quartz.jobStore.isClustered 属性为 true,你就告诉了 Scheduler 实例要它参与到一个集群当中。这一属性会贯穿于调度框架的始终,用于修改集群环境中操作的默认行为。

org.quartz.jobStore.clusterCheckinInterval 属性定义了Scheduler 实例检入到数据库中的频率(毫秒为单位)。Scheduler 检查是否其他的实例到了它们应当检入的时候未检入;这能指出一个失败的 Scheduler 实例,且当前 Scheduler 会以此来接管任何执行失败并可恢复的 Job。通过检入操作,Scheduler 也会更新自身的状态记录。

clusterChedkinInterval 越小,Scheduler 节点检查失败的 Scheduler 实例就越频繁。默认值是 15000 (即15 秒)。

·配置 JobStore 的 数据源

因为你必须用 JDBC JobStore (JobStoreTXJobStoreCMT) 于集群中,你也需要配置一个不受管理的数据源(所谓 "不受管理的",我们意思是说数据源不受应用服务器管理)。看代码 11.1 中给 JobStoreTX 设置不受管理的数据源的例子。参考第六章中列出的可用属性和它们的允许值。

·使用 Scheduler 信息装载数据库

就如所有的使用数据库作为 Job 存储的 Quartz 应用一样,你必须加载 Job 信息到数据库中。我们在第六章已谈论过数种完成这个的方法。

其中一种方式是写一个配置经由 JDBC JobStore 使用数据库的独立的 Quartz 应用,创建一个 Scheduler 实例,部署所有的 Job 和 Trigger 信息。你可以让应用能通过传递一个参数给命令行来从数据库清除 Job 信息。这种用法的问题在于维护数据库变得非常笨拙的。

另一方式是使用你指定的 RDBMS 所带的查询工具来手工加载信息。这使得更新和删除相当容易,但是这在首次加载数据时可能有问题,除非你明确你正在做什么;我们强烈不建议这么做。

有人发现了使用在第十三章,“Quartz 和 Web 应用” 讨论的 Quartz Web 应用是一种很方便的做法。管理 Job 信息简单,甚至能由非技术性的资源来完成。看第十三章中关于 Quartz Wet 应用的内容,假如你选择这么做,也能够以类似的方式集成 Quartz 到你自己的 GUI 程序中来。

[译者 Unmi 注:对于最后一节的原文,感觉到一阵雾水洒过,仿佛说了个东西含含糊糊,不够明确,不具体。]

类别: Quartz. 标签: , . 阅读(304). 订阅评论. TrackBack.

Leave a Reply

Be the First to Comment!

avatar
wpDiscuz