cron vs node-schedule vs node-cron vs bull vs agenda vs bree vs later
Node.js 定时任务库
cronnode-schedulenode-cronbullagendabreelater类似的npm包:
Node.js 定时任务库

定时任务库用于在 Node.js 中调度和执行定时任务。这些库提供了不同的功能和灵活性,帮助开发者在特定时间或间隔执行任务。它们适用于需要定期执行的任务,如发送电子邮件、清理数据库、生成报告等。选择合适的库可以提高应用程序的效率和可维护性。

npm下载趋势
3 年
GitHub Stars 排名
统计详情
npm包名称
下载量
Stars
大小
Issues
发布时间
License
cron3,627,6558,875161 kB171 个月前MIT
node-schedule2,902,9549,22835 kB1713 年前MIT
node-cron1,867,5143,211221 kB266 个月前ISC
bull1,046,42016,215309 kB1471 年前MIT
agenda130,8249,595353 kB355-MIT
bree28,4313,24890.5 kB287 天前MIT
later24,5262,420-9910 年前MIT
功能对比: cron vs node-schedule vs node-cron vs bull vs agenda vs bree vs later

持久化任务

  • cron:

    Cron 不支持持久化任务,适合简单的定时任务,任务信息在内存中。

  • node-schedule:

    Node-Schedule 不支持持久化任务,适合灵活的调度需求。

  • node-cron:

    Node-Cron 不支持持久化任务,适合轻量级的定时任务。

  • bull:

    Bull 支持持久化任务,任务信息存储在 Redis 中,确保任务的可靠性和持久性。

  • agenda:

    Agenda 提供了持久化任务的功能,任务信息存储在 MongoDB 中,确保任务在应用重启后仍然存在。适合需要高可靠性的任务调度。

  • bree:

    Bree 不支持持久化任务,任务在内存中执行,适合轻量级和短期任务。

  • later:

    Later 不支持持久化任务,适合短期任务和简单调度。

调度灵活性

  • cron:

    Cron 使用类 Unix 的 cron 表达式,适合简单的定时任务。

  • node-schedule:

    Node-Schedule 支持 cron 表达式和日期对象,适合多种调度需求。

  • node-cron:

    Node-Cron 提供简单的 cron 风格调度,适合小型应用。

  • bull:

    Bull 提供了优先级和延迟任务的支持,适合需要处理大量任务的应用。

  • agenda:

    Agenda 提供了丰富的调度选项,支持重复任务、延迟任务和复杂的调度逻辑,适合复杂的应用场景。

  • bree:

    Bree 提供简单的调度选项,适合快速开发和简单任务。

  • later:

    Later 提供了灵活的调度选项,支持多种时间格式,适合高度自定义的调度需求。

性能

  • cron:

    Cron 性能良好,适合简单的定时任务。

  • node-schedule:

    Node-Schedule 性能适中,适合灵活的调度需求。

  • node-cron:

    Node-Cron 性能良好,适合轻量级的定时任务。

  • bull:

    Bull 基于 Redis,提供高性能的任务队列,适合处理大量任务。

  • agenda:

    Agenda 性能依赖于 MongoDB 的性能,适合需要高可靠性的任务调度。

  • bree:

    Bree 使用 worker 线程执行任务,适合 CPU 密集型任务,性能优越。

  • later:

    Later 性能适中,适合短期任务和简单调度。

易用性

  • cron:

    Cron API 简单,易于理解,适合小型项目。

  • node-schedule:

    Node-Schedule API 灵活,适合多种调度需求,学习曲线适中。

  • node-cron:

    Node-Cron API 简单,易于使用,适合新手。

  • bull:

    Bull 提供了丰富的功能,可能需要一定的学习成本,但文档清晰。

  • agenda:

    Agenda 提供了简单的 API,易于上手,适合新手和快速开发。

  • bree:

    Bree API 简洁,易于使用,适合快速开发。

  • later:

    Later API 灵活,适合需要自定义调度的开发者。

