bull vs agenda vs bee-queue vs bree vs kue vs node-resque
Bibliotecas de Gestión de Tareas en Node.js
bullagendabee-queuebreekuenode-resquePackages similaires:

Bibliotecas de Gestión de Tareas en Node.js

Las bibliotecas de gestión de tareas en Node.js permiten a los desarrolladores programar y manejar tareas asíncronas de manera eficiente. Estas bibliotecas son útiles para ejecutar trabajos en segundo plano, programar tareas recurrentes y manejar colas de trabajo, lo que mejora el rendimiento y la escalabilidad de las aplicaciones. Cada una de estas bibliotecas tiene sus propias características y enfoques, lo que permite a los desarrolladores elegir la más adecuada según sus necesidades específicas.

Tendance de téléchargements npm

3 Ans

Classement des GitHub Stars

Détail des statistiques

Package
Téléchargements
Stars
Taille
Issues
Publication
Licence
bull2,245,94716,262309 kB147il y a 2 ansMIT
agenda228,6899,712310 kB19il y a 10 heuresMIT
bee-queue67,7854,039107 kB46il y a un anMIT
bree42,9493,29692 kB30il y a 8 moisMIT
kue31,0799,418-286il y a 9 ansMIT
node-resque26,4421,415720 kB24il y a 3 moisApache-2.0

Comparaison des fonctionnalités: bull vs agenda vs bee-queue vs bree vs kue vs node-resque

Persistencia de Datos

  • bull:

    Bull utiliza Redis para almacenar trabajos, lo que proporciona una alta disponibilidad y persistencia. Esto permite que los trabajos se mantengan incluso si el servidor se reinicia, lo que es crucial para aplicaciones críticas.

  • agenda:

    Agenda almacena trabajos en MongoDB, lo que permite una persistencia fácil y una recuperación de trabajos programados incluso después de un reinicio de la aplicación. Esto es útil para aplicaciones que requieren una gestión de trabajos a largo plazo.

  • bee-queue:

    Bee-Queue no ofrece persistencia de datos por defecto, ya que se centra en la velocidad. Los trabajos se almacenan en memoria, lo que significa que se perderán si el proceso se reinicia. Es ideal para trabajos que no requieren persistencia.

  • bree:

    Bree permite la persistencia a través de archivos de configuración y cron jobs, lo que facilita la programación de tareas recurrentes. Sin embargo, no almacena trabajos en una base de datos, lo que puede ser una limitación para algunos casos de uso.

  • kue:

    Kue también utiliza Redis para la persistencia de trabajos, ofreciendo una interfaz de usuario para monitorear el estado de los trabajos. Esto facilita la gestión de trabajos en aplicaciones que requieren supervisión activa.

  • node-resque:

    Node-Resque utiliza Redis para la gestión de trabajos, permitiendo una alta disponibilidad y persistencia. Esto es ideal para aplicaciones que requieren un sistema de colas robusto y confiable.

Facilidad de Uso

  • bull:

    Bull tiene una API rica y poderosa, pero puede ser un poco más compleja de usar debido a sus numerosas características. Es ideal para desarrolladores que necesitan un control más detallado sobre la gestión de trabajos.

  • agenda:

    Agenda tiene una API sencilla y fácil de entender, lo que facilita su integración en proyectos existentes. Su enfoque en MongoDB también simplifica la gestión de datos para los desarrolladores que ya utilizan esta base de datos.

  • bee-queue:

    Bee-Queue es extremadamente fácil de usar, con una API minimalista que permite a los desarrolladores comenzar rápidamente. Su enfoque en la simplicidad lo hace ideal para proyectos pequeños o medianos.

  • bree:

    Bree ofrece una sintaxis clara y concisa para definir trabajos y cron jobs, lo que facilita su uso incluso para desarrolladores novatos. Su documentación es accesible y bien estructurada.

  • kue:

    Kue proporciona una interfaz de usuario que facilita la gestión de trabajos, pero su API puede ser un poco más complicada en comparación con otras bibliotecas. Es ideal para aquellos que valoran la visualización de trabajos.

  • node-resque:

    Node-Resque tiene una API flexible que permite a los desarrolladores personalizar su implementación. Sin embargo, puede requerir más tiempo para configuraciones avanzadas.

