Lesson 11: Advanced (Enterprise) Features
Clustering
Clustering currently works with the JDBC-Jobstore (JobStoreTX or JobStoreCMT) and the TerracottaJobStore. Features include load-balancing and job fail-over (if the JobDetail’s “request recovery” flag is set to true).
集群目前与JDBC-Jobstore（JobStoreTX或JobStoreCMT）和TerracottaJobStore一起工作。特性包括负载平衡和作业故障转移（如果JobDetail的“请求恢复”标志被设置为true）。
Clustering With JobStoreTX or JobStoreCMT Enable clustering by setting the “org.quartz.jobStore.isClustered” property to “true”. Each instance in the cluster should use the same copy of the quartz.properties file. Exceptions of this would be to use properties files that are identical, with the following allowable exceptions: Different thread pool size, and different value for the “org.quartz.scheduler.instanceId” property. Each node in the cluster MUST have a unique instanceId, which is easily done (without needing different properties files) by placing “AUTO” as the value of this property.
通过设置“org.quartz.jobStore.isClustered”的属性为true，可以使用JobStoreTX或JobStoreCMT进行集群。集群中的每一个实例都应该使用相同的quartz属性文件副本。例外情况是使用相同的属性文件，但有以下允许的例外：不同的线程池大小，以及“org.quartz.scheduler.instanceId”的不同值。集群中的每个节点都必须有一个独特的instanceId，它可以很容易地完成（不需要不同的属性文件），将“AUTO”作为该属性的值。
Never run clustering on separate machines, unless their clocks are synchronized using some form of time-sync service (daemon) that runs very regularly (the clocks must be within a second of each other). See http://www.boulder.nist.gov/timefreq/service/its.htm if you are unfamiliar with how to do this.
Never fire-up a non-clustered instance against the same set of tables that any other instance is running against. You may get serious data corruption, and will definitely experience erratic behavior.
不要在隔离的机器上运行集群，除非它们的时钟是使用某种形式的时间同步服务（守护进程）来同步的，这种形式的时钟必须非常规律地运行（时钟必须在彼此之间的一秒内）。如果您不熟悉如何做这件事，请参阅http://www.boulder.nist.gov/timefreq/service/its.htm。
不要将非聚集的实例与任何其他实例所运行的同一组表进行触发。你可能会有严重的数据损坏，并且肯定会经历不稳定的行为。
Only one node will fire the job for each firing. What I mean by that is, if the job has a repeating trigger that tells it to fire every 10 seconds, then at 12:00:00 exactly one node will run the job, and at 12:00:10 exactly one node will run the job, etc. It won’t necessarily be the same node each time - it will more or less be random which node runs it. The load balancing mechanism is near-random for busy schedulers (lots of triggers) but favors the same node that just was just active for non-busy (e.g. one or two triggers) schedulers.
只有一个节点会在每次触发时触发该作业。我的意思是,如果工作有重复触发器告诉它每10秒触发,然后在12:00:00将运行一个节点工作,和12:00:10将运行一个节点工作,等等。每次都不一定是相同的节点,它或多或少会随机节点运行它。对于繁忙的调度程序（大量的触发器），负载平衡机制几乎是随机的，但是对于那些只是为非繁忙（例如一个或两个触发器）调度程序，一般在相同节点触发执行。
即：在同一个触发器在同一时间只可能在某个节点（集群的某个Quartz服务）来执行，不可能同一时间触发的任务在多个节点重复触发。
####Clustering With TerracottaJobStore Simply configure the scheduler to use TerracottaJobStore (covered in Lesson 9: JobStores), and your scheduler will be all set for clustering.
使用TerracottaJobStore的集群，可简单地配置调度程序使用TerracottaJobStore（在第9课在介绍），并且要将您的调度程序设置为集群。
You may also want to consider implications of how you setup your Terracotta server, particularly configuration options that turn on features such as persistence, and running an array of Terracotta servers for HA.
您还可能想要考虑如何设置Terracotta服务器，特别是启用持久性等特性的配置选项，以及为HA运行一组Terracotta服务器。
The Enterprise Edition of TerracottaJobStore provides advanced Quartz Where features, that allow for intelligent targeting of jobs to appropriate cluster nodes.
More information about this JobStore and Terracotta can be found at http://www.terracotta.org/quartz
TerracottaJobStore的企业版提供了高级Quartz的功能，允许将作业定向到适当的集群节点。
关于这个JobStore和Terracotta的更多信息可以在http://www.terracotta.org/quartz中找到。
JTA Transactions
As explained in Lesson 9: JobStores, JobStoreCMT allows Quartz scheduling operations to be performed within larger JTA transactions.
正如第9课所解释的：JobStoreCMT允许在较大的JTA事务中执行Quartz调度操作。
Jobs can also execute within a JTA transaction (UserTransaction) by setting the “org.quartz.scheduler.wrapJobExecutionInUserTransaction” property to “true”. With this option set, a a JTA transaction will begin() just before the Job’s execute method is called, and commit() just after the call to execute terminates. This applies to all jobs.
作业还可以通过设置“org.quartz.scheduler.wrapJobExecutionInUserTransaction”属性为true，来执行JTA事务（UserTransaction）。有了这个选项集，一个JTA事务就会在任务执行方法被调用之前 begin()，并且在调用执行终止之后commit()。这适用于所有的工作。
If you would like to indicate per job whether a JTA transaction should wrap its execution, then you should use the @ExecuteInJTATransaction annotation on the job class.
如果您想要在每个作业中指定是否使JTAtransaction生效，那么您应该在作业类上使用@executeinjtatransaction注释。
Aside from Quartz automatically wrapping Job executions in JTA transactions, calls you make on the Scheduler interface also participate in transactions when using JobStoreCMT. Just make sure you’ve started a transaction before calling a method on the scheduler. You can do this either directly, through the use of UserTransaction, or by putting your code that uses the scheduler within a SessionBean that uses container managed transactions.
除了Quartz在JTA事务中自动包装作业执行之外，在使用JobStoreCMT时，您在调度器接口上的调用也会参与事务。在调用调度程序之前，确保您已经启动了一个事务。您可以通过使用UserTransaction，或者通过使用容器管理事务的SessionBean中使用调度程序的代码来直接做到这一点。
Pasted from <http://www.quartz-scheduler.org/documentation/quartz-2.2.x/tutorials/tutorial-lesson-11.html>