社区支持

  • cron:

    Cron 社区活跃,文档简单易懂,适合新手。

  • node-schedule:

    Node-Schedule 拥有活跃的社区和良好的文档支持,适合需要社区帮助的开发者。

  • node-cron:

    Node-Cron 社区活跃,文档简单,适合新手。

  • bull:

    Bull 拥有强大的社区支持和丰富的文档,适合需要帮助的开发者。

  • agenda:

    Agenda 拥有活跃的社区和良好的文档支持,适合需要社区帮助的开发者。

  • bree:

    Bree 社区相对较小,但文档清晰,适合快速开发。

  • later:

    Later 社区较小,但文档清晰,适合自定义调度的开发者。

如何选择: cron vs node-schedule vs node-cron vs bull vs agenda vs bree vs later
  • cron:

    选择 Cron 如果你需要一个简单的定时任务调度器,支持类 Unix 的 cron 表达式,适合简单的定时任务。它易于使用,适合小型项目和简单的调度需求。

  • node-schedule:

    选择 Node-Schedule 如果你需要一个功能丰富的调度库,支持复杂的时间规则和日期,适合需要灵活调度的应用。它支持 cron 表达式和日期对象,适合多种调度需求。

  • node-cron:

    选择 Node-Cron 如果你需要一个轻量级的 cron 风格的调度库,易于使用且不依赖外部存储。它适合简单的定时任务,适合小型应用。

  • bull:

    选择 Bull 如果你需要一个高性能的任务队列,支持优先级、延迟和重试机制,适合需要处理大量任务的应用。它基于 Redis,提供了强大的功能和良好的性能。

  • agenda:

    选择 Agenda 如果你需要一个基于 MongoDB 的任务调度库,适合需要持久化任务和复杂调度的场景。它支持重复任务和延迟任务,非常适合需要高可靠性的应用。

  • bree:

    选择 Bree 如果你需要一个轻量级的任务调度库,支持使用 worker 线程来执行任务,适合 CPU 密集型任务。它简单易用,适合快速开发和小型项目。

  • later:

    选择 Later 如果你需要一个灵活的定时任务调度库,支持复杂的调度逻辑和多种时间格式。它适合需要高度自定义的调度需求。

cron的README

cron for Node.js logo
cron is a robust tool for running jobs (functions or commands) on schedules defined using the cron syntax.
Perfect for tasks like data backups, notifications, and many more!

Cron for Node.js

Version Monthly Downloads Build Status CodeQL Status Coverage Renovate OpenSSF Scorecard Discord

🌟 Features

  • execute a function whenever your scheduled job triggers
  • execute a job external to the javascript process (like a system command) using child_process
  • use a Date or Luxon DateTime object instead of cron syntax as the trigger for your callback
  • use an additional slot for seconds (leaving it off will default to 0 and match the Unix behavior)

🚀 Installation

npm install cron

Table of Contents

  1. Features
  2. Installation
  3. Migrating
  4. Basic Usage
  5. Cron Patterns
  6. API
  7. Gotchas
  8. Community
  9. Contributing
  10. Acknowledgements
  11. License

⬆ Migrating

v4 dropped Node v16 and renamed the job.running property:

Migrating from v3 to v4

Dropped Node version

Node v16 is no longer supported. Upgrade your Node installation to Node v18 or above

Property renamed and now read-only

You can no longer set the running property (now isActive). It is read-only. To start or stop a cron job, use job.start() and job.stop().

v3 introduced TypeScript and tighter Unix cron pattern alignment:

Migrating from v2 to v3

Month & day-of-week indexing changes

  • Month Indexing: Changed from 0-11 to 1-12. So you need to increment all numeric months by 1.

  • Day-of-Week Indexing: Support added for 7 as Sunday.

