How to Guarantee Zero Message Loss in RocketMQ – Full‑Lifecycle Best Practices

Interview Focus Points

Systematic Thinking : Can you analyze reliability from the complete lifecycle (production → transmission → storage → consumption) rather than isolated points?

Depth of RocketMQ Architecture Knowledge : Do you truly understand persistence, high‑availability (master‑slave replication), message acknowledgment, and related configuration principles?

Engineering Practice and Trade‑off Ability : Ensuring no message loss often requires sacrificing performance (throughput, latency). Are you familiar with key configuration items and can you make reasonable trade‑offs based on scenarios such as financial transactions versus log collection?

Troubleshooting and Design Ability : When message loss occurs in production, what is your investigation approach? This reflects practical experience and system design skills.

Core Answer

Guaranteeing that RocketMQ messages are not lost requires full‑link protection across three stages: the producer, the broker, and the consumer—none can be omitted.

Production Stage : Ensure messages are successfully sent and stored in the broker.

Use Synchronous Send and check the SendResult .

Configure retry mechanism via retryTimesWhenSendFailed .

Handle send exceptions properly (e.g., log, persist to DB, trigger alerts).

Broker Storage Stage : Ensure messages are reliably persisted and replicated.

Master‑Slave Architecture : Set brokerRole to SYNC_MASTER or ASYNC_MASTER and add slave nodes ( SLAVE ).

Flush Strategy : For high reliability, set flushDiskType to SYNC_FLUSH (synchronous flush).

Replication Strategy : In critical scenarios, configure brokerRole as SYNC_MASTER and enable synchronous double‑write so the master returns ACK only after both master and slave have written successfully.

Consumer Stage : Ensure messages are successfully processed by business logic before acknowledging.

After successful business execution, return ConsumeConcurrentlyStatus.CONSUME_SUCCESS .

Avoid using asynchronous consumption or manual offset management that may acknowledge before processing.

Leverage the consumption retry mechanism: for failures (return RECONSUME_LATER or throw an exception), RocketMQ will place the message into a retry queue for delayed re‑consumption.

Deep Analysis

Principles and Mechanisms

Synchronous Flush vs Asynchronous Flush :

SYNC_FLUSH : After the producer writes to the CommitLog , the broker waits for the data to be flushed to disk before responding. This is the most reliable mode.

ASYNC_FLUSH : After the producer writes to the PageCache , the broker returns success immediately; a background thread flushes to disk later. Higher performance but data in the page cache can be lost if the broker crashes before flushing.

Synchronous Replication vs Asynchronous Replication :

SYNC_MASTER : The master waits for the slave ( SLAVE ) to write successfully before acknowledging the producer, ensuring strong consistency.

ASYNC_MASTER : The master acknowledges immediately after its own write; replication to the slave occurs asynchronously. If the master crashes before the slave syncs, messages may be lost.

Consumption Acknowledgment (ACK) : RocketMQ uses an offset mechanism. After a consumer successfully processes a batch, it commits the offset to the broker. The broker then delivers subsequent messages from the next offset. If consumption fails or the offset is not committed, the next poll starts from the last committed offset.

Code Example and Best Practices

DefaultMQProducer producer = new DefaultMQProducer("ProducerGroupName");
producer.setNamesrvAddr("name-server-ip:9876");
producer.setRetryTimesWhenSendFailed(3);
producer.start();

Message msg = new Message("TopicTest", "TagA", "OrderId001", "Hello, RocketMQ".getBytes());
SendResult sendResult = producer.send(msg);
System.out.printf("Message sent: MsgId=%s, Queue=%s%n", sendResult.getMsgId(), sendResult.getMessageQueue());

DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("ConsumerGroupName");
consumer.setNamesrvAddr("name-server-ip:9876");
consumer.subscribe("TopicTest", "*");
consumer.registerMessageListener((MessageListenerConcurrently) (msgs, context) -> {
    for (MessageExt msg : msgs) {
        try {
            String orderId = new String(msg.getBody());
            boolean success = processOrder(orderId);
            if (success) {
                return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
            } else {
                return ConsumeConcurrentlyStatus.RECONSUME_LATER;
            }
        } catch (Exception e) {
            log.error("Exception during consumption, will retry", e, msg);
            return ConsumeConcurrentlyStatus.RECONSUME_LATER;
        }
    }
    return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
});
consumer.start();

Comparison and Common Pitfalls

Performance vs Reliability Trade‑off : SYNC_FLUSH + SYNC_MASTER offers the highest safety but lowest throughput (often only a tenth of async mode). The recommended balance is ASYNC_FLUSH + SYNC_MASTER , which keeps master‑slave consistency while improving write performance.

Assuming Asynchronous Send Guarantees No Loss ( sendOneWay or async callbacks): Asynchronous send does not wait for a response, so network glitches or broker failures can cause silent loss.

Returning CONSUME_SUCCESS Prematurely : This is the most common cause of consumer‑side message loss. Ensure business logic succeeds before acknowledging.

Ignoring Retry and Dead‑Letter Queues : Monitor dead‑letter queues and handle repeatedly failing messages, which usually indicate serious business logic issues.

Deploying a Single‑Node Broker : Without master‑slave replication, a disk failure or host crash will cause all unconsumed messages to be lost.

Summary

Ensuring RocketMQ messages are never lost is a "three‑party collaboration" effort: the producer must send synchronously and handle exceptions, the broker must be configured with appropriate flush and replication strategies, and the consumer must acknowledge only after successful business processing. Negligence in any link breaks the chain and leads to message loss.