bull vs agenda vs bee-queue vs bree vs kue vs node-resque
Job-Queue-Bibliotheken für Node.js
bullagendabee-queuebreekuenode-resqueÄhnliche Pakete:

Job-Queue-Bibliotheken für Node.js

Job-Queue-Bibliotheken ermöglichen es Entwicklern, Aufgaben asynchron zu verarbeiten und zu verwalten, indem sie eine Warteschlange für Jobs erstellen, die im Hintergrund ausgeführt werden. Diese Bibliotheken sind besonders nützlich für die Verarbeitung von zeitintensiven Aufgaben, die nicht im Hauptausführungsstrang blockieren sollen, wie z.B. das Versenden von E-Mails, das Verarbeiten von Bildern oder das Durchführen von Datenbankoperationen. Sie bieten Mechanismen zur Planung, Wiederholung und Fehlerbehandlung von Jobs.

npm-Download-Trend

3 Jahre

GitHub Stars Ranking

Statistik-Detail

Paket
Downloads
Stars
Größe
Issues
Veröffentlichung
Lizenz
bull2,245,94716,262309 kB147vor 2 JahrenMIT
agenda228,6899,712310 kB19vor 10 StundenMIT
bee-queue67,7854,039107 kB46vor einem JahrMIT
bree42,9493,29692 kB30vor 8 MonatenMIT
kue31,0799,418-286vor 9 JahrenMIT
node-resque26,4421,415720 kB24vor 3 MonatenApache-2.0

Funktionsvergleich: bull vs agenda vs bee-queue vs bree vs kue vs node-resque

Architektur

  • bull:

    Bull ist eine umfassende Lösung, die Redis verwendet und eine Vielzahl von Funktionen wie Job-Priorisierung und Wiederholungen bietet. Die Architektur ist robust und für komplexe Anwendungen geeignet.

  • agenda:

    Agenda verwendet MongoDB zur Speicherung von Jobs und bietet eine einfache API zur Planung und Verwaltung von Jobs. Die Architektur ist flexibel und ermöglicht eine einfache Integration in bestehende Anwendungen.

  • bee-queue:

    Bee-Queue ist auf Geschwindigkeit und Effizienz optimiert und verwendet Redis zur Speicherung von Jobs. Es ist leichtgewichtig und bietet eine einfache API für die Jobverarbeitung.

  • bree:

    Bree nutzt Node.js-Worker-Threads für die Jobverarbeitung, was eine hohe Parallelität und Leistung ermöglicht. Die Architektur ist einfach und benötigt keine externen Abhängigkeiten.

  • kue:

    Kue bietet eine benutzerfreundliche API und ein Dashboard zur Überwachung von Jobs. Es verwendet Redis zur Speicherung und ist einfach zu implementieren.

  • node-resque:

    Node-Resque basiert auf der Resque-Architektur und verwendet Redis zur Speicherung von Jobs. Es bietet eine einfache API und eine hohe Flexibilität.

Leistung

  • bull:

    Bull bietet eine hohe Leistung und kann eine große Anzahl von Jobs effizient verarbeiten. Die Verwendung von Redis ermöglicht schnelle Lese- und Schreibvorgänge.

  • agenda:

    Die Leistung von Agenda hängt stark von der MongoDB-Instanz ab. Bei hoher Last kann die Leistung beeinträchtigt werden, insbesondere wenn viele Jobs gleichzeitig geplant werden.

  • bee-queue:

    Bee-Queue ist für hohe Leistung optimiert und kann Tausende von Jobs pro Sekunde verarbeiten. Es ist ideal für Anwendungen mit hoher Last.

  • bree:

    Bree bietet eine hervorragende Leistung, da es Node.js-Worker-Threads verwendet, die eine parallele Verarbeitung von Jobs ermöglichen. Dies verbessert die Effizienz bei der Verarbeitung mehrerer Jobs.

  • kue:

    Kue hat eine akzeptable Leistung, kann jedoch bei sehr hohen Lasten langsamer werden. Es ist wichtig, die Redis-Konfiguration zu optimieren, um die Leistung zu maximieren.

  • node-resque:

    Node-Resque bietet eine gute Leistung, die von der Redis-Instanz abhängt. Es ist wichtig, die Anzahl der Worker und die Redis-Konfiguration zu optimieren.

