Can ApsaraMQ for RocketMQ guarantee no duplicate messages? - ApsaraMQ for RocketMQ

No. ApsaraMQ for RocketMQ provides at-least-once delivery semantics -- messages are never lost, but may occasionally be delivered more than once.

In distributed messaging systems, three delivery semantics exist:

Delivery semantic	Behavior
At-most-once	Messages are delivered once. If a failure occurs, a message may be lost and is not redelivered.
At-least-once	Messages are delivered one or more times. Messages are never lost, but duplicates are possible.
Exactly-once	Messages are delivered once and only once. No message loss and no duplicates, even during failures.

ApsaraMQ for RocketMQ uses at-least-once delivery. In most cases, each message reaches consumers exactly once. However, certain failure conditions cause the broker to redeliver a message:

Network jitter -- The broker sends a message and the consumer processes it successfully, but the acknowledgment (ACK) is lost in transit. Because the broker never receives the ACK, it assumes the message was not consumed and redelivers it.
Processing timeout -- The consumer takes too long to process a message. The broker times out waiting for an ACK and redelivers the message to the same or a different consumer.

In both cases, the consumer has already processed the message once. The redelivery results in duplicate processing unless the consumer is designed to handle it.

Design consumers to be idempotent

No distributed messaging system can fully guarantee exactly-once delivery across all failure modes. Design your consumers to handle the same message more than once without unintended side effects.

Common approaches

Deduplication by message key -- Store processed message IDs in a database or cache (such as Redis). Before processing a message, check whether its ID already exists. Skip the message if it does.
Idempotent operations -- Design your business logic so that applying the same operation twice produces the same result. For example, use INSERT ... ON DUPLICATE KEY UPDATE or upsert patterns instead of blind inserts.
Business-level deduplication keys -- Assign each message a unique business-level key (such as an order ID combined with an action type). Anchor the key to your business process rather than to infrastructure-level message IDs. This way, the key can be reliably reconstructed after a failure. For example, a payment message for order 12345 could use the key 12345/payment. If the message is delivered twice, the consumer identifies the duplicate by business key alone.