Rendimiento

  • bull:

    Bull es altamente eficiente y puede manejar una gran cantidad de trabajos simultáneamente gracias a su integración con Redis. Es ideal para aplicaciones que requieren un procesamiento intensivo de trabajos.

  • agenda:

    Agenda es eficiente para trabajos programados, pero su dependencia de MongoDB puede introducir cierta latencia en comparación con soluciones basadas en memoria. Es ideal para tareas que no requieren una respuesta instantánea.

  • bee-queue:

    Bee-Queue está diseñado para un alto rendimiento y baja latencia, lo que lo hace adecuado para aplicaciones que requieren un procesamiento rápido de trabajos en tiempo real.

  • bree:

    Bree ofrece un buen rendimiento para trabajos programados, pero su enfoque en cron jobs puede no ser tan eficiente para trabajos que requieren un procesamiento inmediato.

  • kue:

    Kue ofrece un rendimiento sólido, pero su interfaz de usuario puede introducir cierta sobrecarga. Es ideal para aplicaciones que requieren monitoreo y gestión activa de trabajos.

  • node-resque:

    Node-Resque es eficiente y puede manejar una gran cantidad de trabajos, pero su rendimiento depende de la configuración de Redis. Es ideal para aplicaciones que ya utilizan Redis y requieren un sistema de colas.

Características Adicionales

  • bull:

    Bull ofrece características avanzadas como reintentos automáticos, programación de trabajos y manejo de trabajos fallidos. Esto lo convierte en una opción robusta para aplicaciones críticas.

  • agenda:

    Agenda permite la programación de trabajos recurrentes y tiene soporte para trabajos únicos. También ofrece una API para manejar eventos de trabajo, lo que permite una mayor personalización.

  • bee-queue:

    Bee-Queue se centra en la simplicidad y el rendimiento, pero no ofrece características avanzadas como reintentos o programación de trabajos. Es ideal para aplicaciones que no requieren estas funcionalidades.

  • bree:

    Bree incluye soporte para cron jobs y tareas programadas, lo que lo hace versátil para diversas aplicaciones. También permite la ejecución de trabajos en paralelo, lo que mejora la eficiencia.

  • kue:

    Kue ofrece una interfaz de usuario para monitorear trabajos y permite la gestión manual de trabajos fallidos. Esto es útil para aplicaciones que requieren un control más detallado sobre sus colas de trabajo.

  • node-resque:

    Node-Resque permite la creación de trabajos y colas personalizadas, lo que ofrece una gran flexibilidad. También tiene soporte para reintentos y manejo de errores.

Comment choisir: bull vs agenda vs bee-queue vs bree vs kue vs node-resque

  • bull:

    Elige Bull si necesitas una solución robusta y rica en características para manejar colas de trabajos. Es ideal para aplicaciones que requieren una gestión avanzada de trabajos, incluyendo la capacidad de manejar trabajos fallidos y repetidos.

  • agenda:

    Elige Agenda si necesitas una solución simple y basada en MongoDB para programar trabajos. Es ideal para aplicaciones que requieren una integración directa con la base de datos MongoDB y una API fácil de usar.

  • bee-queue:

    Opta por Bee-Queue si buscas un rendimiento rápido y una implementación sencilla. Es ideal para aplicaciones que requieren una cola de trabajos ligera y eficiente, especialmente en entornos donde la velocidad es crítica.

  • bree:

    Selecciona Bree si necesitas una biblioteca que soporte trabajos recurrentes y cron jobs con una sintaxis sencilla. Es ideal para aplicaciones que requieren tareas programadas y un manejo fácil de trabajos en segundo plano.

  • kue:

    Opta por Kue si buscas una solución que ofrezca una interfaz de usuario para monitorear y gestionar trabajos. Es ideal para aplicaciones que requieren una visualización clara de sus colas de trabajo y un manejo de tareas más manual.

  • node-resque:

    Selecciona Node-Resque si necesitas una solución que se integre con Redis y ofrezca un enfoque flexible para manejar trabajos y colas. Es ideal para aplicaciones que ya utilizan Redis y necesitan un sistema de colas eficiente.

README pour 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).