JobStore负责跟踪您提供给调度器的所有“work data”:Jobs、triggers、calendars等。为您的Quartz调度器实例选择适当的JobStore是重要的一步。幸运的是，一旦你理解了它们之间的差异，这个选择应该是非常容易的。在属性文件(或对象)中声明调度程序应该使用哪个JobStore(以及它的配置设置)，并将其提供给用于生成调度程序实例的调度器工厂。
切勿在代码中直接使用JobStore实例。出于某种原因，许多人试图这样做。JobStore用于Quartz本身的幕后使用。您必须告诉Quartz（通过配置）使用哪个JobStore，但是您应该只使用代码中的Scheduler接口。
RAMJobStore
RAMJobStore是最简单的JobStore，它也是性能最高的（就CPU时间而言）。RAMJobStore以明显的方式得名：它将所有数据保存在RAM中。这就是它闪电般快速的原因，也是配置如此简单的原因。缺点是，当您的应用程序结束（或崩溃）时，所有调度信息都将丢失 - 这意味着RAMJobStore无法遵守作业和触发器上的“非易失性”设置。对于某些应用程序，这是可以接受的 - 甚至是所需的行为，但对于其他应用程序，这可能是灾难性的。
要使用RAMJobStore（假设您正在使用StdSchedulerFactory），只需将类名org.quartz.simpl.RAMJobStore指定为用于配置quartz的JobStore类属性：
配置Quartz以使用RAMJobStore
org.quartz.jobStore.class = org.quartz.simpl.RAMJobStore
您无需担心其他设置。
JDBCJobStore
JDBCJobStore也被恰当地命名 - 它通过JDBC将所有数据保存在数据库中。因此，配置比RAMJobStore要复杂一些，而且速度也不快。但是，性能缺点并不是非常糟糕，特别是如果您使用主键上的索引构建数据库表。在相当现代的具有良好LAN(LAN:局域网)（在调度程序和数据库之间）的机器上，检索和更新触发触发器的时间通常小于10毫秒。
JDBCJobStore几乎适用于任何数据库，它已广泛应用于Oracle，PostgreSQL，MySQL，MS SQLServer，HSQLDB和DB2。要使用JDBCJobStore，必须首先为Quartz创建一组数据库表以供使用。您可以在Quartz发行版的“docs / dbTables”目录中找到表创建SQL脚本。如果还没有适用于您的数据库类型的脚本，只需查看其中一个现有脚本，然后以您的数据库所需的任何方式对其进行修改。需要注意的一点是，在这些脚本中，所有表都以前缀“QRTZ_”开头（例如表“QRTZ_TRIGGERS”和“QRTZ_JOB_DETAIL”）。这个前缀实际上可以是你想要的任何东西，只要你通知JDBCJobStore前缀是什么（在你的Quartz属性中）。对于多个调度程序实例，使用不同的前缀对于创建多组表可能很有用，
一旦创建了表，在配置和启动JDBCJobStore之前，还有一个重要的决定。您需要确定应用程序所需的事务类型。如果您不需要将调度命令（例如添加和删除触发器）绑定到其他事务，那么您可以让Quartz使用JobStoreTX作为JobStore 来管理事务（这是最常见的选择）。
如果您需要Quartz与其他事务一起工作（即在J2EE应用程序服务器中），那么您应该使用JobStoreCMT - 在这种情况下，Quartz将让app服务器容器管理事务。
最后一个难题是设置一个DataSource，JDBCJobStore可以从中获取与数据库的连接。DataSources是使用几种不同方法之一在Quartz属性中定义的。一种方法是让Quartz创建和管理DataSource本身 - 通过提供数据库的所有连接信息。另一种方法是让Quartz使用由Quartz在其中运行的应用程序服务器管理的DataSource - 通过向JDBCJobStore提供DataSource的JNDI名称。有关这些属性的详细信息，请参阅“docs / config”文件夹中的示例配置文件。
要使用JDBCJobStore（并假设您正在使用StdSchedulerFactory），首先需要将Quartz配置的JobStore类属性设置为org.quartz.impl.jdbcjobstore.JobStoreTX或org.quartz.impl.jdbcjobstore.JobStoreCMT - 具体取决于您根据上面几段中的解释做出的选择。
Configuring Quartz to use JobStoreTx
org.quartz.jobStore.class = org.quartz.impl.jdbcjobstore.JobStoreTX
接下来，您需要为JobStore选择要使用的DriverDelegate。DriverDelegate负责执行特定数据库可能需要的任何JDBC工作。StdJDBCDelegate是一个委托，它使用“vanilla”JDBC代码（和SQL语句）来完成它的工作。如果没有专门为您的数据库制作的另一个委托，请尝试使用此委托 - 我们只为使用StdJDBCDelegate发现问题的数据库创建了特定于数据库的委托（这似乎是最多的！）。其他代表可以在“org.quartz.impl.jdbcjobstore”包中找到，也可以在其子包中找到。其他委托包括DB2v6Delegate（用于DB2版本6及更早版本），HSQLDBDelegate（用于HSQLDB），MSSQLDelegate（用于Microsoft SQLServer），PostgreSQLDelegate（用于PostgreSQL），WeblogicDelegate（用于使用由Weblogic制作的JDBC驱动程序），
选择委托后，将其类名设置为JDBCJobStore要使用的委托。
Configuring JDBCJobStore to use a DriverDelegate
org.quartz.jobStore.driverDelegateClass = org.quartz.impl.jdbcjobstore.StdJDBCDelegate
接下来，您需要通知JobStore您正在使用的表前缀（如上所述）。
Configuring JDBCJobStore with the Table Prefix
org.quartz.jobStore.tablePrefix = QRTZ_
最后，您需要设置JobStore应该使用哪个DataSource。还必须在Quartz属性中定义命名的DataSource。在这种情况下，我们指定Quartz应该使用DataSource名称“myDS”（在配置属性中的其他位置定义）。
Configuring JDBCJobStore with the name of the DataSource to use
org.quartz.jobStore.dataSource = myDS
如果您的调度程序繁忙（即几乎总是执行与线程池大小相同的作业数，那么您应该将DataSource中的连接数设置为大约线程池的大小+ 2。
“org.quartz.jobStore.useProperties”配置参数可以设置为“true”（默认为false），以指示JDBCJobStore JobDataMaps中的所有值都是字符串，因此可以存储为名称 - 值对，而不是在BLOB列中以序列化形式存储更复杂的对象。从长远来看，这样更安全，因为您可以避免将非String类序列化为BLOB时出现的类版本问题。
TerracottaJobStore
TerracottaJobStore提供了一种无需使用数据库的伸缩和健壮性的方法。这意味着您的数据库可以不受Quartz的负载影响，而是可以将其所有资源保存到应用程序的其余部分。
TerracottaJobStore可以运行群集或非群集，并且在任何一种情况下都可以为应用程序重新启动之间持久的job data 提供存储介质，因为数据存储在Terracotta服务器中。它的性能比通过JDBCJobStore使用数据库要好得多（大约更好一个数量级），但比RAMJobStore慢得多。
要使用TerracottaJobStore（假设您正在使用StdSchedulerFactory），只需将类名org.quartz.jobStore.class = org.terracotta.quartz.TerracottaJobStore指定为用于配置quartz的JobStore类属性，并添加一行额外的配置以指定Terracotta服务器的位置：
Configuring Quartz to use TerracottaJobStore
org.quartz.jobStore.class = org.terracotta.quartz.TerracottaJobStore
org.quartz.jobStore.tcConfigUrl = localhost:9510
有关此JobStore和Terracotta的更多信息， 请访问http://www.terracotta.org/quartz
貌似也可以参考： https://www.w3cschool.cn/quartz_doc/quartz_doc-m4ao2doh.html