Ensuring Message Reliability in RocketMQ: Producer, Broker, and Consumer Strategies

1. Overall Message Processing Flow

The message lifecycle is divided into three stages: Producer sending, Broker processing, and Consumer consumption.

Producer Sending Stage

During this stage, messages travel from the producer to the broker over the network, so loss is possible. RocketMQ mitigates this risk with several measures.

Measure 1: Synchronous Send

RocketMQ offers three send modes:

Synchronous send: The producer blocks until the broker acknowledges the send result.

Asynchronous send: The producer submits a send task to a thread pool and receives the result via a callback.

Oneway send: The producer sends the request without waiting for a response.

When producer.send is called without a callback, the default is synchronous send, which has the lowest loss probability.

Measure 2: Retry on Failure or Timeout

If sending fails or times out, RocketMQ automatically retries (default three times, configurable per producer).

Measure 3: Multi‑Master Broker Mode

With multiple broker masters, if one broker crashes, the producer can resend to another healthy broker, preventing loss.

Summary

Prefer synchronous sending combined with retries and multi‑master brokers to minimize message loss.

Broker Processing Stage

Measure 4: Synchronous Disk Flush Strategy

public enum FlushDiskType {
    SYNC_FLUSH, // synchronous flush
    ASYNC_FLUSH // asynchronous flush (default)
}

Messages are first written to the page cache; if the flush strategy is asynchronous, the broker may acknowledge success before persisting to disk, risking loss if the broker crashes.

Measure 5: Master‑Slave Replication with Synchronous Dual‑Write

Even with synchronous flush, a disk failure on the master can cause loss. By configuring a slave broker as a SYNC_MASTER with synchronous flush, the broker only acknowledges success after both master and slave have persisted the message.

Summary

Message loss on the broker side mainly stems from the flush policy and replication mode. Using synchronous flush together with synchronous slave replication mitigates this risk.

Consumer Consumption Stage

Measure 6: At‑Least‑Once Delivery

RocketMQ guarantees at‑least‑once delivery, meaning the consumer pulls messages, processes them, and then acknowledges back to the server.

What is At‑Least‑Once?

The consumer acknowledges only after successful processing, ensuring no message is lost, though duplicates may occur.

Two acknowledgment strategies exist:

Commit before processing (prevents duplicates but may lose messages).

Process first, then commit (default in RocketMQ; consumers must ensure idempotency).

Measure 7: Consumer Retry Mechanism

If processing fails, RocketMQ can redeliver the message, providing reliability.

Summary

Consumer reliability relies on at‑least‑once delivery combined with retry mechanisms.

2. Preventing Duplicate Consumption

Duplicate consumption can happen in systems like RabbitMQ, RocketMQ, and Kafka when offsets are not committed before a crash, causing the same messages to be delivered again.

To achieve idempotency, consider the following approaches:

Check primary keys before inserting into a database; update instead of inserting duplicate rows.

Use Redis SET operations, which are naturally idempotent.

Attach a globally unique identifier to each message (e.g., order ID) and record it in Redis; skip processing if the ID already exists.

Leverage database unique constraints to prevent duplicate rows.

These strategies ensure that even if a message is delivered multiple times, the system state remains consistent.