To ensure interaction reliability in scenarios of network jitter or server abnormalities, Simple Message Queue (SMQ, formerly MNS) clients implement reliability policies that address both the producer and consumer.
Producer: retry mechanism
Types of exceptions and retry trigger
Types of exceptions: Identify and categorize client exceptions (
MNS ClientException, such as network timeouts or rate limiting errors) and server exceptions (ServerException). Differentiate between retryable errors (e.g., error codes 5xx or network jitter) and non-retryable errors (e.g., resource does not existQueueNotExist).Client retries as needed: to resend messages as needed, you can create a retry logic within the business code based on your business requirements.
Backoff policy
We recommend that you implement an exponential backoff policy (e.g., starting at 1 second, capped at 60 seconds) combined with a random jitter policy. In this way, excessive cluster-level retries may be avoided.
Consumer: retry mechanism
Producer: automatic retry
In cases of failed consumption (e.g., messages not explicitly acknowledged or consumption timeouts), SMQ will automatically redeliver messages based on the visibility timeout period of queues when the client pulls new messages.
Consumer: idempotency design
Design business logic to be naturally idempotent (e.g., deduplication through a unique database key) or verify whether the message has been consumed based on the unique message identifier
MessageIdcombined with service status.
Exception handling
Upon encountering exceptions in message consumption logics, do not send an acknowledgment (ACK) message. Instead, allow SMQ to redeliver the message until it is successfully consumed, at which point you can call the
DeleteMessageoperation to delete the message.
References
For sample code in Java, see Use sample code to receive messages.