Bull vs RSMQ vs RabbitMQ

Overview

RabbitMQ

Stacks21.8K

Followers18.9K

Votes558

GitHub Stars13.2K

Forks4.0K

RSMQ

Stacks4

Followers87

Votes6

GitHub Stars1.8K

Forks120

Bull

Stacks92

Followers113

Votes1

GitHub Stars16.2K

Forks1.4K

Bull vs RSMQ vs RabbitMQ: What are the differences?

Bull, RSMQ, and RabbitMQ are three popular message queue systems. Let's explore the key differences that set them apart.

Scalability: Bull is designed to scale horizontally, allowing you to distribute your workload across multiple processes or even machines. On the other hand, RSMQ is more suitable for smaller applications that can be handled by a single server. RabbitMQ, being built on the Erlang programming language, is highly scalable and can handle large-scale enterprise applications efficiently.
Persistence: Bull and RSMQ both provide persistent message storage, meaning that messages can be stored even if the server goes down and can be recovered later. RabbitMQ goes a step further by providing a choice of multiple message persistence options like in-memory storage, file system storage, or a combination of both.
Message Priority: Bull and RSMQ both support priority queues, allowing you to assign priorities to different messages and ensure that higher priority messages are processed first. RabbitMQ, on the other hand, uses a different approach called "message ordering" to handle message priorities, ensuring that messages are processed in the order they are received.
Ease of Use: Bull is known for its simplicity and ease of use, making it a preferred choice for developers who want to get started quickly. RSMQ, being a lightweight alternative, also offers ease of use but with limited features. RabbitMQ, on the other hand, provides a rich set of features and is suitable for more complex use cases, but it requires a deeper understanding of messaging concepts and may have a steeper learning curve.
Language Support: Bull, being built on top of Node.js, is primarily used with JavaScript or TypeScript applications. RSMQ, also built for Node.js, has broader language support, including JavaScript, TypeScript, and Python. RabbitMQ, being language-agnostic, can be used with practically any programming language as it provides client libraries for various platforms.
Message Routing: Bull and RSMQ follow a simple publish-subscribe model, where messages are sent to a specific queue and any interested consumers can consume them. RabbitMQ, on the other hand, provides advanced message routing capabilities through its exchange mechanism, allowing messages to be routed based on criteria like routing keys or message headers, enabling more complex routing scenarios.

In summary, Bull is lightweight and easy to use, suitable for simple use cases, while RSMQ offers similar simplicity but with broader language support. RabbitMQ, being a robust and highly scalable messaging system, provides advanced features and language-agnostic support but requires more understanding of messaging concepts.

Share your Stack

Help developers discover the tools you use. Get visibility for your team's tech choices and contribute to the community's knowledge.

View Docs

CLI (Node.js)

Manual

Advice on RabbitMQ, RSMQ, Bull

viradiya

Apr 12, 2020

Needs adviceon

AngularJS

ASP.NET Core

MSSQL

We are going to develop a microservices-based application. It consists of AngularJS, ASP.NET Core, and MSSQL.

We have 3 types of microservices. Emailservice, Filemanagementservice, Filevalidationservice

I am a beginner in microservices. But I have read about RabbitMQ, but come to know that there are Redis and Kafka also in the market. So, I want to know which is best.

933k views933k

Comments

André

Technology Manager at GS1 Portugal - Codipor

Jul 30, 2020

Needs adviceon

.NET Core

Hello dear developers, our company is starting a new project for a new Web App, and we are currently designing the Architecture (we will be using .NET Core). We want to embark on something new, so we are thinking about migrating from a monolithic perspective to a microservices perspective. We wish to containerize those microservices and make them independent from each other. Is it the best way for microservices to communicate with each other via ESB, or is there a new way of doing this? Maybe complementing with an API Gateway? Can you recommend something else different than the two tools I provided?

We want something good for Cost/Benefit; performance should be high too (but not the primary constraint).

Thank you very much in advance :)

461k views461k

Comments

mediafinger

Feb 13, 2019

Reviewon

Kafka

RabbitMQ

The question for which Message Queue to use mentioned "availability, distributed, scalability, and monitoring". I don't think that this excludes many options already. I does not sound like you would take advantage of Kafka's strengths (replayability, based on an even sourcing architecture). You could pick one of the AMQP options.

I would recommend the RabbitMQ message broker, which not only implements the AMQP standard 0.9.1 (it can support 1.x or other protocols as well) but has also several very useful extensions built in. It ticks the boxes you mentioned and on top you will get a very flexible system, that allows you to build the architecture, pick the options and trade-offs that suite your case best.

