Quartz的架构是模块化的，因此为了让它运行几个组件需要“拼凑”在一起。幸运的是，有一些类可以帮助你做到这一点。
在Quartz开始工作之前需要配置的主要组件有：
- ThreadPool
- JobStore
- DataSources（如果必要的话）
- Scheduler本身
ThreadPool提供了Quartz执行任务时需要使用的线程。线程池中的线程越多，可以并发执行的任务数就越大。但是，太多的线程可能会让系统崩溃。大多数Quartz用户发现大约5个线程就足够用——因为它们在任何时候的任务都不超过100个，而且这些工作通常不会同时运行且运行的很快。其他用户发现他们需要10个、15个、50个甚至100个线程——因为他们有成千上万的触发器且最终每刻大概有10~100个任务同时执行。你的线程池的合适大小完全取决于你要如何使用调度器。这个没有真正的规则，除了保持尽可能小的线程数量（为了节省机器资源）——但是确保你又足够的线程让你的任务去触发运行。请注意，如果触发器的触发时间到了，并且没有可用线程，则Quartz将阻塞（暂停），直到线程可用，然后执行作业——比它应该执行的时间晚数毫秒。这甚至可能导致线程misfire——如果等待时间超过了配置的“misfire threshold”。
ThreadPool接口在org.quartz.spi包中定义，您可以使用任何您喜欢的方式创建ThreadPool实现。Quartz附带一个简单的（但非常令人满意的）名为org.quartz.simpl.SimpleThreadPool的线程池。这个ThreadPool只是在其池中维护一组固定的线程 - 永远不会增长，永远不会缩小。但它是相当强大的，并且经过很好的测试 - 几乎每个使用Quartz的人都使用这个池。
JobStores和DataSources在课程9中讨论过。值得一提的是，所有JobStore都实现了org.quartz.spi.JobStore接口 - 如果其中一个捆绑的JobStore不适合您的需求，那么您可以自己创建。
最后，你需要创建你的Scheduler实例。调度程序本身需要被赋予一个名字，告诉它的RMI设置，并递交一个JobStore和ThreadPool的实例。RMI设置包括调度程序是否应将其自身创建为RMI的服务器对象（使其可用于远程连接），要使用的主机和端口等。StdSchedulerFactory（下面讨论）还可以生成Scheduler实例，这些实例实际上是对远程进程中创建的调度程序的代理（RMI存根）。
StdSchedulerFactory
StdSchedulerFactory是org.quartz.SchedulerFactory接口的实现。它使用一组属性（java.util.Properties）来创建和初始化Quartz Scheduler。这些属性通常存储在文件中并从文件加载，但也可以由程序创建并直接传送到工厂。只需在工厂调用getScheduler()将生成调度程序，对其进行初始化（及其ThreadPool，JobStore和DataSources），并返回其公共接口的引用。
Quartz发行版的“docs / config”目录中有一些示例配置（包括属性的说明）。您可以在Quartz文档的“Reference”部分的“Configuration”手册中找到完整的文档。
DirectSchedulerFactory
DirectSchedulerFactory是另一个SchedulerFactory实现。对于那些希望以更加程序化的方式创建其调度程序实例的人来说非常有用。但由于以下原因，通常不鼓励使用它：（1）它要求用户必须很明确它们自己在做什么，（2）它不允许进行声明式配置 - 或者换句话说，您最终会对所有调度程序的设置进行硬编码。
Logging
Quartz使用SLF4J框架满足所有的日志需求。为了“调整”日志设置（例如输出量和输出位置），您需要了解SLF4J框架，这超出了本文的范围。
如果您想捕获关于触发触发和作业执行的额外信息，您可能有兴趣启用org.quartz.plugins.history.LoggingJobHistoryPlugin
和/或org.quartz.plugins.history.LoggingTriggerHistoryPlugin