![](\"./support/logo@2x.png\"){kind=logo}
\n \n The fastest, most reliable, Redis-based queue for Node.
\n Carefully written for rock solid stability and atomicity.\n
\n Sponsors ·\n Features ·\n UIs ·\n Install ·\n Quick Guide ·\n Documentation\n
\nCheck the new Guide!
\n\n \n ![](\"https://badges.gitter.im/Join%20Chat.svg\"/)
\n \n \n ![](\"https://img.shields.io/badge/Slack-4A154B\"/){kind=icon}
![](\"https://badge.fury.io/js/bull.svg\"/){kind=icon}
\n \n \n ![](\"https://coveralls.io/repos/github/OptimalBits/bull/badge.svg?branch=master\"/){kind=icon}
\n \n \n ![](\"http://isitmaintained.com/badge/open/optimalbits/bull.svg\"/){kind=icon}
\n \n \n ![](\"http://isitmaintained.com/badge/resolution/optimalbits/bull.svg\"/){kind=icon}
\n \n \n ![](\"https://img.shields.io/twitter/follow/manast?label=Stay%20updated&style=social\"/)
\n \n ![\"Dragonfly\"](\"https://raw.githubusercontent.com/dragonflydb/dragonfly/main/.github/images/logo-full.svg\"){kind=logo} \n \n | \n \n Dragonfly is a new Redis™ drop-in replacement that is fully compatible with BullMQ and brings some important advantages over Redis™ such as massive\n 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.\n | \n
| \n \n | \n \n \n | \n \n \n | \n \n \n | \n \n \n | \n\n
![\"Taskforce.sh,](\"http://taskforce.sh/assets/logo_square.png\"){kind=logo}
](https://taskforce.sh)\n\nSupercharge your queues with a professional front end:\n- Get a complete overview of all your queues.\n- Inspect jobs, search, retry, or promote delayed jobs.\n- Metrics and statistics.\n- and many more features.\n\nSign up at [Taskforce.sh](https://taskforce.sh)\n\n---\n\n### Bull Features\n\n- [x] Minimal CPU usage due to a polling-free design.\n- [x] Robust design based on Redis.\n- [x] Delayed jobs.\n- [x] Schedule and repeat jobs according to a cron specification.\n- [x] Rate limiter for jobs.\n- [x] Retries.\n- [x] Priority.\n- [x] Concurrency.\n- [x] Pause/resume—globally or locally.\n- [x] Multiple job types per queue.\n- [x] Threaded (sandboxed) processing functions.\n- [x] Automatic recovery from process crashes.\n\nAnd coming up on the roadmap...\n\n- [ ] Job completion acknowledgement (you can use the message queue [pattern](https://github.com/OptimalBits/bull/blob/develop/PATTERNS.md#returning-job-completions) in the meantime).\n- [ ] Parent-child jobs relationships.\n\n---\n\n### UIs\n\nThere are a few third-party UIs that you can use for monitoring:\n\n**BullMQ**\n\n- [Taskforce](https://taskforce.sh)\n\n**Bull v3**\n\n- [Taskforce](https://taskforce.sh)\n- [bull-board](https://github.com/vcapretz/bull-board)\n- [bull-repl](https://github.com/darky/bull-repl)\n- [bull-monitor](https://github.com/s-r-x/bull-monitor)\n- [Monitoro](https://github.com/AbhilashJN/monitoro)\n\n**Bull <= v2**\n\n- [Matador](https://github.com/ShaneK/Matador)\n- [react-bull](https://github.com/kfatehi/react-bull)\n- [Toureiro](https://github.com/Epharmix/Toureiro)\n\n---\n\n### Monitoring & Alerting\n\n- With Prometheus [Bull Queue Exporter](https://github.com/UpHabit/bull_exporter)\n\n---\n\n### Feature Comparison\n\nSince there are a few job queue solutions, here is a table comparing them:\n\n| Feature | [BullMQ-Pro](https://bullmq.io/#bullmq-pro) | [BullMQ](https://bullmq.io) | Bull | Kue | Bee | Agenda |\n| :------------------------ | :-------------: | :-------------: | :-------------: | :---: | -------- | ------ |\n| Backend | redis | redis | redis | redis | redis | mongo |\n| Observables | ✓ | | | | | |\n| Group Rate Limit | ✓ | | | | | |\n| Group Support | ✓ | | | | | |\n| Batches Support | ✓ | | | | | |\n| Parent/Child Dependencies | ✓ | ✓ | | | | |\n| Priorities | ✓ | ✓ | ✓ | ✓ | | ✓ |\n| Concurrency | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |\n| Delayed jobs | ✓ | ✓ | ✓ | ✓ | | ✓ |\n| Global events | ✓ | ✓ | ✓ | ✓ | | |\n| Rate Limiter | ✓ | ✓ | ✓ | | | |\n| Pause/Resume | ✓ | ✓ | ✓ | ✓ | | |\n| Sandboxed worker | ✓ | ✓ | ✓ | | | |\n| Repeatable jobs | ✓ | ✓ | ✓ | | | ✓ |\n| Atomic ops | ✓ | ✓ | ✓ | | ✓ | |\n| Persistence | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |\n| UI | ✓ | ✓ | ✓ | ✓ | | ✓ |\n| Optimized for | Jobs / Messages | Jobs / Messages | Jobs / Messages | Jobs | Messages | Jobs |\n\n\n### Install\n\n```bash\nnpm install bull --save\n```\nor\n\n```bash\nyarn add bull\n```\n\n_**Requirements:** Bull requires a Redis version greater than or equal to `2.8.18`._\n\n\n### Typescript Definitions\n\n```bash\nnpm install @types/bull --save-dev\n```\n```bash\nyarn add --dev @types/bull\n```\n\nDefinitions are currently maintained in the [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped/tree/master/types/bull) repo.\n\n\n## Contributing\n\nWe welcome all types of contributions, either code fixes, new features or doc improvements.\nCode formatting is enforced by [prettier](https://prettier.io/).\nFor commits please follow conventional [commits convention](https://www.conventionalcommits.org/en/v1.0.0-beta.2/).\nAll code must pass lint rules and test suites before it can be merged into develop.\n\n---\n\n### Quick Guide\n\n#### Basic Usage\n```js\nconst Queue = require('bull');\n\nconst videoQueue = new Queue('video transcoding', 'redis://127.0.0.1:6379');\nconst audioQueue = new Queue('audio transcoding', { redis: { port: 6379, host: '127.0.0.1', password: 'foobared' } }); // Specify Redis connection using object\nconst imageQueue = new Queue('image transcoding');\nconst pdfQueue = new Queue('pdf transcoding');\n\nvideoQueue.process(function (job, done) {\n\n // job.data contains the custom data passed when the job was created\n // job.id contains id of this job.\n\n // transcode video asynchronously and report progress\n job.progress(42);\n\n // call done when finished\n done();\n\n // or give an error if error\n done(new Error('error transcoding'));\n\n // or pass it a result\n done(null, { framerate: 29.5 /* etc... */ });\n\n // If the job throws an unhandled exception it is also handled correctly\n throw new Error('some unexpected error');\n});\n\naudioQueue.process(function (job, done) {\n // transcode audio asynchronously and report progress\n job.progress(42);\n\n // call done when finished\n done();\n\n // or give an error if error\n done(new Error('error transcoding'));\n\n // or pass it a result\n done(null, { samplerate: 48000 /* etc... */ });\n\n // If the job throws an unhandled exception it is also handled correctly\n throw new Error('some unexpected error');\n});\n\nimageQueue.process(function (job, done) {\n // transcode image asynchronously and report progress\n job.progress(42);\n\n // call done when finished\n done();\n\n // or give an error if error\n done(new Error('error transcoding'));\n\n // or pass it a result\n done(null, { width: 1280, height: 720 /* etc... */ });\n\n // If the job throws an unhandled exception it is also handled correctly\n throw new Error('some unexpected error');\n});\n\npdfQueue.process(function (job) {\n // Processors can also return promises instead of using the done callback\n return pdfAsyncProcessor();\n});\n\nvideoQueue.add({ video: 'http://example.com/video1.mov' });\naudioQueue.add({ audio: 'http://example.com/audio1.mp3' });\nimageQueue.add({ image: 'http://example.com/image1.tiff' });\n```\n\n#### Using promises\n\nAlternatively, you can return promises instead of using the `done` callback:\n\n```javascript\nvideoQueue.process(function (job) { // don't forget to remove the done callback!\n // Simply return a promise\n return fetchVideo(job.data.url).then(transcodeVideo);\n\n // Handles promise rejection\n return Promise.reject(new Error('error transcoding'));\n\n // Passes the value the promise is resolved with to the \"completed\" event\n return Promise.resolve({ framerate: 29.5 /* etc... */ });\n\n // If the job throws an unhandled exception it is also handled correctly\n throw new Error('some unexpected error');\n // same as\n return Promise.reject(new Error('some unexpected error'));\n});\n```\n\n#### Separate processes\n\nThe process function can also be run in a separate process. This has several advantages:\n- The process is sandboxed so if it crashes it does not affect the worker.\n- You can run blocking code without affecting the queue (jobs will not stall).\n- Much better utilization of multi-core CPUs.\n- Less connections to redis.\n\nIn order to use this feature just create a separate file with the processor:\n```js\n// processor.js\nmodule.exports = function (job) {\n // Do some heavy work\n\n return Promise.resolve(result);\n}\n```\n\nAnd define the processor like this:\n\n```js\n// Single process:\nqueue.process('/path/to/my/processor.js');\n\n// You can use concurrency as well:\nqueue.process(5, '/path/to/my/processor.js');\n\n// and named processors:\nqueue.process('my processor', 5, '/path/to/my/processor.js');\n```\n\n#### Repeated jobs\n\nA job can be added to a queue and processed repeatedly according to a cron specification:\n\n```js\n paymentsQueue.process(function (job) {\n // Check payments\n });\n\n // Repeat payment job once every day at 3:15 (am)\n paymentsQueue.add(paymentsData, { repeat: { cron: '15 3 * * *' } });\n\n```\n\nAs a tip, check your expressions here to verify they are correct:\n[cron expression generator](https://crontab.cronhub.io)\n\n#### Pause / Resume\n\nA queue can be paused and resumed globally (pass `true` to pause processing for\njust this worker):\n```js\nqueue.pause().then(function () {\n // queue is paused now\n});\n\nqueue.resume().then(function () {\n // queue is resumed now\n})\n```\n\n#### Events\n\nA queue emits some useful events, for example...\n```js\n.on('completed', function (job, result) {\n // Job completed with output result!\n})\n```\n\nFor more information on events, including the full list of events that are fired, check out the [Events reference](./REFERENCE.md#events)\n\n#### Queues performance\n\nQueues are cheap, so if you need many of them just create new ones with different\nnames:\n```javascript\nconst userJohn = new Queue('john');\nconst userLisa = new Queue('lisa');\n.\n.\n.\n```\n\nHowever every queue instance will require new redis connections, check how to [reuse connections](https://github.com/OptimalBits/bull/blob/master/PATTERNS.md#reusing-redis-connections) or you can also use [named processors](https://github.com/OptimalBits/bull/blob/master/REFERENCE.md#queueprocess) to achieve a similar result.\n\n#### Cluster support\n\nNOTE: From version 3.2.0 and above it is recommended to use threaded processors instead.\n\nQueues are robust and can be run in parallel in several threads or processes\nwithout any risk of hazards or queue corruption. Check this simple example\nusing cluster to parallelize jobs across processes:\n```js\nconst Queue = require('bull');\nconst cluster = require('cluster');\n\nconst numWorkers = 8;\nconst queue = new Queue('test concurrent queue');\n\nif (cluster.isMaster) {\n for (let i = 0; i < numWorkers; i++) {\n cluster.fork();\n }\n\n cluster.on('online', function (worker) {\n // Let's create a few jobs for the queue workers\n for (let i = 0; i < 500; i++) {\n queue.add({ foo: 'bar' });\n };\n });\n\n cluster.on('exit', function (worker, code, signal) {\n console.log('worker ' + worker.process.pid + ' died');\n });\n} else {\n queue.process(function (job, jobDone) {\n console.log('Job done by worker', cluster.worker.id, job.id);\n jobDone();\n });\n}\n```\n\n---\n\n\n### Documentation\n\nFor the full documentation, check out the reference and common patterns:\n\n- [Guide](https://optimalbits.github.io/bull/) — Your starting point for developing with Bull.\n- [Reference](./REFERENCE.md) — Reference document with all objects and methods available.\n- [Patterns](./PATTERNS.md) — a set of examples for common patterns.\n- [License](./LICENSE.md) — the Bull license—it's MIT.\n\nIf you see anything that could use more docs, please submit a pull request!\n\n\n\n---\n\n### Important Notes\n\nThe queue aims for an \"at least once\" working strategy. This means that in some situations, a job\ncould be processed more than once. This mostly happens when a worker fails to keep a lock\nfor a given job during the total duration of the processing.\n\nWhen a worker is processing a job it will keep the job \"locked\" so other workers can't process it.\n\nIt's important to understand how locking works to prevent your jobs from losing their lock - becoming _stalled_ -\nand being restarted as a result. Locking is implemented internally by creating a lock for `lockDuration` on interval\n`lockRenewTime` (which is usually half `lockDuration`). If `lockDuration` elapses before the lock can be renewed,\nthe job will be considered stalled and is automatically restarted; it will be __double processed__. This can happen when:\n1. The Node process running your job processor unexpectedly terminates.\n2. 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](https://github.com/OptimalBits/bull/issues/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).\n\nAs 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.\n\nAs 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`).","users":{}}