For more information about RabbitMQ, please have a look at the linked markdown I assembled. The second half explains many configuration options. It also contains links to managed hosting and to libraries (though it is missing Python's - which should be Puka, I assume).

159k views159k

Comments

Detailed Comparison

RabbitMQ	RSMQ	Bull
RabbitMQ gives your applications a common platform to send and receive messages, and your messages a safe place to live until received.	tl;dr: If you run a Redis server and currently use Amazon SQS or a similar message queue you might as well use this fast little replacement. Using a shared Redis server multiple Node.js processes can send / receive messages.	The fastest, most reliable, Redis-based queue for Node. Carefully written for rock solid stability and atomicity.
Robust messaging for applications;Easy to use;Runs on all major operating systems;Supports a huge number of developer platforms;Open source and commercially supported	Lightweight: Just Redis and ~500 lines of javascript.;Guaranteed delivery of a message to exactly one recipient within a messages visibility timeout.;Received messages that are not deleted will reappear after the visibility timeout.;Test coverage;Optional RESTful interface via rest-rsmq	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.
Statistics
GitHub Stars 13.2K	GitHub Stars 1.8K	GitHub Stars 16.2K
GitHub Forks 4.0K	GitHub Forks 120	GitHub Forks 1.4K
Stacks 21.8K	Stacks 4	Stacks 92
Followers 18.9K	Followers 87	Followers 113
Votes 558	Votes 6	Votes 1
Pros & Cons
Pros 235 It's fast and it works with good metrics/monitoring 80 Ease of configuration 60 I like the admin interface 52 Easy to set-up and start with 22 Durable Cons 9 Too complicated cluster/HA config and management 6 Needs Erlang runtime. Need ops good with Erlang runtime 5 Configuration must be done first, not by your code 4 Slow	Pros 2 Simple, does one thing well 1 Written in Coffeescript 1 Backed by Redis 1 Comes with a visibility timeout feature similar to AWS 1 Written in TypeScript	Pros 1 Ease of use
Integrations
No integrations available	Redis	Node.js

What are some alternatives to RabbitMQ, RSMQ, Bull?

Kafka

Kafka is a distributed, partitioned, replicated commit log service. It provides the functionality of a messaging system, but with a unique design.

Sidekiq

Sidekiq uses threads to handle many jobs at the same time in the same process. It does not require Rails but will integrate tightly with Rails 3/4 to make background processing dead simple.

Celery

Celery is an asynchronous task queue/job queue based on distributed message passing. It is focused on real-time operation, but supports scheduling as well.

Amazon SQS

Transmit any volume of data, at any level of throughput, without losing messages or requiring other services to be always available. With SQS, you can offload the administrative burden of operating and scaling a highly available messaging cluster, while paying a low price for only what you use.

NSQ

NSQ is a realtime distributed messaging platform designed to operate at scale, handling billions of messages per day. It promotes distributed and decentralized topologies without single points of failure, enabling fault tolerance and high availability coupled with a reliable message delivery guarantee. See features & guarantees.

ActiveMQ

Apache ActiveMQ is fast, supports many Cross Language Clients and Protocols, comes with easy to use Enterprise Integration Patterns and many advanced features while fully supporting JMS 1.1 and J2EE 1.4. Apache ActiveMQ is released under the Apache 2.0 License.

Beanstalkd

Beanstalks's interface is generic, but was originally designed for reducing the latency of page views in high-volume web applications by running time-consuming tasks asynchronously.

ZeroMQ

The 0MQ lightweight messaging kernel is a library which extends the standard socket interfaces with features traditionally provided by specialised messaging middleware products. 0MQ sockets provide an abstraction of asynchronous message queues, multiple messaging patterns, message filtering (subscriptions), seamless access to multiple transport protocols and more.

Apache NiFi

An easy to use, powerful, and reliable system to process and distribute data. It supports powerful and scalable directed graphs of data routing, transformation, and system mediation logic.

Gearman

Gearman allows you to do work in parallel, to load balance processing, and to call functions between languages. It can be used in a variety of applications, from high-availability web sites to the transport of database replication events.

Related Comparisons

Bull vs RSMQ vs RabbitMQ: What are the differences?

Bull, RSMQ, and RabbitMQ are three popular message queue systems. Let's explore the key differences that set them apart.

Scalability: Bull is designed to scale horizontally, allowing you to distribute your workload across multiple processes or even machines. On the other hand, RSMQ is more suitable for smaller applications that can be handled by a single server. RabbitMQ, being built on the Erlang programming language, is highly scalable and can handle large-scale enterprise applications efficiently.
Persistence: Bull and RSMQ both provide persistent message storage, meaning that messages can be stored even if the server goes down and can be recovered later. RabbitMQ goes a step further by providing a choice of multiple message persistence options like in-memory storage, file system storage, or a combination of both.
Message Priority: Bull and RSMQ both support priority queues, allowing you to assign priorities to different messages and ensure that higher priority messages are processed first. RabbitMQ, on the other hand, uses a different approach called "message ordering" to handle message priorities, ensuring that messages are processed in the order they are received.
Ease of Use: Bull is known for its simplicity and ease of use, making it a preferred choice for developers who want to get started quickly. RSMQ, being a lightweight alternative, also offers ease of use but with limited features. RabbitMQ, on the other hand, provides a rich set of features and is suitable for more complex use cases, but it requires a deeper understanding of messaging concepts and may have a steeper learning curve.
Language Support: Bull, being built on top of Node.js, is primarily used with JavaScript or TypeScript applications. RSMQ, also built for Node.js, has broader language support, including JavaScript, TypeScript, and Python. RabbitMQ, being language-agnostic, can be used with practically any programming language as it provides client libraries for various platforms.
Message Routing: Bull and RSMQ follow a simple publish-subscribe model, where messages are sent to a specific queue and any interested consumers can consume them. RabbitMQ, on the other hand, provides advanced message routing capabilities through its exchange mechanism, allowing messages to be routed based on criteria like routing keys or message headers, enabling more complex routing scenarios.

Bull vs RSMQ vs RabbitMQ

Overview