ApsaraMQ for RocketMQ is a distributed platform from Alibaba Cloud that is built on Apache RocketMQ. It provides a unified solution for processing messages, events, and streams with low latency, high concurrency, high availability, and high reliability. With the release of Apache RocketMQ 5.0, ApsaraMQ for RocketMQ offers the more stable and reliable server-side v5.x. This topic describes the differences and compatibility between the server-side v5.x and v4.x of ApsaraMQ for RocketMQ.
Advantages of v5.x
Compared with previous server-side versions, ApsaraMQ for RocketMQ v5.x offers the following advantages:
More advanced architecture
It uses a message architecture that separates storage from computing. Storage and computing resources can be scaled out horizontally and independently as needed. This architecture supports efficient, elastic operations and maintenance (O&M) and provides high-performance, large-scale capabilities.
Lower development barrier
It primarily supports access through client software development kits (SDKs) that are fully compatible with Apache RocketMQ. It is also compatible with all previous versions of SDKs and API operations.
It supports secure access within a Virtual Private Cloud (VPC). You can migrate to the cloud by simply modifying the endpoint, without any code changes.
Lower O&M barrier
It provides solutions, such as automatic elasticity and lightweight test environments, for common challenges. These challenges include online capacity assessment, managing elastic service traffic during peak and off-peak hours, and maintaining daily grayscale environments. This lowers the overall O&M barrier and reduces risks.
More flexible costs
Through optimizations in cloud infrastructure technology, computing resources for sending and receiving messages support both reserved capacity and elastic bursting for traffic spikes. This means you do not need to reserve a large buffer for burst traffic.
Message storage is pay-as-you-go. This model offers a significant advantage in elasticity compared with mounted disks, which cannot be scaled in.
More comprehensive billing models
It offers more comprehensive service tiers and supports both subscription and pay-as-you-go billing models.
SDK versions
The following table describes the SDK versions and feature support for ApsaraMQ for RocketMQ.
In the table, ✅ indicates that the feature is supported, and ❌ indicates that the feature is not supported.
Comparison Item | ||||||
Protocol | gRPC protocol v2 | Remoting protocol | Remoting protocol | Remoting protocol | gRPC protocol v1 | HTTP protocol |
Accessible instances | v5.x series instances |
|
|
| v4.x series instances | v4.x series instances |
Recommendations | The 5.x gRPC SDK is recommended.
|
|
| |||
Sending normal, ordered, transactional, and scheduled messages | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Concurrent consumption | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
Ordered consumption | ✅ | ✅ | ✅ | ✅ | ✅ | ✅ |
✅ | ❌ | ❌ | ❌ | ❌ | ❌ | |
Broadcasting consumption | ❌ | ✅ | ✅ | ✅ | ❌ | ❌ |
Stream consumption (connecting to Flink, etc.) | ❌ | ✅ | ✅ | ❌ | ❌ | ❌ |
Message trace | ✅ | ✅ | Supported in v4.5.2 and later | ✅ | ✅ | ❌ |
✅ | ❌ | ❌ | ❌ | ❌ | ❌ | |
✅ | Supported only for v5.x series instances | ❌ | ❌ | ❌ | ❌ | |
Feature compatibility between v4.x and v5.x
ApsaraMQ for RocketMQ v5.x instances are optimized based on production experience with large-scale enterprise customers. The behavior of some features in the message sending and receiving process has been adjusted. As a result, parameter configurations and feature behaviors may differ in some scenarios. These differences generally do not affect the primary message sending and receiving process. If you upgrade an existing v4.x instance to v5.x, you must assess the risks as needed.
The specific differences in feature behavior are as follows:
Feature Difference | v4.x | v5.x | Description |
Maximum delay for scheduled messages | 40 days |
| Very long delay parameters can cause stability risks to the system. Do not set the delay for too long. Use short timers to simulate business scenarios. For more information, see Scheduled and delayed messages. If you are migrating an existing v4.x instance and the maximum delay does not meet your requirements, submit a ticket for consultation. |
HTTP protocol support | Supported | Not supported | v5.x does not currently support the HTTP protocol. If your existing v4.x instance uses the HTTP protocol, postpone the upgrade. |
RAM authorization policy | Data link + control link | Supports control link, but the authorization policy is different from v4.x |
|
Global message routing | Supported | Not supported | v5.x does not support configuring global message routing tasks. Use the message integration feature to synchronize messages between instances. For more information, see Message integration. |
Message type restrictions | No restrictions | Strict restrictions | In v5.x, message types are separated into topics for independent O&M and processing. The system strictly validates the sent message type against the message type defined for the topic. If the validation fails, the message sending request is rejected, and a type mismatch exception is returned. For more information, see Topic behavior constraints. |
Purchase restrictions
ApsaraMQ for RocketMQ v5.x instances can be purchased and activated by all users.
Purchase of ApsaraMQ for RocketMQ v4.x instances is limited to existing users. We recommend that you upgrade your instances to v5.x. If you want to upgrade, submit a ticket.
Upgrading from v4.x to v5.x
You cannot perform an in-place upgrade of a v4.x instance to v5.x. To upgrade, you must purchase a v5.x instance and gradually migrate your service traffic to the new instance. The following figure shows the migration process.
As shown in the figure, in the second step, you can use the topic and group import and export features to quickly create metadata. For more information, see Import or export topics and Import or export groups.
When you migrate your services, you can use the dual-read, dual-write, and phased release solution shown in the following figure.
