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. |
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 |