Wiederholungsmechanismen

  • bull:

    Bull bietet umfassende Unterstützung für wiederkehrende Jobs und ermöglicht die einfache Konfiguration von Wiederholungsstrategien für Jobs.

  • agenda:

    Agenda bietet eingebaute Unterstützung für wiederkehrende Jobs mit flexiblen Zeitplänen. Dies ermöglicht eine einfache Planung von Jobs, die regelmäßig ausgeführt werden müssen.

  • bee-queue:

    Bee-Queue unterstützt keine eingebaute Wiederholung, aber Entwickler können manuell wiederkehrende Jobs implementieren, indem sie Jobs erneut in die Warteschlange stellen.

  • bree:

    Bree bietet eine einfache Möglichkeit, wiederkehrende Jobs zu planen, indem es Cron-ähnliche Syntax verwendet. Dies erleichtert die Planung von Jobs, die regelmäßig ausgeführt werden müssen.

  • kue:

    Kue unterstützt wiederkehrende Jobs, allerdings muss die Logik zur Wiederholung manuell implementiert werden. Es bietet jedoch eine einfache API zur Verwaltung von Jobs.

  • node-resque:

    Node-Resque unterstützt die Wiederholung von Jobs, indem es die Resque-Logik verwendet. Entwickler können wiederkehrende Jobs einfach implementieren.

Fehlerbehandlung

  • bull:

    Bull bietet umfassende Fehlerbehandlungsfunktionen, einschließlich der Möglichkeit, fehlgeschlagene Jobs zu protokollieren, sie erneut zu versuchen und benutzerdefinierte Fehlerbehandlungsstrategien zu implementieren.

  • agenda:

    Agenda bietet grundlegende Fehlerbehandlungsmechanismen, die es ermöglichen, fehlgeschlagene Jobs zu protokollieren und erneut zu versuchen. Die Implementierung ist jedoch nicht so robust wie bei anderen Bibliotheken.

  • bee-queue:

    Bee-Queue bietet einfache Fehlerbehandlungsmechanismen, die es ermöglichen, fehlgeschlagene Jobs erneut in die Warteschlange zu stellen. Die API ist einfach und leicht verständlich.

  • bree:

    Bree bietet eine einfache Fehlerbehandlung, die es ermöglicht, fehlgeschlagene Jobs zu protokollieren und erneut zu versuchen. Die Implementierung ist benutzerfreundlich.

  • kue:

    Kue bietet grundlegende Fehlerbehandlungsmechanismen, die es ermöglichen, fehlgeschlagene Jobs zu protokollieren und erneut zu versuchen. Die Implementierung ist jedoch nicht so robust wie bei Bull.

  • node-resque:

    Node-Resque bietet eine einfache Fehlerbehandlung, die es ermöglicht, fehlgeschlagene Jobs zu protokollieren und sie erneut in die Warteschlange zu stellen.

Benutzeroberfläche

  • bull:

    Bull bietet ein Dashboard zur Überwachung von Jobs, das eine einfache Möglichkeit bietet, den Status von Jobs zu überprüfen und fehlgeschlagene Jobs zu verwalten.

  • agenda:

    Agenda hat keine eingebaute Benutzeroberfläche, aber Entwickler können eine eigene Implementierung erstellen, um Jobs zu überwachen und zu verwalten.

  • bee-queue:

    Bee-Queue bietet keine Benutzeroberfläche, aber Entwickler können externe Tools verwenden, um den Status von Jobs zu überwachen.

  • bree:

    Bree hat keine eingebaute Benutzeroberfläche, aber es ist einfach, eine eigene zu erstellen, um Jobs zu überwachen und zu verwalten.

  • kue:

    Kue bietet eine eingebaute Benutzeroberfläche zur Überwachung von Jobs, die eine einfache Möglichkeit bietet, den Status von Jobs zu überprüfen und fehlgeschlagene Jobs zu verwalten.

  • node-resque:

    Node-Resque bietet keine eingebaute Benutzeroberfläche, aber es ist einfach, eine eigene zu erstellen, um Jobs zu überwachen.

