ApsaraMQ for RabbitMQ is a messaging product that implements the AMQP 0-9-1 protocol and is based on a high-availability (HA) distributed storage architecture. It 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 in terms of features, stability, performance, exchanges, and queues to help you better understand the capabilities of ApsaraMQ for RabbitMQ.
For more information about ApsaraMQ for RabbitMQ, see Benefits.
Features
Item | 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 support | Supports open source SDKs for all languages and versions. | Open source SDKs. |
Scheduled message | Provides second-level precision. It is compatible with both the x-delayed-message plug-in and the time to live (TTL) method. For more information, see Delayed messages. | Implemented using a plug-in or the message TTL expiration and transfer method. |
Transactional message | Not supported. | Supported. |
Ordered message | Supported. For more information, see Ordered consumption of messages. | Supported. |
Message priority | Supported only by dedicated instances. | Supported. |
Message retry mechanism | Messages are redelivered if they are not acknowledged within a specified period. For more information about the timeout period and the number of retries, see Retry policy. | No message retry mechanism is provided. Problematic messages cannot be skipped during consumption, which prevents new messages from being processed. This can lead to message accumulation, memory issues, and service breakdowns. |
Username and password |
| Custom username and password. |
Permission |
| Open source permission management. |
Observability: Dashboard |
For more information, see Dashboard. | Supports the following two solutions:
|
Observability: Message trace |
For more information, see Message trace. | Message trace information is stored in text-based log files on the server. This makes querying and identifying issues inefficient. |
Service and performance
Item | ApsaraMQ for RabbitMQ | Open source RabbitMQ |
Maximum cluster transactions per second (TPS) | No upper limit. ApsaraMQ for RabbitMQ uses a masterless, distributed cluster deployment. The cluster can be scaled out or in horizontally. | Has an upper limit. Scaling out depends on upgrading device specifications, which is limited. |
Maximum TPS for a single queue | No upper limit. ApsaraMQ for RabbitMQ supports horizontal scaling for a single queue. It has no performance or capacity limits related to concurrency. | Has an upper limit. The performance of a single queue is limited by the performance of a single node. |
Connections | No upper limit. The number of connections that an ApsaraMQ for RabbitMQ instance can handle increases as the cluster scales out. Performance is not affected by an increase in connections. | Has an upper limit. The number of connections for a single machine is limited by its performance and cannot be scaled out. |
Scheduled message | Second-level precision, high performance, and ready to use. | Complex to use. |
Service availability and data reliability |
| Implemented using mirror queues or quorum queues. This implementation is prone to split-brain issues. |
Message accumulation capacity | Maintains high performance even with a massive accumulation of messages. The normal operation of the cluster is not affected. | A large accumulation of messages can easily cause memory issues, which may lead to service breakdowns. |
Elasticity |
| The capacity of a single machine is the upper limit for the cluster's concurrent capacity. Scaling out requires you to upgrade machine specifications or split the cluster. |
Inspection system | Automatically detects and fixes issues such as deadlocks and breakdowns. | None. |
Exchanges and queues
Table 1. Exchange
Item | ApsaraMQ for RabbitMQ | Open source RabbitMQ |
Exchange type | Supports direct, fanout, headers, topic, x-delayed-message, and x-consistent-hash types. | Supports direct, fanout, headers, topic, x-delayed-message, and x-consistent-hash types. |
Persistence | Supports both persistent and non-persistent configurations. | Supports both persistent and non-persistent configurations. |
Auto delete | Supported. | Supported. |
Internal | Supported. | Supported. |
Alternate exchange | Supported. | Supported. |
Consistent hash exchange | Supported. | Supported. |
Table 2. Queue
Item | ApsaraMQ for RabbitMQ | Open source RabbitMQ |
Queue type | No configuration is required. It is a distributed HA cluster. | Configuration is required.
|
Node | No configuration is required. The service is operations and maintenance (O&M)-free. | Configuration is required. You can select nodes. |
Retry policy | Messages are redelivered if a consumption timeout occurs. For more information about the retry policy, see Retry policy. | No timeout redelivery policy is available. |
Persistence | Supports both persistent and non-persistent configurations. | Supports both persistent and non-persistent configurations. |
Max length | No configuration is required. Supports massive message accumulation. | Configuration is required to prevent memory issues and breakdowns caused by excessive message accumulation. |
Max length bytes | ||
Max in memory length | ||
Max in memory bytes | ||
Delivery limit | No configuration is required. This is a static field with a default value of 16. For more information about the message retry mechanism, see Retry policy. | Configuration is required. |
Dead letter exchange | Supported. | Supported. |
Dead letter routing key | Supported. | Supported. |
Single active consumer | Supported. For more information, see Ordered consumption of messages. | Supported. |