Quartz-cluster Best Practices

1. Overview

While a single quartz instance can give you a good job scheduling capability, it does not meet typical enterprise requirements, such as scalability and high reliability. If you need the ability to fail over and run an ever-increasing number of job,quartz clusters, it's bound to be part of your application. Using Quartz's clustering capabilities can better support your business needs and ensure that all jobs are executed even if one of the machines crashes at the worst possible time.

2. Working principle

Each node in a Quartz cluster is a standalone Quartz application that manages other nodes. It means you have to start or stop each node individually. Unlike many application server clusters, a standalone Quartz node does not communicate with another node or management node. The Quartz application is perceived by a database table to another application.
Figure: Indicates that each node communicates directly with the database, leaving the database unaware of the other nodes

3. Environment Construction

3.1. Create a Quartz database table

Because the quartz cluster relies on the database, you must first create the Quartz database table. Quartz includes SQL scripts for all supported database platforms. Find those SQL scripts in the <quartz_home>/docs/dbtables directory, where <quartz_home> is the directory after extracting the quartz bundle.
Here the Quartz 1.6.0 version, a total of 12 tables, different versions, the number of tables may be different. The database is MySQL and the database table is created with Tables_mysql_innodb.sql.

3.2. Configure the database connection pool

1. Configuring the Jdbc.properties File

2. Configuring the Applicationcontext.xml File

3.3. Configure the Quartz.properties file for the cluster node

Description

The Org.quartz.scheduler.instanceName property can be used in JDBC Jobstore to uniquely identify an instance for any value, but must be the same across all cluster nodes.

The Org.quartz.scheduler.instanceId property is auto, which generates the instance ID based on the host name and timestamp.

The Org.quartz.jobStore.class property is Jobstoretx, which persists the task to the data. Because nodes in a cluster rely on databases to propagate the state of Scheduler instances, you can only apply Quartz clusters when using JDBC Jobstore. This means that you must use JOBSTORETX or JOBSTORECMT as the Job store; you cannot use Ramjobstore in a cluster.

The Org.quartz.jobStore.isClustered property is true, and you tell the Scheduler instance to participate in a cluster. This property is always used throughout the scheduling framework to modify the default behavior of operations in a clustered environment.

The Org.quartz.jobStore.clusterCheckinInterval property defines the frequency, in milliseconds, that the scheduler instance is checked into the database. Scheduler Check if other instances are not checked in when they should be checked in; This can indicate a failed Scheduler instance, and the current Scheduler will take over any Job that fails and is recoverable. With the check-in operation, Scheduler also updates its own status record. The smaller the clusterchedkininterval, the more frequently the Scheduler node checks for Scheduler instances that fail. The default value is 15000 (that is, 15 seconds).

3.4. Create the Job service class

Description

Because the job needs to be persisted into the database, Custservice must implement the Serializable interface, where it simply prints the log.

But here's a question, if our custservice is going to inherit other base classes, and the base class is not serialized, then Custservice still can't persist into the database. So we need to add a layer of business reference outside of Custservice, Custservice as an object into the reference layer, see the code in detail:

1 Business Reference Layer Mybusijob.java

2 implementation of the serialization interface Job2

3 Task Guidance

3.5. Integration with spring (2.0.8)

Applicationcontext-quartz.xml

Description

1 This Methodinvokingjobdetailfactorybean, Org.springframework.scheduling.quartz.MethodInvokingJobDetailFactoryBean should be used to specify classes and methods, but direct use will be reported JAVA.IO.NOTSERIALIZABLEEXCEP tion exceptions, because the MethodInvoking method in this class does not support serialization, so it is wrong to serialize the QUARTZ TASK into the database. and currently the latest version of spring does not support this issue. Here we use the revised class substitution in the spring official forum, which you can refer to:

http://jira.springframework.org/browse/SPR-3797

3.6. Test class

Test results:

Several nodes have quartz tasks, at which time only one quartz is running and quartz on the other nodes is not running.

At this time manually shutdown that run QUARTZ, after about 7 seconds, the other node's QUARTZ automatically monitored the QUARTZ in the cluster running instance has shutdown, so QUARTZ cluster will automatically put any available app on Initiates the task of a quartz job.

The following two images are tasks distributed under quartz-cluster normal operation

Environment:

WebLogic 10.3.5 + Redhat 5.6 + Quartz 1.6.0 + Spring 2.0.8

4. Deployment

There are two points to note:

1 cluster configuration file Quartz.properties deployment must be consistent

2 after the cluster is established, if you need to modify the strategy of the Quartz scheduler during the operation, for example: once every 5 days, it is now going to be executed every half month, this time to modify all the configuration files, and to re-execute the above database script!

Quartz-cluster Best Practices