For Java, it is recommended to use quartz. 1. Quartz is very convenient for doing various scheduled tasks. 2. It supports clusters. The principle is to ensure that the same task is only executed on one service through database tables.
Assuming you use it in the simplest wayquartz, then you need to modify it in the code and add the operation of acquiring the lock in the job logic. This lock can be applied to the database. The specific method is: insert a primary key record with business significance and execute , only one of the same jobs in the cluster will be inserted successfully, which means that it has obtained the lock and can be executed. Otherwise, the job will be exited and not executed.
You can make a middleware system that specifically manages the triggering of scheduled tasks and the subscription and consumption of messages. When the time is triggered, a message will be sent out, and the cluster system will subscribe to this message. Messages can be randomly delivered to any machine in the cluster.
When a machine starts timing, it must broadcast messages to other machines. But the time interval of each machine is a problem. Before the message is sent, they are all turned on regularly...
Use zookeeper, redis, etc. to manually store scheduled task execution status and other information to ensure that it is only executed once.
Extract scheduled tasks into a separate project (run on a single machine), but the specific content of the task calls specific distributed services through remote calls (dubbo, mq, etc.). That is to say, scheduled tasks are only used for task triggering alone, and specific tasks are executed in a distributed manner.
Use various distributed task scheduling systems, such as Uncode-Schedule
For Java, it is recommended to use quartz.
1. Quartz is very convenient for doing various scheduled tasks.
2. It supports clusters. The principle is to ensure that the same task is only executed on one service through database tables.
Assuming you use it in the simplest way
quartz
, then you need to modify it in the code and add the operation of acquiring the lock in the job logic. This lock can be applied to the database. The specific method is: insert a primary key record with business significance and execute , only one of the same jobs in the cluster will be inserted successfully, which means that it has obtained the lock and can be executed. Otherwise, the job will be exited and not executed.Configure Clustering with JDBC-JobStore
Quartz’s clustering features bring both high availability and scalability to your scheduler via fail-over and load balancing functionality.
quartz itself supports clustering, fault tolerance, and load balancing. This can be achieved without changing any code.
quartz framework supports clustering
You can make a middleware system that specifically manages the triggering of scheduled tasks and the subscription and consumption of messages. When the time is triggered, a message will be sent out, and the cluster system will subscribe to this message. Messages can be randomly delivered to any machine in the cluster.
When a machine starts timing, it must broadcast messages to other machines. But the time interval of each machine is a problem. Before the message is sent, they are all turned on regularly...
Use zookeeper, redis, etc. to manually store scheduled task execution status and other information to ensure that it is only executed once.
Extract scheduled tasks into a separate project (run on a single machine), but the specific content of the task calls specific distributed services through remote calls (dubbo, mq, etc.). That is to say, scheduled tasks are only used for task triggering alone, and specific tasks are executed in a distributed manner.
Use various distributed task scheduling systems, such as Uncode-Schedule
I tend to pull it out and make a stand-alone program