When your business spans multiple regions, keeping messages and consumer progress in sync across ApsaraMQ for RocketMQ instances requires building and maintaining custom replication pipelines. Global Replicator eliminates this overhead by providing built-in cross-region message replication with seconds-level latency, supporting geo-disaster recovery, active geo-redundancy, and centralized data aggregation. Global Replicator is compatible with both ApsaraMQ for RocketMQ and open-source Apache RocketMQ clusters (version 4.4.0 or later).
What gets replicated
| Data type | Supported |
|---|---|
| Normal messages | Yes |
| Ordered messages | Yes |
| Scheduled or delayed messages | Yes |
| Transactional messages | Yes |
| Consumer progress (offsets) | Yes |
Global Replicator supports both one-way and two-way synchronization. Two-way synchronization prevents circular replication by default.
If the source instance encounters an error, the quick synchronization feature syncs consumer progress from the destination group back to the source instance, reducing duplicate message consumption.
How it works
Global Replicator replicates messages asynchronously through connectors. These connectors scale in seconds, apply rule-based tags to messages, and support resumable upload and download.
Cross-region network connectivity between instances is handled by Cloud Enterprise Network (CEN), delivering message synchronization with seconds-level latency.
During synchronization, Global Replicator adds tags to each message based on the tag key and value specified in user attributes. Consumer applications filter these tags using the SQL-92 filtering method to control whether they receive all data or only locally produced data.
Global Replicator consumes read and write resources on the ApsaraMQ for RocketMQ instances involved. Evaluate your instance computing specifications before enabling the feature.
Use cases
All clusters involved in Global Replicator are independent instances with full read and write capabilities. Messages replicate asynchronously between them.
Data aggregation (one-way)
Aggregate messages from multiple regions or instances into a central region for unified processing. Each business unit processes data on the nearest server, avoiding cross-network latency. One-way synchronization replicates data from distributed regions and instances -- including open-source Apache RocketMQ and ApsaraMQ for RocketMQ clusters -- to a single central location.
Typical industries: Banking, securities, insurance
Architecture pattern: Multiple units, single center
Geo-disaster recovery (one-way)
Maintain a standby instance in a secondary region that stays in sync through one-way replication. If the primary data center or region fails, switch traffic to the standby to restore service quickly.
Typical industries: All
Architecture pattern: Two regions, two data centers
Under normal operation, no applications run in the secondary region, which reduces resource consumption and cost. During a failover, start the applications in the secondary region and use the consumer offset resetting feature to consume a minimum number of historical messages on the source instance.
Because replication is asynchronous, a small amount of data may not have reached the standby instance at the time of failure. Implement message idempotence in your business logic to handle potential duplicates after failover.
Active geo-redundancy (two-way)
Deploy applications in multiple regions simultaneously, with two-way synchronization keeping messages in sync across all active instances. Both regions serve production traffic at all times, ensuring business continuity if one region becomes unavailable.
Typical industries: Finance, energy, and other industries where service continuity is critical
Architecture pattern: Two regions, two data centers
Global Replicator automatically tags synchronized messages. Producer applications require no code changes. Consumer applications use the SQL-92 filtering method to select either full data or only local data based on these tags.
During a regional failure, producer applications route all traffic to the healthy instance. Adjust the filtering conditions on consumer applications, and use the consumer offset resetting feature to consume messages from other regions with minimal duplication. Design your business logic to be idempotent so that duplicate messages do not affect downstream processing.
Message tagging details
The instance that an application connects to is determined by the configured endpoint. During synchronization, Global Replicator adds tags to each replicated message based on the tag key and value in the user attributes. Consumer applications use these tags to control whether they receive all data or only locally produced data.
For details on tagging behavior and consumer configuration, see Usage notes.
Benefits
Low-code setup: Replicate messages between instances without building custom synchronization pipelines.
Flexible configuration: Set up one-way or two-way synchronization and use tag-based filtering for selective message consumption.
Seconds-level cross-region latency: Built on EventBridge, Global Replicator delivers stable, low-latency message synchronization across regions.
Billing
Global Replicator incurs costs from two services:
EventBridge: Global Replicator uses EventBridge for message synchronization. For pricing details, see EventBridge billing.
ApsaraMQ for RocketMQ: Replication consumes read resources on the source instance and write resources on the destination instance. For pricing details, see ApsaraMQ for RocketMQ billing.
Supported editions, versions, and regions
Editions and versions
| Edition / version | One-way sync | Two-way sync |
|---|---|---|
| ApsaraMQ for RocketMQ 5.0 | Yes | Yes |
| ApsaraMQ for RocketMQ 4.0 (all editions except Standard) | Yes | Yes |
| ApsaraMQ for RocketMQ 4.0 (Standard Edition) | Yes | No |
| ApsaraMQ for RocketMQ Enterprise Platinum Edition with Apache RocketMQ clusters (version 4.4.0 or later) | Yes | Yes |
Global Replicator supports synchronizing data from one ApsaraMQ for RocketMQ instance to multiple destination instances.