This article refers to http://www.cnblogs.com/davidwang456/p/4205237.html and https://blog.csdn.net/guolong1983811/article/details/51501346
1 Cluster Architecture
The distributed architecture of Quartz is shown in the figure above. You can see that the database is the hub of the scheduler on each node. Each node does not perceive the existence of other nodes, and only communicates indirectly through the database.
In fact, Quartz's distributed strategy is a concurrency strategy with the database as the boundary resource. Each node abides by the same operating specifications, so that the operations on the database can be executed serially. Schedulers with different names can run in parallel without affecting each other.
2 Scheduling mechanism
2.1 Task scheduling communication mechanism
Quartz runtime has four main roles: QuartzSchedulerThread class as the main body, which executes the scheduling process cyclically; JobStore as the middle layer, performs database operations according to quartz's concurrency strategy and completes the main scheduling logic; JobRunShellFactory is responsible for instantiating the JobDetail object and placing it in The thread pool runs; LockHandler is responsible for acquiring database locks in the LOCKS table.
2.2 Task scheduling process
0. Scheduler thread run()
1. Get the trigger to be triggered
1.1 Database LOCKS table TRIGGER_ACCESS row lock
1.2 Read JobDetail information
1.3 Read the trigger information in the trigger table and mark it as "acquired"
1.4 commit transaction, release lock
2. Trigger trigger
2.1 Database LOCKS table STATE_ACCESS row lock
2.2 Confirm the status of trigger
2.3 Read the JobDetail information of trigger
2.4 Read the Calendar information of trigger
2.5 Update trigger information
2.6 commit transaction, release lock
3 Instantiate and execute the Job
3.1 Get the thread from the thread pool to execute the run method of JobRunShell
2.3 Task scheduling sequence
2.4 Trigger state changes
