Understanding RocketMQ: Basic Concepts, Ordered Messages, and Transactional Messages

Recently our team gathered practical insights from using RocketMQ and our internally developed ZZMQ, and this article shares those experiences. It starts with a basic introduction to RocketMQ's domain model, covering producers, topics, queues, messages, consumer groups, consumers, and subscription relationships.

The message transmission model is compared between point‑to‑point (queue) and publish‑subscribe, highlighting that RocketMQ adopts the publish‑subscribe model, which offers higher scalability.

Reliability of ordinary messages is discussed, describing ACK mechanisms, storage reliability challenges (broker shutdown, crashes, OS failures, power loss, hardware failures, disk failures), and the trade‑off between synchronous and asynchronous flushing, as well as master‑slave synchronization.

Ordered messages are examined through a fictional scenario where out‑of‑order processing caused a payment failure. The article outlines why RocketMQ can produce ordering issues due to multiple queues per topic, presents typical use cases (financial transactions, order processing, real‑time data sync), and provides guidelines for ensuring order at the production and consumption sides, including single‑producer single‑thread, single‑producer multi‑thread, and consumer processing strategies.

Key considerations for ordered messages include handling consumer exceptions with limited retries, avoiding message hot‑spots by dispersing message groups, and designing appropriate message keys.

客服同学: @XXX 我们判责了，为啥客户还收不到退款? 售后单号xxxxxx。

研发同学: 让我看看。

Transactional messages are introduced to address consistency problems when a message is sent but the related database operation fails. The article explains the need for distributed transactional messages, their role in ensuring atomicity between local transactions and message delivery, and typical scenarios such as payment processing.

Implementation details of the open‑source RocketMQ transactional message are described, including the half‑message mechanism, the two‑phase commit process, broker‑initiated status checks, and the three possible states (Commit, Rollback, Unknown). Sample code snippets illustrate the TransactionListener interface methods.

executeLocalTransaction方法：用来执行本地事务，返回本地事务给到broker，同时，将事务状态进行记录：

The proprietary ZZMQ version adapts the concept by leveraging local database transactions and retry mechanisms, storing transactional information in a database and using a time‑wheel queue for failed messages. Differences between the open‑source and ZZMQ implementations are highlighted, such as design orientation (vertical vs. horizontal) and reliance on internal queues versus database‑driven guarantees.

Both versions ultimately aim to provide reliable, ordered, and consistent message processing in distributed microservice architectures.