Wie man wählt: bull vs agenda vs bee-queue vs bree vs kue vs node-resque

  • bull:

    Bull ist eine leistungsstarke Job-Queue-Bibliothek, die Redis verwendet und eine Vielzahl von Funktionen wie Priorisierung, Wiederholungen und Fehlerbehandlung bietet. Wählen Sie Bull, wenn Sie eine robuste Lösung für komplexe Jobverarbeitungen benötigen.

  • agenda:

    Wählen Sie Agenda, wenn Sie eine MongoDB-basierte Lösung benötigen, die eine einfache API zur Planung von Jobs bietet. Agenda eignet sich gut für Anwendungen, die eine flexible und wiederholbare Jobplanung erfordern.

  • bee-queue:

    Bee-Queue ist ideal, wenn Sie eine einfache und schnelle Lösung für die Verarbeitung von Jobs benötigen, die Redis als Backend verwendet. Es bietet eine hohe Leistung und ist besonders nützlich für Anwendungen mit hoher Last.

  • bree:

    Bree ist eine moderne Job-Queue-Bibliothek, die auf Node.js-Worker-Threads basiert. Wählen Sie Bree, wenn Sie eine einfache API und Unterstützung für wiederkehrende Jobs benötigen, ohne sich um externe Abhängigkeiten kümmern zu müssen.

  • kue:

    Kue ist eine weitere Redis-basierte Job-Queue-Bibliothek, die eine benutzerfreundliche API und ein Dashboard zur Überwachung von Jobs bietet. Wählen Sie Kue, wenn Sie eine visuelle Überwachung Ihrer Jobs wünschen.

  • node-resque:

    Node-Resque ist eine Job-Queue-Bibliothek, die auf der Resque-Architektur basiert und eine einfache Integration mit Redis bietet. Wählen Sie Node-Resque, wenn Sie eine Lösung benötigen, die sich gut in bestehende Resque-Implementierungen einfügt.

README für bull




The fastest, most reliable, Redis-based queue for Node.
Carefully written for rock solid stability and atomicity.


Sponsors · Features · UIs · Install · Quick Guide · Documentation

Check the new Guide!


🚀 Sponsors 🚀

Dragonfly Dragonfly is a new Redis™ drop-in replacement that is fully compatible with BullMQ and brings some important advantages over Redis™ such as massive better performance by utilizing all CPU cores available and faster and more memory efficient data structures. Read more here on how to use it with BullMQ.

📻 News and updates

Bull is currently in maintenance mode, we are only fixing bugs. For new features check BullMQ, a modern rewritten implementation in Typescript. You are still very welcome to use Bull if it suits your needs, which is a safe, battle tested library.

Follow me on Twitter for other important news and updates.

🛠 Tutorials

You can find tutorials and news in this blog: https://blog.taskforce.sh/


Used by

Bull is popular among large and small organizations, like the following ones:

Atlassian Autodesk Mozilla Nest Salesforce


Official FrontEnd

Taskforce.sh, Inc

Supercharge your queues with a professional front end:

  • Get a complete overview of all your queues.
  • Inspect jobs, search, retry, or promote delayed jobs.
  • Metrics and statistics.
  • and many more features.

Sign up at Taskforce.sh


Bull Features

  • Minimal CPU usage due to a polling-free design.
  • Robust design based on Redis.
  • Delayed jobs.
  • Schedule and repeat jobs according to a cron specification.
  • Rate limiter for jobs.
  • Retries.
  • Priority.
  • Concurrency.
  • Pause/resume—globally or locally.
  • Multiple job types per queue.
  • Threaded (sandboxed) processing functions.
  • Automatic recovery from process crashes.

And coming up on the roadmap...

  • Job completion acknowledgement (you can use the message queue pattern in the meantime).
  • Parent-child jobs relationships.

UIs

There are a few third-party UIs that you can use for monitoring:

BullMQ

Bull v3

Bull <= v2


Monitoring & Alerting