Adjustments in CronJob

  • The constructor no longer accepts an object as its first and only params. Use CronJob.from(argsObject) instead.
  • Callbacks are now called in the order they were registered.
  • nextDates(count?: number) now always returns an array (empty if no argument is provided). Use nextDate() instead for a single date.

Removed methods

  • removed job() method in favor of new CronJob(...args) / CronJob.from(argsObject)

  • removed time() method in favor of new CronTime()

🛠 Basic Usage

import { CronJob } from 'cron';

const job = new CronJob(
	'* * * * * *', // cronTime
	function () {
		console.log('You will see this message every second');
	}, // onTick
	null, // onComplete
	true, // start
	'America/Los_Angeles' // timeZone
);
// job.start() is optional here because of the fourth parameter set to true.
// equivalent job using the "from" static method, providing parameters as an object
const job = CronJob.from({
	cronTime: '* * * * * *',
	onTick: function () {
		console.log('You will see this message every second');
	},
	start: true,
	timeZone: 'America/Los_Angeles'
});

Note: In the first example above, the fourth parameter to CronJob() starts the job automatically. If not provided or set to falsy, you must explicitly start the job using job.start().

For more advanced examples, check the examples directory.

⏰ Cron Patterns

Cron patterns are the backbone of this library. Familiarize yourself with the syntax:

- `*` Asterisks: Any value
- `1-3,5` Ranges: Ranges and individual values
- `*/2` Steps: Every two units

Detailed patterns and explanations are available at crontab.org. The examples in the link have five fields, and 1 minute as the finest granularity, but our cron scheduling supports an enhanced format with six fields, allowing for second-level precision. Tools like crontab.guru can help in constructing patterns but remember to account for the seconds field.

Supported Ranges

Here's a quick reference to the UNIX Cron format this library uses, plus an added second field:

field          allowed values
-----          --------------
second         0-59
minute         0-59
hour           0-23
day of month   1-31
month          1-12 (or names, see below)
day of week    0-7 (0 or 7 is Sunday, or use names)

Names can also be used for the 'month' and 'day of week' fields. Use the first three letters of the particular day or month (case does not matter). Ranges and lists of names are allowed.
Examples: "mon,wed,fri", "jan-mar".

📖 API

Standalone Functions

  • sendAt: Indicates when a CronTime will execute (returns a Luxon DateTime object).

    import * as cron from 'cron';
    
    const dt = cron.sendAt('0 0 * * *');
    console.log(`The job would run at: ${dt.toISO()}`);
    
  • timeout: Indicates the number of milliseconds in the future at which a CronTime will execute (returns a number).

    import * as cron from 'cron';
    
    const timeout = cron.timeout('0 0 * * *');
    console.log(`The job would run in ${timeout}ms`);
    
  • validateCronExpression: Validates if a given cron expression is valid (returns an object with valid and error properties).

    import * as cron from 'cron';
    
    const validation = cron.validateCronExpression('0 0 * * *');
    console.log(`Is the cron expression valid? ${validation.valid}`);
    if (!validation.valid) {
    	console.error(`Validation error: ${validation.error}`);
    }
    

CronJob Class

Constructor

