Message Types

URocketMQ supports a variety of message types including general, partition order, global order, transaction, timed, etc. The code for producing/consuming each type of message may differ, so it’s suggested not to mix them up.

General Messages

Common messages with no special settings, have the best performance.

Partition Order Messages

Partition based on the Sharding Key provided by the user, the messages within the same partition will be published and consumed strictly according to the FIFO order.

Global Order Messages

All messages are guaranteed to be produced and consumed in FIFO order, which is essentially a queue, but with the lowest performance.

Transaction Messages

Transaction messages provide a distributed transaction function similar to X/Open XA, which can either succeed or fail at the same time. Through transaction messages, the eventual consistency of distributed transactions can be achieved.

Timed/Deferred Messages

In addition to supporting fixed gradient delay messages like open-source RocketMQ, URocketMQ independently developed support for any second-level timed/deferred messages.

Fixed Gradient Delay Messages

Open source RocketMQ supports fixed gradient delay messages. After the message is sent, it won’t be consumed immediately, but will be delivered to the actual topic after a specific time. The default configuration provides 18 levels of “1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”, each level corresponds to a different delay time. For example, 1 corresponds to 1s, 5 corresponds to 1m, the specifics are as follows:

Any Second-Level Delay Messages

URocketMQ independently supports any second-level delay messages, and users can customize the timing or delay to send messages at any second in the future.

Notes:

1. The precision of timed messages may have a delay error of 1s~2s.
2. Customized second-level delay messages are supported within 2 days by default.
3. If both fixed gradient delay and custom delay properties are set at the same time, only the fixed gradient delay will take effect.
4. If the delay time exceeds the supported range (like the default 2 days), it will be adjusted to the maximum supported time.
5. The actual timestamp is based on the server time. If the scheduled timestamp is less than the current server timestamp, the message will be sent immediately.
6. Instances created before November 15, 2021, will be upgraded in batches to support this feature. If the instance doesn’t support it, please contact the account manager for an instance upgrade.