This topic compares Alibaba Cloud Message Queue for RabbitMQ with open source RabbitMQ in terms of performance, stability, and features.

Performance

Item Message Queue for RabbitMQ Open source RabbitMQ
Peak transactions per second (TPS) of clusters Not limited. Message Queue for RabbitMQ clusters adopt a distributed architecture that involves no primary nodes. This way, the number of nodes in use can be increased or decreased based on business needs, and thus the peak TPS of clusters is not limited. Limited. To improve the performance of open source RabbitMQ clusters, you must upgrade the specifications, which have upper limits.
Peak TPS of a single queue Not limited. Message Queue for RabbitMQ supports the increase of nodes in a single queue. No limit is imposed on the node concurrency, and a queue can have an unlimited size. Limited. The peak TPS of a single queue allowed is the peak TPS of a node allowed in the queue.
Number of connections Not limited. The more nodes a Message Queue for RabbitMQ instance has, the more connections the instance supports. Limited. A single cluster supports only a limited number of connections, and the threshold cannot be adjusted to a higher value. This is due to the limit on cluster performance.
Scheduled messages Supports message scheduling that is accurate to seconds, high-performance, and out-of-the-box. Supports message scheduling, which however is complex to use.

Stability

Item Message Queue for RabbitMQ Open source RabbitMQ
Message accumulation Supports a large number of accumulated messages, and provides high performance even in scenarios of large message accumulation. Cannot support a large number of accumulated messages. Breakdowns may occur due to memory overuse in scenarios of large message accumulation.
Scalability Adopts a distributed architecture that involves no primary nodes. The number of nodes in use can be increased or decreased with efficiency. Requires you to modify the cluster specifications to adjust the cluster performance.
Service availability Adopts a distributed architecture that ensures the high availability of 99.95% of the clusters and provides high availability across zones. Developed by using the Erlang programming language and requires advanced O&M experience. Availability cannot be ensured due to the open source architecture.
Data reliability Uses the triplicate mechanism, which ensures high TPS performance. Cannot ensure high TPS performance if you configure multiple replicas.
Inspection system Automatically detects and fixes issues such as deadlocks and breakdowns. Not supported.

Features

Table 1. General features
Item Message Queue for RabbitMQ Open source RabbitMQ
Support for client SDKs Supports the open source SDK for each language and each SDK version. Supports open source SDKs.
Scheduled messages Supports message scheduling that is accurate to seconds. You can use the x-delayed-message plug-in or specify the time-to-live (TTL) value to enable message scheduling. Requires you to install a plug-in or transfer expired messages to support delayed messages.
Transactional messages Not supported. Supported.
Table 2. Exchange-related features
Item Message Queue for RabbitMQ Open source RabbitMQ
Exchange types Supports direct, fanout, headers, topic, and x-delayed-message exchanges. Supports direct, fanout, headers, topic, and x-delayed-message exchanges.
Persistence Supports both persistent and non-persistent storage of configurations. Supports both persistent and non-persistent storage of configurations.
Auto deletion Supported. Supported.
Internal Supported. Supported.
Alternate exchange Not supported. Supported.
Table 3. Queue-related features
Item Message Queue for RabbitMQ Open source RabbitMQ
Queue type Adopts a distributed architecture that requires no manual configuration of the queue type and provides high availability. Requires manual configuration. Valid types:
  • Classic: classic image queue.
  • Quorum: quorum queue.
Node Requires no manual configuration and no O&M operations. Requires manual configuration. You can select a node as needed.
Persistence Supports both persistent and non-persistent storage. Supports both persistent and non-persistent storage.
Maximum length Requires no manual configuration and supports large message accumulation. Requires manual configuration to prevent breakdowns caused by memory overuse in scenarios of large message accumulation.
Maximum length (in bytes)
Maximum memory size
Maximum memory size (in bytes)
Retry limit Requires no manual configuration. By default, a maximum of 16 retries are allowed. For more information about retries, see Message retry. Requires manual configuration.
Dead letter exchange Supported. Supported.
Dead letter routing key Supported. Supported.
Single active consumer Not supported. Supported.