constructor(cronTime, onTick, onComplete, start, timeZone, context, runOnInit, utcOffset, unrefTimeout, waitForCompletion, errorHandler, name, threshold):

  • cronTime: [REQUIRED] - The time to fire off your job. Can be cron syntax, a JS Date object or a Luxon DateTime object.

  • onTick: [REQUIRED] - Function to execute at the specified time. If an onComplete callback was provided, onTick will receive it as an argument.

  • onComplete: [OPTIONAL] - Invoked when the job is halted with job.stop(). It might also be triggered by onTick post its run.

  • start: [OPTIONAL] - Determines if the job should commence before constructor exit. Default is false.

  • timeZone: [OPTIONAL] - Sets the execution time zone. Default is local time. Check valid formats in the Luxon documentation.

  • context: [OPTIONAL] - Execution context for the onTick method.

  • runOnInit: [OPTIONAL] - Instantly triggers the onTick function post initialization. Default is false.

  • utcOffset: [OPTIONAL] - Specifies time zone offset in minutes. Cannot co-exist with timeZone.

  • unrefTimeout: [OPTIONAL] - Useful for controlling event loop behavior. More details here.

  • waitForCompletion: [OPTIONAL] - If true, no additional instances of the onTick callback function will run until the current onTick callback has completed. Any new scheduled executions that occur while the current callback is running will be skipped entirely. Default is false.

  • errorHandler: [OPTIONAL] - Function to handle any exceptions that occur in the onTick method.

  • name: [OPTIONAL] - Name of the job. Useful for identifying jobs in logs.

  • threshold: [OPTIONAL] - Threshold in ms to control whether to execute or skip missed execution deadlines caused by slow or busy hardware. Execution delays within threshold will be executed immediately, and otherwise will be skipped. In both cases a warning will be printed to the console with the job name and cron expression. See issue #962 for more information. Default is 250.

Methods

  • from (static): Create a new CronJob object providing arguments as an object. See argument names and descriptions above.

  • start: Initiates the job.

  • stop: Halts the job.

  • setTime: Modifies the time for the CronJob. Parameter must be a CronTime.

  • lastDate: Provides the last execution date.

  • nextDate: Indicates the subsequent date that will activate an onTick.

  • nextDates(count): Supplies an array of upcoming dates that will initiate an onTick.

  • fireOnTick: Allows modification of the onTick calling behavior.

  • addCallback: Permits addition of onTick callbacks.

Properties

  • isActive: [READ-ONLY] Indicates if a job is active (checking to see if the callback needs to be called).

  • isCallbackRunning: [READ-ONLY] Indicates if a callback is currently executing.

    const job = new CronJob('* * * * * *', async () => {
    	console.log(job.isCallbackRunning); // true during callback execution
    	await someAsyncTask();
    	console.log(job.isCallbackRunning); // still true until callback completes
    });
    
    console.log(job.isCallbackRunning); // false
    job.start();
    console.log(job.isActive); // true
    console.log(job.isCallbackRunning); // false
    

CronTime Class

Constructor

constructor(time, zone, utcOffset):

  • time: [REQUIRED] - The time to initiate your job. Accepts cron syntax or a JS Date object.

  • zone: [OPTIONAL] - Equivalent to timeZone from CronJob parameters.

  • utcOffset: [OPTIONAL] - Analogous to utcOffset from CronJob parameters.

💢 Gotchas

  • Both JS Date and Luxon DateTime objects don't guarantee millisecond precision due to computation delays. This module excludes millisecond precision for standard cron syntax but allows execution date specification through JS Date or Luxon DateTime objects. However, specifying a precise future execution time, such as adding a millisecond to the current time, may not always work due to these computation delays. It's observed that delays less than 4-5 ms might lead to inconsistencies. While we could limit all date granularity to seconds, we've chosen to allow greater precision but advise users of potential issues.

  • Using arrow functions for onTick binds them to the parent's this context. As a result, they won't have access to the cronjob's this context. You can read a little more in issue #47 (comment).

🤝 Community

Join the Discord server! Here you can discuss issues and get help in a more casual forum than GitHub.

🌍 Contributing

This project is looking for help! If you're interested in helping with the project, please take a look at our contributing documentation.

🐛 Submitting Bugs/Issues

Please have a look at our contributing documentation, it contains all the information you need to know before submitting an issue.

🙏 Acknowledgements

This is a community effort project. In the truest sense, this project started as an open source project from cron.js and grew into something else. Other people have contributed code, time, and oversight to the project. At this point there are too many to name here so we'll just say thanks.

Special thanks to Hiroki Horiuchi, Lundarl Gholoi and koooge for their work on the DefinitelyTyped typings before they were imported in v2.4.0.

⚖ License

MIT