ApsaraMQ for RabbitMQ is a fully managed messaging service built on a distributed, high-availability storage architecture. It implements the AMQP 0-9-1 protocol and is compatible with open-source RabbitMQ clients. Compared with open-source RabbitMQ, ApsaraMQ for RabbitMQ resolves common stability pain points, such as message accumulation and split-brain issues. It also offers the benefits of a cloud messaging service, such as high concurrency, distributed deployment, and flexible scaling.
This topic compares ApsaraMQ for RabbitMQ with open-source RabbitMQ across features, scalability, reliability, exchanges, and queues.
For a full list of advantages, see Benefits.
Features
Feature | ApsaraMQ for RabbitMQ | Open-source RabbitMQ |
Protocol | AMQP 0-9-1 | AMQP 0-9-1, AMQP 1.0, STOMP, MQTT, HTTP(S), and WebSocket |
Client SDK | All open-source RabbitMQ client SDKs (any language, any version) | Open-source SDKs |
Delayed messages | Second-level precision. Compatible with both the x-delayed-message plug-in and the TTL method. See Delayed messages. | Requires plug-in or the message TTL expiration and transfer method |
Transactional messages | Not supported | Supported |
Ordered messages | Supported. See Ordered consumption of messages. | Supported |
Message priority | Dedicated instances only | Supported |
Message retry | Automatic redelivery when messages are not acknowledged within a timeout period. See Retry policy. | No built-in retry. Unacknowledged messages block the queue, which can cause accumulation and service disruption. |
Authentication | Custom username and password, or credentials generated from an AccessKey pair in Resource Access Management (RAM). See Static usernames and passwords and RAM credentials. | Custom username and password |
Access control | Open-source permission model and RAM policy-based authorization. See Permission management and RAM access control. | Open-source permission model |
Observability
Capability | ApsaraMQ for RabbitMQ | Open-source RabbitMQ |
Dashboard | Built-in metrics at the vhost, exchange, and queue level. Prometheus and Grafana integration is preconfigured. See Dashboard. | Two options: (1) Use the management UI for metrics, but build your own storage and visualization layer. (2) Set up Prometheus and Grafana manually. |
Message tracing | Console-based trace view showing the full message lifecycle. Query by queue, message ID, or processing time. See Message traces. | Trace data is written to server-side log files, making querying and root-cause analysis slow. |
AMQP Commands
The following table compares the behavior of the BasicCancel AMQP command between ApsaraMQ for RabbitMQ and open-source RabbitMQ.
Item | ApsaraMQ for RabbitMQ | Open-source RabbitMQ |
| Cancels the consumer subscription; already-delivered messages are requeued. | Cancels the consumer subscription; already-delivered messages remain in the Unacked state. |
This difference matters when troubleshooting message delivery after consumer cancellation. In ApsaraMQ for RabbitMQ, requeuing after BasicCancel means unacknowledged messages may be redelivered to other consumers. In open-source RabbitMQ, those messages remain unacknowledged until the channel closes or the timeout expires.
Scalability and reliability
Dimension | ApsaraMQ for RabbitMQ | Open-source RabbitMQ |
Cluster throughput | No fixed upper limit. A masterless, distributed architecture supports horizontal scale-out. | Bounded by single-node capacity. Scaling up requires hardware upgrades. |
Single-queue throughput | No fixed upper limit. Each queue scales horizontally across nodes. | Bounded by the node that hosts the queue. |
Connections | Scale with the cluster. Adding nodes increases connection capacity without degrading performance. | Bounded by single-machine resources. |
Delayed messages | Second-level precision, high throughput, ready to use | Requires plug-in setup |
High availability | Multi-zone deployment with storage-compute separation. Faulty compute nodes can be quickly removed and isolated. Data is stored in triplicate. | Relies on mirror queues or quorum queues. This implementation is prone to split-brain issues. |
Message accumulation | Maintains stable performance even with massive backlogs. The normal operation of the cluster is not affected. | Large backlogs consume node memory and can trigger out-of-memory failures, leading to service disruption. |
Elastic scaling | Scale out or in by adding or removing cluster nodes on demand. Serverless instances bill based on message volume, eliminating the need for upfront capacity planning. | Capacity is constrained by the largest machine in the cluster. Scaling requires hardware upgrades or cluster re-partitioning. |
Self-healing | A built-in inspection system automatically detects and resolves deadlocks and node failures. | No automated self-healing. Manual intervention is required. |
Exchanges
ApsaraMQ for RabbitMQ supports the same exchange types and properties as open-source RabbitMQ.
Property | ApsaraMQ for RabbitMQ | Open-source RabbitMQ |
Types | direct, fanout, headers, topic, x-delayed-message, x-consistent-hash | direct, fanout, headers, topic, x-delayed-message, x-consistent-hash |
Persistence | Persistent and non-persistent | Persistent and non-persistent |
Auto-delete | Supported | Supported |
Internal | Supported | Supported |
Alternate exchange | Supported | Supported |
Consistent hash exchange | Supported | Supported |
Queues
ApsaraMQ for RabbitMQ abstracts away queue-level infrastructure decisions. All queues run on a distributed high-availability cluster, so there is no need to choose between classic and quorum queue types or to configure replication manually.
Property | ApsaraMQ for RabbitMQ | Open-source RabbitMQ |
Queue type | Distributed HA cluster (no configuration required) | Manual selection required: classic (mirror queue) or quorum queue |
Node assignment | Fully managed, no manual assignment | Manual node selection required |
Retry policy | Automatic redelivery on consumption timeout. See Retry policy. | No timeout-based redelivery |
Persistence | Persistent and non-persistent | Persistent and non-persistent |
Max length / max length bytes / max in-memory length / max in-memory bytes | No configuration required. Supports massive message accumulation without memory pressure. | Must be configured to prevent out-of-memory failures caused by unbounded accumulation. |
Delivery limit | Default value of 16 (static). See Retry policy. | Manual configuration required |
Dead-letter exchange | Supported | Supported |
Dead-letter routing key | Supported | Supported |
Single active consumer | Supported. See Ordered consumption of messages. | Supported |
Action
The following table compares the behavior of the BasicCancel AMQP command between ApsaraMQ for RabbitMQ and open-source RabbitMQ.
Item | ApsaraMQ for RabbitMQ | Open-source RabbitMQ |
BasicCancel | Cancels the consumer subscription; already-delivered messages are requeued. | Cancels the consumer subscription; already-delivered messages remain in the Unacked state. |