Backend Development 7 min read

RocketMQ Practical Guide: Overview, Architecture, and Dual‑Master Deployment Steps

This article introduces RocketMQ, compares it with ActiveMQ, explains its producer/consumer group model, describes various broker deployment modes, and provides a step‑by‑step dual‑master installation guide with configuration, log, and console setup instructions.

Java Captain
Java Captain
Java Captain
RocketMQ Practical Guide: Overview, Architecture, and Dual‑Master Deployment Steps

Alibaba’s two core distributed technologies are OceanBase and RocketMQ; this practical series covers RocketMQ’s overview, environment setup, basic usage, API details, architecture analysis, and administrator cluster operations.

What is RocketMQ?

RocketMQ is a distributed message middleware that evolved from MetaQ 1.x and 2.x and was hardened by Taobao’s Double‑11 events, offering performance and features far beyond ActiveMQ.

RocketMQ natively supports distribution, whereas ActiveMQ is single‑point.

RocketMQ guarantees strict message ordering; ActiveMQ cannot.

It can accumulate billions of messages while maintaining low write latency.

Supports both push and pull consumption modes; pull gives the application control over message fetching and offset tracking.

Earlier MetaQ versions used Zookeeper for coordination; RocketMQ implements a lightweight NameServer with better performance.

Features include retry mechanisms, horizontal subscriber scaling, powerful APIs, transaction support, etc.

Initial Understanding of Producer/Consumer Group

Unlike ActiveMQ, RocketMQ introduces the concept of a consumer group, which enables natural load balancing: if a topic has 9 messages and a consumer group has 3 instances, each instance will receive 3 messages.

Install RocketMQ

RocketMQ broker clusters can be deployed in several modes: single‑master, multi‑master, multi‑master with async slaves, and multi‑master with synchronous double‑write slaves. A RocketMQ slave can read but not write, similar to MySQL’s master‑slave architecture.

Step 1: Modify /etc/hosts

Ensure the machines can resolve each other’s hostnames (see image).

Step 2: Extract package and create storage directories

tar -xvf alibaba-rocketmq-3.2.6.tar.gz
mkdir -p alibaba-rocketmq/store/{commitlog,consumequeue,index}

Step 3: Configure broker properties

Set the necessary properties in broker-x.properties (see image).

Step 4: Adjust log configuration

Replace the placeholder ${user.home} in logback.*.xml files, e.g. using sed :

sed -i 's#${user.home}#/software/alibaba-rocketmq#g' *.xml

Step 5: Modify JVM parameters in the startup scripts

Set the initial and maximum heap size to 1 GB and the young generation to 512 MB (adjustable for production environments).

Step 6: Start the NameServer

nohup sh mqnamesrv &

Check the startup logs to confirm the NameServer is running.

Step 7: Start the broker

Launch each broker instance (e.g., broker‑X) and monitor the broker logs for successful startup.

Step 8: Deploy RocketMQ Console

Deploy rocketmq-console.war to a Tomcat server, then edit config.properties inside the extracted WAR to point to the NameServer.

The dual‑master setup is now complete (to be continued).

distributed systemsbackend developmentMessage QueuerocketmqInstallationBrokerNameServer
Java Captain
Written by

Java Captain

Focused on Java technologies: SSM, the Spring ecosystem, microservices, MySQL, MyCat, clustering, distributed systems, middleware, Linux, networking, multithreading; occasionally covers DevOps tools like Jenkins, Nexus, Docker, ELK; shares practical tech insights and is dedicated to full‑stack Java development.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.