Connecting EventBridge to RocketMQ 4.0, 5.0 & Self‑Hosted Clusters: A Step‑by‑Step Guide

Overview

Alibaba Cloud Message Queue (MQ) RocketMQ edition is a low‑latency, high‑concurrency, highly‑available distributed platform built on Apache RocketMQ. The latest 5.0 release adds extensive architectural, networking, load‑balancing, and storage optimizations, expanding its scope from simple message decoupling to event‑driven and streaming scenarios. EventBridge, Alibaba Cloud’s event hub, now provides a unified connector for both RocketMQ 4.0 and 5.0, as well as self‑hosted Apache RocketMQ clusters.

RocketMQ 4.0 Architecture

The classic client‑nameserver‑broker model consists of four components:

Name Server : a lightweight, stateless node that can be clustered; it provides service discovery and updates for brokers.

Broker : stores and forwards messages; each Master Broker can have multiple Slave Brokers, while a Slave can belong to only one Master. Brokers register with the Name Server and report topic routing every 30 seconds.

Producer : establishes a long‑living keep‑alive connection to a random Name Server node, fetches topic routes, and connects to the appropriate Master Broker, sending periodic heartbeats.

Consumer : similarly connects to a random Name Server, pulls topic routes, and establishes connections to both Master and Slave Brokers. Subscription rules are defined by the broker.

API Usage for RocketMQ 4.0

Creating a custom event bus and source in EventBridge follows a consistent pattern. Key parameters include:

Version – select 4.x or 5.x.

RocketMQ Instance – the instance ID (e.g., MQ_INST_123456789***_BX6zY7ah).

Topic – the RocketMQ topic to read from or write to.

Tag – consumer‑side tag for message filtering.

Group ID – identifies a consumer group (required for source tasks).

Consume Position – initial offset (latest, earliest, or a specific timestamp).

RocketMQ 5.0 Architecture and Improvements

Version 5.0 separates storage logic from compute, delivering multi‑replica, low‑latency, massive‑partition queues. The broker focuses on storage while a stateless compute layer handles protocol adaptation, permission management, consumption state, and observability. Notable enhancements:

Lightweight SDK with dual protocol support (4.x and new gRPC) and built‑in OpenTelemetry metrics (10+ new metrics).

Message‑level load balancing, making each message the smallest scheduling unit.

Multi‑network access: a single instance can expose both public and private endpoints.

Tiered storage: unlimited‑size messages retained up to 30 days, with hot‑cold separation to reduce performance impact of historical consumption.

5.0 also supports VPC‑based secure identification, allowing users to migrate to the cloud without code changes. After granting EventBridge the necessary network and RocketMQ permissions, EventBridge automatically fills VPC, switch, and security‑group information when creating source or sink tasks.

API Usage for RocketMQ 5.0

Compared with 4.0, the 5.0 API adds three parameters:

VPC – the VPC where the RocketMQ instance resides.

Switch – the network switch associated with the instance.

Security Group – controls EventBridge’s access policy within the VPC. Users can select an existing group or let EventBridge create a default one.

Self‑Hosted Apache RocketMQ Integration

EventBridge also supports exporting messages from user‑managed Apache RocketMQ clusters. Users provide the nameserver address (future support for proxy), topic, tag, group ID, filter type, authentication mode (if ACL is enabled), consume position, VPC, switch, and security‑group details. The access path mirrors the 5.0 cloud version, differing only in the nameserver endpoint.

Message Routing via EventBridge

Message routing is achieved by creating an EventBridge event flow. The flow reads from a source RocketMQ instance in one region and writes to a target instance in another region. For intra‑China routing, EventBridge handles the cross‑region network; for cross‑border scenarios (e.g., Beijing to Singapore), the target’s public endpoint is used, requiring the user to supply a VPC with NAT capability.

Step‑by‑Step Creation of a RocketMQ Message Routing Task

Open the EventBridge console, select the target region, and navigate to “Event Flow → Create Event Flow”.

On the source page, choose “Message Queue RocketMQ Edition”, select the source region (e.g., Qingdao), and fill in the required RocketMQ parameters.

Configure the rule page (default settings are usually sufficient).

On the target page, select “Message Queue RocketMQ Edition” again and provide the destination region and parameters.

Confirm and create; the event flow will start and handle message synchronization.

Conclusion

The article provides a comprehensive reference for integrating EventBridge with various RocketMQ deployments—cloud‑based 4.0, 5.0, and self‑hosted clusters—detailing architecture, required API fields, VPC/security considerations, and practical steps for building event‑driven systems and implementing disaster‑recovery or cross‑region message synchronization.