Feature Comparison

Since there are a few job queue solutions, here is a table comparing them:

FeatureBullMQ-ProBullMQBullKueBeeAgenda
Backendredisredisredisredisredismongo
Observables✓
Group Rate Limit✓
Group Support✓
Batches Support✓
Parent/Child Dependencies✓✓
Priorities✓✓✓✓✓
Concurrency✓✓✓✓✓✓
Delayed jobs✓✓✓✓✓
Global events✓✓✓✓
Rate Limiter✓✓✓
Pause/Resume✓✓✓✓
Sandboxed worker✓✓✓
Repeatable jobs✓✓✓✓
Atomic ops✓✓✓✓
Persistence✓✓✓✓✓✓
UI✓✓✓✓✓
Optimized forJobs / MessagesJobs / MessagesJobs / MessagesJobsMessagesJobs

Install

npm install bull --save

or

yarn add bull

Requirements: Bull requires a Redis version greater than or equal to 2.8.18.

Typescript Definitions

npm install @types/bull --save-dev
yarn add --dev @types/bull

Definitions are currently maintained in the DefinitelyTyped repo.

Contributing

We welcome all types of contributions, either code fixes, new features or doc improvements. Code formatting is enforced by prettier. For commits please follow conventional commits convention. All code must pass lint rules and test suites before it can be merged into develop.


Quick Guide

Basic Usage

const Queue = require('bull');

const videoQueue = new Queue('video transcoding', 'redis://127.0.0.1:6379');
const audioQueue = new Queue('audio transcoding', { redis: { port: 6379, host: '127.0.0.1', password: 'foobared' } }); // Specify Redis connection using object
const imageQueue = new Queue('image transcoding');
const pdfQueue = new Queue('pdf transcoding');

videoQueue.process(function (job, done) {

  // job.data contains the custom data passed when the job was created
  // job.id contains id of this job.

  // transcode video asynchronously and report progress
  job.progress(42);

  // call done when finished
  done();

  // or give an error if error
  done(new Error('error transcoding'));

  // or pass it a result
  done(null, { framerate: 29.5 /* etc... */ });

  // If the job throws an unhandled exception it is also handled correctly
  throw new Error('some unexpected error');
});

audioQueue.process(function (job, done) {
  // transcode audio asynchronously and report progress
  job.progress(42);

  // call done when finished
  done();

  // or give an error if error
  done(new Error('error transcoding'));

  // or pass it a result
  done(null, { samplerate: 48000 /* etc... */ });

  // If the job throws an unhandled exception it is also handled correctly
  throw new Error('some unexpected error');
});

imageQueue.process(function (job, done) {
  // transcode image asynchronously and report progress
  job.progress(42);

  // call done when finished
  done();

  // or give an error if error
  done(new Error('error transcoding'));

  // or pass it a result
  done(null, { width: 1280, height: 720 /* etc... */ });

  // If the job throws an unhandled exception it is also handled correctly
  throw new Error('some unexpected error');
});

pdfQueue.process(function (job) {
  // Processors can also return promises instead of using the done callback
  return pdfAsyncProcessor();
});

videoQueue.add({ video: 'http://example.com/video1.mov' });
audioQueue.add({ audio: 'http://example.com/audio1.mp3' });
imageQueue.add({ image: 'http://example.com/image1.tiff' });

Using promises

Alternatively, you can return promises instead of using the done callback:

videoQueue.process(function (job) { // don't forget to remove the done callback!
  // Simply return a promise
  return fetchVideo(job.data.url).then(transcodeVideo);

  // Handles promise rejection
  return Promise.reject(new Error('error transcoding'));

  // Passes the value the promise is resolved with to the "completed" event
  return Promise.resolve({ framerate: 29.5 /* etc... */ });

  // If the job throws an unhandled exception it is also handled correctly
  throw new Error('some unexpected error');
  // same as
  return Promise.reject(new Error('some unexpected error'));
});

Separate processes

The process function can also be run in a separate process. This has several advantages:

  • The process is sandboxed so if it crashes it does not affect the worker.
  • You can run blocking code without affecting the queue (jobs will not stall).
  • Much better utilization of multi-core CPUs.
  • Less connections to redis.

