How to Achieve Near‑Zero Message Loss with RocketMQ and RabbitMQ

How to Ensure RocketMQ Message Reliability?

In distributed systems, guaranteeing that messages are not lost is critical. Alibaba’s technical article describes how RocketMQ maximizes reliability by controlling the message lifecycle across three key stages.

Production stage: the producer creates the message and sends it over the network to the broker for storage.

Storage stage: the broker stores the message; if replication is enabled, the message is copied to other nodes.

Consumption stage: the consumer pulls the message from the broker, and retries are used to maximize consumption success.

Below we share how RabbitMQ ensures message reliability for comparison.

How to Ensure RabbitMQ Full‑Chain Data 100% No Loss

We skip basic RabbitMQ concepts and focus on the three steps a message goes through: producer → RabbitMQ → consumer.

Producer sends the message to RabbitMQ.

RabbitMQ forwards the message to the consumer.

Consumer processes the message.

Each step can cause loss; the goal is to achieve 99.999999% reliability, which is practically sufficient.

Producer Reliability Delivery

The producer must ensure that messages are correctly delivered to RabbitMQ. Network failures or broker crashes can cause loss, but RabbitMQ provides mechanisms to mitigate these issues.

Transactional Message Mechanism

Transactional messages severely impact performance and are rarely used; instead, the lightweight confirm mechanism is preferred.

Confirm Message Mechanism

The confirm mechanism works by having the broker send an acknowledgment back to the producer once the message is safely stored.

channel.confirmSelect(); // enable publisher confirm mode

The producer then registers an asynchronous listener for acknowledgments and negative acknowledgments.

channel.addConfirmListener(new ConfirmListener() {
    // Message successfully reached broker
    @Override
    public void handleAck(long deliveryTag, boolean multiple) throws IOException {
        System.out.println("已收到消息");
        // additional processing
    }

    // Broker reports a failure, message lost
    @Override
    public void handleNack(long deliveryTag, boolean multiple) throws IOException {
        System.out.println("未确认消息，标识：" + deliveryTag);
        // retry or other handling
    }
});

Message Persistence

After a message reaches RabbitMQ, it resides in memory; if the broker crashes, the message would be lost unless persisted to disk.

Message flow: exchange → queue → consumer.

All three components must be declared as durable.

Exchange persistence:

// third parameter true makes the exchange durable
channel.exchangeDeclare(EXCHANGE_NAME, "direct", true);

Queue persistence:

// second parameter true makes the queue durable
channel.queueDeclare(QUEUE_NAME, true, false, false, null);

Message persistence:

// MessageProperties.PERSISTENT_TEXT_PLAIN marks the message as persistent
channel.basicPublish(EXCHANGE_NAME, ROUTING_KEY, MessageProperties.PERSISTENT_TEXT_PLAIN, message.getBytes(StandardCharsets.UTF_8));

If RabbitMQ crashes after receiving a message but before persisting it, the message can still be lost; likewise, network failures may prevent the producer from receiving the broker’s confirmation.

Therefore, an additional compensation strategy—storing messages in a database—is recommended.

Message Storage in Database

Before sending, the producer saves the message with a status flag (e.g., status=0). After receiving the broker’s acknowledgment, the status is updated to 1. A scheduled task scans for messages with status=0 that have timed out and retries them, handling possible duplicates with idempotent consumer logic.

With this approach, the producer can reliably deliver messages and be aware of their status.

Consumer Side Message No Loss

Three typical scenarios cause consumer‑side loss:

Network failure before the consumer receives the message.

The consumer crashes before receiving the message.

The consumer processes the message but crashes during handling.

These losses stem from RabbitMQ’s default automatic‑acknowledge mode, which removes the message from the queue as soon as it is delivered, regardless of consumer success.

Switching to manual acknowledgment resolves this issue.

Consumer manual‑ack code:

DeliverCallback deliverCallback = (consumerTag, delivery) -> {
    try {
        // process message
        channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
    } catch (Exception e) {
        // error handling, possibly requeue or discard
    }
};
// autoAck set to false disables automatic acknowledgment
channel.basicConsume(QUEUE_NAME, false, deliverCallback, consumerTag -> {});

With manual ack, unacknowledged messages are re‑queued if the consumer disconnects or crashes, allowing another consumer to retry while requiring idempotent processing.

Thus, from producer through RabbitMQ to consumer, the full message chain can achieve near‑zero loss.

Message Middleware Mind Map

Finally, a mind map summarizing middleware concepts and interview questions is provided.