How to Ensure Zero Message Loss in RocketMQ: Scenarios and Solutions

When a project uses a message queue (MQ), the risk of message loss becomes critical, especially in financial transaction scenarios. This article outlines the main loss scenarios in RocketMQ and how to prevent them.

Typical Message‑Loss Scenarios

Producer sends a message to RocketMQ, but network jitter or communication errors cause the message to be lost.

After RocketMQ receives a message, it may store it only in the OS cache before flushing to disk; if the broker crashes before the asynchronous flush completes, the message is lost.

The message is persisted to disk but no backup exists; a disk failure leads to loss.

The consumer acknowledges consumption before fully processing the message; if the consumer crashes afterward, RocketMQ assumes the message is consumed and the data is lost.

Ensuring Zero Message Loss

Scenario 1 – Producer side : Use RocketMQ’s built‑in transaction mechanism.

Producer sends a half‑message; consumers cannot consume it. If sending fails, rollback logic is executed.

If the half‑message is accepted, the producer proceeds with its core business logic.

If the core logic fails, the transaction is rolled back and the half‑message is deleted.

If the core logic succeeds, the producer commits the half‑message, making it consumable.

Scenario 2 – Broker side : Switch the flush policy from ASYNC_FLUSH to SYNC_FLUSH by setting flushDiskType=SYN​C_FLUSH in the broker configuration, ensuring the message is truly persisted to disk. Additionally, deploy RocketMQ in a master‑slave cluster so that each leader’s data is replicated to multiple followers, protecting against disk failure.

Scenario 3 – Consumer side : Register a message listener that processes the message and returns ConsumeConcurrentlyStatus.CONSUME_SUCCESS only after the business logic completes. If the consumer crashes before returning success, RocketMQ will re‑assign the message to another consumer, preventing loss. Avoid spawning asynchronous threads inside the listener that might acknowledge before processing finishes.

Trade‑offs

Transactional messaging adds extra steps and reduces throughput.

Synchronous flushing is slower than asynchronous flushing because it writes directly to disk.

Master‑slave replication requires data synchronization between leader and followers.

Consumers must process messages synchronously and cannot acknowledge before completion.

Message zero‑loss is a double‑edged sword; the appropriate solution should be chosen based on specific business requirements.