In order to use this feature just create a separate file with the processor:

// processor.js
module.exports = function (job) {
  // Do some heavy work

  return Promise.resolve(result);
}

And define the processor like this:

// Single process:
queue.process('/path/to/my/processor.js');

// You can use concurrency as well:
queue.process(5, '/path/to/my/processor.js');

// and named processors:
queue.process('my processor', 5, '/path/to/my/processor.js');

Repeated jobs

A job can be added to a queue and processed repeatedly according to a cron specification:

  paymentsQueue.process(function (job) {
    // Check payments
  });

  // Repeat payment job once every day at 3:15 (am)
  paymentsQueue.add(paymentsData, { repeat: { cron: '15 3 * * *' } });

As a tip, check your expressions here to verify they are correct: cron expression generator

Pause / Resume

A queue can be paused and resumed globally (pass true to pause processing for just this worker):

queue.pause().then(function () {
  // queue is paused now
});

queue.resume().then(function () {
  // queue is resumed now
})

Events

A queue emits some useful events, for example...

.on('completed', function (job, result) {
  // Job completed with output result!
})

For more information on events, including the full list of events that are fired, check out the Events reference

Queues performance

Queues are cheap, so if you need many of them just create new ones with different names:

const userJohn = new Queue('john');
const userLisa = new Queue('lisa');
.
.
.

However every queue instance will require new redis connections, check how to reuse connections or you can also use named processors to achieve a similar result.

Cluster support

NOTE: From version 3.2.0 and above it is recommended to use threaded processors instead.

Queues are robust and can be run in parallel in several threads or processes without any risk of hazards or queue corruption. Check this simple example using cluster to parallelize jobs across processes:

const Queue = require('bull');
const cluster = require('cluster');

const numWorkers = 8;
const queue = new Queue('test concurrent queue');

if (cluster.isMaster) {
  for (let i = 0; i < numWorkers; i++) {
    cluster.fork();
  }

  cluster.on('online', function (worker) {
    // Let's create a few jobs for the queue workers
    for (let i = 0; i < 500; i++) {
      queue.add({ foo: 'bar' });
    };
  });

  cluster.on('exit', function (worker, code, signal) {
    console.log('worker ' + worker.process.pid + ' died');
  });
} else {
  queue.process(function (job, jobDone) {
    console.log('Job done by worker', cluster.worker.id, job.id);
    jobDone();
  });
}

Documentation

For the full documentation, check out the reference and common patterns:

  • Guide — Your starting point for developing with Bull.
  • Reference — Reference document with all objects and methods available.
  • Patterns — a set of examples for common patterns.
  • License — the Bull license—it's MIT.

If you see anything that could use more docs, please submit a pull request!


Important Notes

The queue aims for an "at least once" working strategy. This means that in some situations, a job could be processed more than once. This mostly happens when a worker fails to keep a lock for a given job during the total duration of the processing.

When a worker is processing a job it will keep the job "locked" so other workers can't process it.

It's important to understand how locking works to prevent your jobs from losing their lock - becoming stalled - and being restarted as a result. Locking is implemented internally by creating a lock for lockDuration on interval lockRenewTime (which is usually half lockDuration). If lockDuration elapses before the lock can be renewed, the job will be considered stalled and is automatically restarted; it will be double processed. This can happen when:

  1. The Node process running your job processor unexpectedly terminates.
  2. Your job processor was too CPU-intensive and stalled the Node event loop, and as a result, Bull couldn't renew the job lock (see #488 for how we might better detect this). You can fix this by breaking your job processor into smaller parts so that no single part can block the Node event loop. Alternatively, you can pass a larger value for the lockDuration setting (with the tradeoff being that it will take longer to recognize a real stalled job).

As such, you should always listen for the stalled event and log this to your error monitoring system, as this means your jobs are likely getting double-processed.

As a safeguard so problematic jobs won't get restarted indefinitely (e.g. if the job processor always crashes its Node process), jobs will be recovered from a stalled state a maximum of maxStalledCount times (default: 1).