Various Strategies for Deploying Distributed Scheduled Tasks on a Single Server

1. Deploy the scheduled‑task code on a single server

Advantages: Simple to understand.

Disadvantages: Deployment is cumbersome because multiple code bases are needed, and if that server fails the scheduled task stops working.

2. Add an IP‑based restriction to the scheduled‑task code so that only a specific server can run it

Advantages: Easy to understand, simple deployment, no need for multiple code bases.

Disadvantages: Same as above – only one server can run the task; if it fails the task is lost.

3. Create multiple tables in the database and fetch the scheduled method from a task table

Method: Because MySQL provides table locks and row locks (MyISAM only supports table locks, InnoDB supports both), each execution reads a record from the task table. The current machine triggers the task only when the record’s status is “not executed”, then updates the status (update first, then execute). The lock guarantees that only one transaction can operate at a time, ensuring a single execution.

Pros & Cons: This approach is suitable but requires additional tables and significant changes to the existing scheduler logic.

Reference: https://blog.csdn.net/xiao_2317/article/details/51765457

4. Use Redis expiration mechanism and a distributed lock

Method: Define a key‑value pair in Redis for the scheduler (e.g., project name + server IP). Before executing, read the key; if it does not exist, the task is considered not executed. The server updates Redis first, then triggers the task. The expiration feature allows setting a timeout to ensure normal re‑evaluation later.

Pros & Cons: This method is recommended for its simplicity and minimal impact on business logic; only a small conditional check needs to be added to the existing scheduler.

Reference: https://www.cnblogs.com/ztfjs/p/redis-lock.html https://www.jianshu.com/p/48c5b11b80cd

5. Apply Quartz clustering

Method: If the project uses Spring’s built‑in Task scheduler, the Quartz framework already supports clustered environments. You can set up a Quartz cluster to run the scheduler, which solves the single‑execution problem, but it requires configuring around eleven database tables.

Pros & Cons: The main drawback is the heavy configuration effort due to the large number of tables.

Reference: https://www.cnblogs.com/jiafuwei/p/6145280.html

Thank you for reading, hope this helps :)

Source: blog.csdn.net/weixin_42754512/article/details/109197168