Quartz Job Scheduling Framework［翻译］第六章. Job 存储和持久化 (第七部分)

十三. 改善持久性 JobStore 的性能

当在只有最少量时间做任何相关事情的时候，性能是一个广受人瞩目的课题。作为有经验的开发者，我们知道从项目之初它就成为一个需要考虑的事。

在使用 Quartz 的 JobStore 时，最大的关注面就是有关于与关系型数据库的交互。数据库 I/O(就像文件 I/O) 通常不是很快。你可以通过采取一些措施，如调优 SQL、增加索引和操作表和列等来改善性能。因为性能问题在写 Quartz 框架的时候就已有考虑到，而你又不想在未出现实际的性能问题时扎入到 Quartz 中做些手脚，那么可试图通过配置来解决它，或者尝试所有可能的方式，只要不是维护源代码。最好的消息是 Quartz 是开源的，你完全可以窥入其中了解它做了什么和如何实现的。假如你不喜欢它现有的查询数据库的方式，你有权去修正它。不过，在你采取行动之前，确定检查了 Quartz 论坛上的用户和开发者，看看是否其他人也遇到了相关的问题并浏览推荐的做法。

一个很简单(也是很有效的) 改善性能的方式是确保在所有适当的列上创建了索引。Quartz 所带的某些数据库创建脚本已有创建索引的命令。如果你的没有，你可以简单参考定义在 tables_oracle_sql 底端的语句并针对你的 RDBM 需要作些语法上改变。

不管你怎么做的，假如你修改了 Quartz 来改善性，一定要反馈到社区和 Quartz 项目。

十四. 创建新的 JobStore

对于多数用户，JobStore 所提供开箱即用的实现已是足够了。当你的应用在重启之间不需要维护状态，那么 RAMJobStore 就是你的第一选择。它速度快，易于配置，也不会带来什么麻烦。另一方面，如果你需要在重启之间维护 Scheduler 的状态，且正使用一个数据库或可以访问数据，那么用一个 JDBC JobStore 或许是你最后的选择。

那会在什么时候你需要一个完全不同的 JobStore 类型？你将需要创建一个新的类型。本节讨论几种途径，并针对如何创建一个新的 JobStore ，在所提供的方案无法满足你时给出一些主意。

·实现 JobStore 接口

无论它们是否是用的数据库、文件系统、甚至是内存，所有的 JobStore 必须实现 JobStore 接口。你创建的新的 JobStore 也不例外。回头看本章前面部分，你会发现 RAMJobStore 直接实现了 JobStore 接口，JDBC JobStore 是 JobStroeSupport 的子类，它本身实现了 JobStore 接口。

JobStore 接口有 40 个方法，它要求任何 JobStroe 实现都必须实现这些方法，你的也一样。你如何实现那些方法完全依赖于你正构建的 JobStore 的类型。那不是说你的 JobStore 将只能有 40 个方法；这仅仅是接口需要的最小数量。这 40 个方法体现 JobStore 和 Scheduler 之间的公共契约。

让我们拣出其中一个方法来简短的讨论它。我们就选 JobStore 接口方法：

public void schedulerStarted() throws SchedulerException;

Scheduler 调用 JobStore 的 SchedulerStarted() 方法去通知 JobStore Scheduler 已经启动了。如果你看了 RAMJobStore 的实现，你能发现它在这个方法实现中什么也没做：

public void schedulerStarted() throws SchedulerException{
    // nothing to do
}

然而，假如你去看那两个 JobStore 的实现，你会看到在 Scheduler 在首次启动时进行了一些工作：

每一个 JobStore 实现会是唯一的，在接口方法内部实现的功能也是不同的。如果你是认真的去创建你自己的 JobStore，你就应当好好看看 RAMJobStore 的源代码来完全理解 JobStore 所有职责。RAMJobStore 应该作为你需要定制任何 JobStore 时的指南。