第10课小结：
在Quartz完成其工作之前需要配置的主要组件是：
• ThreadPool
• JobStore
• DataSources (if necessary)
• The Scheduler itself
一、ThreadPool
ThreadPool提供了一组用于Quartz在执行作业时使用的线程。池中的线程越多，可以并发运行的作业数量就越多。调度程序池找到合适的大小完全取决于您使用调度程序做什么。没有真正的规则，除了保持线程的数量尽可能小（为了您的机器的资源），但是也要确保您有足够的线程让您的工作按时进行。如果触发器的触发时间已至，并且没有可用的线程，Quartz将阻塞（暂停）直到线程可用为止。如果在调度器配置的“misfire threshold”期间没有可用的线程，这甚至可能导致线程被misfire。
ThreadPool的实现类，Quartz附带一个简单的（但非常令人满意的）线程池SimpleThreadPool，这个ThreadPool只是在它的池中维护一组固定的线程——永远不会增长，不会收缩。但它在其他方面都相当健壮，而且经过了很好的测试——几乎每个使用Quartz的人都使用这个池。
二、JobStores 和 DataSources ：参考前一章
三、Scheduler
您需要创建Scheduler 实例。Scheduler本身需要给它一个名称，告诉它的RMI设置，并传递一个JobStore和ThreadPool的实例。
StdSchedulerFactory 是一个org.quartz.SchedulerFactory接口的实现。它使用一整套属性（java.util.properties）来创建和初始化一个Quartz 调度程序。这些属性通常存储在一个文件中并从文件中加载，但是也可以由程序创建并直接传递给工厂。简单地在工厂调用getScheduler（）将生成调度程序，初始化它（及它的ThreadPool、JobStore和DataSources），并返回其公共接口的句柄。
DirectSchedulerFactory 是另一个SchedulerFactory 实现。对于那些希望以更程序化的方式创建调度程序实例的人来说，这是很有用的。它的使用通常是不受鼓励的，原因如下：（1）它要求用户对他们正在做的事情有更深入的理解，（2）它不允许声明式配置——或者换句话说，您最终会硬编码所有调度器的设置。
四、Logging
Quartz使用SLF4J框架来满足所有的日志记录需求。为了“调优”日志设置（比如输出量和输出的位置），您需要理解SLF4J框架。
Lesson 10: Configuration, Resource Usage and SchedulerFactory
The architecture of Quartz is modular, and therefore to get it running several components need to be “snapped” together. Fortunately, some helpers exist for making this happen.
The major components that need to be configured before Quartz can do its work are:
- ThreadPool
- JobStore
- DataSources (if necessary)
- The Scheduler itself
Quartz的架构是模块化的，因此要获取运行的几个组件需要一起被“快照”。幸运的是，有一些辅助工具是为了实现这一目标而存在的。在Quartz完成其工作之前需要配置的主要组件是：
- ThreadPool
- JobStore
- DataSources (if necessary)
- The Scheduler itself
The ThreadPool provides a set of Threads for Quartz to use when executing Jobs. The more threads in the pool, the greater number of Jobs that can run concurrently. However, too many threads may bog-down your system. Most Quartz users find that 5 or so threads are plenty- because they have fewer than 100 jobs at any given time, the jobs are not generally scheduled to run at the same time, and the jobs are short-lived (complete quickly). Other users find that they need 10, 15, 50 or even 100 threads - because they have tens-of-thousands of triggers with various schedules - which end up having an average of between 10 and 100 jobs trying to execute at any given moment. Finding the right size for your scheduler’s pool is completely dependent on what you’re using the scheduler for. There are no real rules, other than to keep the number of threads as small as possible (for the sake of your machine’s resources) - but make sure you have enough for your Jobs to fire on time. Note that if a trigger’s time to fire arrives, and there isn’t an available thread, Quartz will block (pause) until a thread comes available, then the Job will execute - some number of milliseconds later than it should have. This may even cause the thread to misfire - if there is no available thread for the duration of the scheduler’s configured “misfire threshold”.
ThreadPool提供了一组用于Quartz在执行作业时使用的线程。池中的线程越多，可以并发运行的作业数量就越多。然而，太多的线程可能会对您的系统造成影响。大多数Quartz用户发现5个左右的线程是足够的——因为他们在任何给定的时间都有不到100个工作，所以工作通常不会同时运行，而且工作是短暂的（很快就完成了）。其他用户发现他们需要10个、15个、50个甚至100个线程——因为他们有成千上万的触发器在不同的schedules上——这最终导致平均有10到100个工作在任何给定的时刻执行。为调度程序池找到合适的大小完全取决于您使用调度程序做什么。没有真正的规则，除了保持线程的数量尽可能小（为了您的机器的资源），但是也要确保您有足够的线程让您的工作按时进行。注意，如果触发器的触发时间已至，并且没有可用的线程，Quartz将阻塞（暂停）直到线程可用为止，然后作业将执行——比它应该的执行的时间晚一些。如果在调度器配置的“misfire threshold”期间没有可用的线程，这甚至可能导致线程被misfire。
A ThreadPool interface is defined in the org.quartz.spi package, and you can create a ThreadPool implementation in any way you like. Quartz ships with a simple (but very satisfactory) thread pool named org.quartz.simpl.SimpleThreadPool. This ThreadPool simply maintains a fixed set of threads in its pool - never grows, never shrinks. But it is otherwise quite robust and is very well tested - as nearly everyone using Quartz uses this pool.
ThreadPool接口是在org.quartz.spi包中定义的。您可以以任何您喜欢的方式创建ThreadPool接口的实现类。Quartz附带一个简单的（但非常令人满意的）线程池，名为org.quartz.simpl.SimpleThreadPool。这个ThreadPool只是在它的池中维护一组固定的线程——永远不会增长，不会收缩。但它在其他方面都相当健壮，而且经过了很好的测试——几乎每个使用Quartz的人都使用这个池。
JobStores and DataSources were discussed in Lesson 9 of this tutorial. Worth noting here, is the fact that all JobStores implement the org.quartz.spi.JobStore interface - and that if one of the bundled JobStores does not fit your needs, then you can make your own.
在本教程的第9部分中讨论了JobStores 和DataSources 。值得注意的是，所有的JobStores 都实现了org.quartz.spi.JobStore接口——如果其中一个捆绑的JobStores不符合您的需求，那么您可以自己创建。
Finally, you need to create your Scheduler instance. The Scheduler itself needs to be given a name, told its RMI settings, and handed instances of a JobStore and ThreadPool. The RMI settings include whether the Scheduler should create itself as a server object for RMI (make itself available to remote connections), what host and port to use, etc.. StdSchedulerFactory (discussed below) can also produce Scheduler instances that are actually proxies (RMI stubs) to Schedulers created in remote processes.
最后，您需要创建Scheduler 实例。Scheduler本身需要给它一个名称，告诉它的RMI设置，并传递一个JobStore和ThreadPool的实例。RMI设置包括调Scheduler是否应该将自己创建为RMI的服务器对象（使其本身可以让远程连接调用）、使用何种主机和端口等等。StdSchedulerFactory （下文讨论）也可以生成Scheduler 实例，这些实例实际上是为远程过程中创建的Schedulers 的代理（RMI存根）。
StdSchedulerFactory
StdSchedulerFactory is an implementation of the org.quartz.SchedulerFactory interface. It uses a set of properties (java.util.Properties) to create and initialize a Quartz Scheduler. The properties are generally stored in and loaded from a file, but can also be created by your program and handed directly to the factory. Simply calling getScheduler() on the factory will produce the scheduler, initialize it (and its ThreadPool, JobStore and DataSources), and return a handle to its public interface.
StdSchedulerFactory 是一个org.quartz.SchedulerFactory接口的实现。它使用一整套属性（java.util.properties）来创建和初始化一个Quartz 调度程序。这些属性通常存储在一个文件中并从文件中加载，但是也可以由程序创建并直接传递给工厂。简单地在工厂调用getScheduler（）将生成调度程序，初始化它（及它的ThreadPool、JobStore和DataSources），并返回其公共接口的句柄。
There are some sample configurations (including descriptions of the properties) in the “docs/config” directory of the Quartz distribution. You can find complete documentation in the “Configuration” manual under the “Reference” section of the Quartz documentation.
在Quartz发行版的“doc/config”目录中有一些样例配置（包括属性的描述）。您可以在Quartz文档“参考”部分的“配置”手册中找到完整的文档。
DirectSchedulerFactory
DirectSchedulerFactory is another SchedulerFactory implementation. It is useful to those wishing to create their Scheduler instance in a more programmatic way. Its use is generally discouraged for the following reasons: (1) it requires the user to have a greater understanding of what they’re doing, and (2) it does not allow for declarative configuration - or in other words, you end up hard-coding all of the scheduler’s settings.
DirectSchedulerFactory 是另一个SchedulerFactory 实现。对于那些希望以更程序化的方式创建调度程序实例的人来说，这是很有用的。它的使用通常是不受鼓励的，原因如下：（1）它要求用户对他们正在做的事情有更深入的理解，（2）它不允许声明式配置——或者换句话说，您最终会硬编码所有调度器的设置。
Logging
Quartz uses the SLF4J framework for all of its logging needs. In order to “tune” the logging settings (such as the amount of output, and where the output goes), you need to understand the SLF4J framework, which is beyond the scope of this document.
Quartz使用SLF4J框架来满足所有的日志记录需求。为了“调优”日志设置（比如输出量和输出的位置），您需要理解SLF4J框架，这超出了本文档的范围。
If you want to capture extra information about trigger firings and job executions, you may be interested in enabling the org.quartz.plugins.history.LoggingJobHistoryPlugin and/or org.quartz.plugins.history.LoggingTriggerHistoryPlugin.
如果您想要获取关于触发器触发和作业执行的额外信息，您可能会对启用rg.quartz.plugins.history.LoggingJobHistoryPlugin 和/或org.quartz.plugins.history.LoggingTriggerHistoryPlugin感兴趣。
quartz.properties示例：
#============================================================================
# Configure Main Scheduler Properties
#============================================================================
org.quartz.scheduler.instanceName: TestScheduler
org.quartz.scheduler.instanceId: AUTO
org.quartz.scheduler.skipUpdateCheck: true
#============================================================================
# Configure ThreadPool
#============================================================================
org.quartz.threadPool.class: org.quartz.simpl.SimpleThreadPool
org.quartz.threadPool.threadCount: 12
org.quartz.threadPool.threadPriority: 5
#============================================================================
# Configure JobStore
#============================================================================
org.quartz.jobStore.misfireThreshold: 60000
org.quartz.jobStore.class: org.quartz.simpl.RAMJobStore
#org.quartz.jobStore.class: org.quartz.impl.jdbcjobstore.JobStoreTX
#org.quartz.jobStore.driverDelegateClass: org.quartz.impl.jdbcjobstore.PostgreSQLDelegate
#org.quartz.jobStore.useProperties: false
#org.quartz.jobStore.dataSource: myDS
#org.quartz.jobStore.tablePrefix: QRTZ_
#org.quartz.jobStore.isClustered: false
#============================================================================
# Configure Datasources
#============================================================================
#org.quartz.dataSource.myDS.driver: org.postgresql.Driver
#org.quartz.dataSource.myDS.URL: jdbc:postgresql://localhost/dev
#org.quartz.dataSource.myDS.user: jhouse
#org.quartz.dataSource.myDS.password:
#org.quartz.dataSource.myDS.maxConnections: 5
Pasted from <http://www.quartz-scheduler.org/documentation/quartz-2.2.x/tutorials/tutorial-lesson-10.html>