opening

Daily business development often has delayed trigger requirements, such as common orders created for a period of time not paid, will automatically trigger closure; Registered users within a period of time did not improve the information, can trigger reminder information update. This requirement is the application scenario of delayed scheduling.

This paper proposes a method to implement distributed delay scheduling and provides a design idea for children’s shoes that need delay scheduling design.

Implementation one, QelayQueue scheduling implementation

DelayQueue is an efficient memory delay blocking queue that can delay firing within a single Java process by adding delay fetching time to task elements.

Advantages:

  1. Delayed tasks can be triggered precisely.

Disadvantages:

  1. Supports scheduling within a single process, which cannot be supported in distributed scenarios.
  2. DelayQueue is a memory queue. Tasks may be lost when a process breaks down or restarts.

Realization of two, cycle task + database

Writing a task record to a database and using a fixed cycle to load a delayed task from the database and execute it is a relatively simple but violent approach to practice.

Advantages:

  1. Task records are written to the database to prevent task loss caused by process crashes.

Disadvantages:

  1. Periodic task scanning, critical task may lead to one more cycle delay trigger;
  2. If you set the period to very low (such as 1s), it will burden the database.

Implement three, periodic task + DelayQueue + database

Another idea:

  1. Set a delay threshold, such as 5m;
  2. All delayed task records are written to the database first;
  3. Tasks whose delay time is within the threshold are directly queued in DelayQueue and triggered when they expire.
  4. Each time the task in the next period is scanned and the DelayQueue is loaded. When the task expires, the DelayQueue is triggered.

The preceding operations ensure that all tasks within the latest delay threshold are queued in the DelayQueue waiting to be triggered. Note that task records need to be stateless. Status updates are required for “Create”, “Queue”, “trigger succeeded”, and “trigger failed” to avoid repeated task execution.

The realization process can be referred to the following figure:

Advantages:

  1. Delayed tasks can be triggered precisely
  2. Task records are written into the database to prevent task loss caused by process crash.
  3. Periodic load delay tasks do not need to be executed frequently, reducing the database burden.

Disadvantages:

  1. Periodic load delay tasks are managed in-process (without distributed coordination) and may be executed multiple times in multi-point deployment scenarios, requiring additional contention.

Quartz + DelayQueue + database implementation

To solve the problem of multiple execution of tasks that are periodically loaded and delayed within a process in implementation 3, Quartz can be introduced for task management to ensure that the same task can be executed only on one machine in multi-point deployment, thus solving the problem of multiple execution of tasks in multi-point deployment. The realization process can be referred to the following figure:

Advantages:

  1. Delayed tasks can be triggered precisely;
  2. Delayed task persistence ensures that no task is lost.
  3. No high frequency polling operation, will not cause a burden to the database;
  4. This implementation is perfectly adequate for systems with small business volumes.

Consider a scenario where a large number of tasks need to be triggered in a second, and Quartz only allows lazy task loading on one node (Quartz does not support task sharding, only failure drift), can delayed tasks be triggered precisely?

Five, distributed scheduling + DelayQueue + database

Distributed scheduling systems (XXl-job, Elastice-job, and TB-schedule) all support task fragmentation. Therefore, the distributed scheduling system is used instead of Quartz, and the fragmentation policy is used for periodic tasks. In this way, different delayed tasks can be loaded with fragmented information on a multi-machine cluster. In this way, we can give full play to the parallel computing capability of multiple machines and ensure the accuracy of delay triggering as much as possible.

Some of the team

  • Delayed record bloat in the database

Task records accumulate over time, and the records of delayed tasks in the database swell. Based on the delayed task feature, records are generally triggered in a relatively short period of time. Therefore, after the task is triggered successfully, records can be moved to the history, and only the tasks that are not triggered or fail to be triggered can be stored in the current library. In this way, the amount of data in the current library can be reduced to improve the query performance on the task table. Of course, there can also be sub-database sub-table and other technical solutions can be considered.

  • Handle task compensation for clear failures

For a task that fails to trigger, it is meaningless to trigger accurately. Compensation can be performed onsite (using tools such as Spring-Retry and idempotency of compensation callback), and another thread compensation task can be started to scan the delay task record table periodically.

  • Handle compensation for process crashes and restarts

For tasks in the “create” or “queue” states for a long time, set a certain threshold (for example, 10 MB). If the threshold period exceeds the trigger time, the task is considered to have failed and can be compensated separately.

conclusion

This paper provides an idea, combined with external scheduling, Java delay blocking queue, database, design a relatively lightweight technology implementation. Can realize delayed task persistence, do not lose, but also support the precise triggering of large quantities of tasks.

End.