This project aims to build lightweight, cloud-native clients, and establish the unified messaging model/APIs design acorss languages.
We assume that you are familiar with the basic concepts and terminologies about Apache RocketMQ. Therefore, we will not go into details about that.
In order to adapt different scenarios, we defined different types for messages to publish.
message group
. This type of message need to be used with FIFO consumer group, which guarantees that the message must be received first if the it is published first with the same message group.delivery timestamp
, which decides the visible time to consumers;The different types are mutually exclusive, when means that the message to publish could not be both FIFO type and DELAY type at the same time. Actually the type of the topic determines the type of the message. For example, FIFO topic do not allow the publishing of other types of messages.
As we all know, consumer group is the basic unit of load balancing for consumers. Messages are evenly distributed to all consumers in the same consumer group. Now, we assigned more attributes to consumer group rather than the consumer itself.
Especially, this table shows the sequence of message receiption with the combination of FIFO/non-FIFO topics and FIFO/non-FIFO consumer groups.
FIFO Consumer Group | non-FIFO Consumer Group | |
---|---|---|
FIFO Topic | FIFO | non-FIFO |
non-FIFO Topic | non-FIFO | non-FIFO |
There are four types of client.
Client identifier provides indentity information for each client event within the same process. A typical client identifier: macbook-pro@90009@0@2dyeb8lep
, which could be divided into 4 parts by the separator @
.
macbook-pro
: hostname of device;90009
: process identifier;2
: client index within current process;2dyeb8lep
: the unique string within process.Note: Implementations of client identifier by different languages may vary slightly, but the uniqueness is the first principle that must be followed.
Message identifer provides identity information for each message stored in broker, which means producer can not get the message identifier until it is sent out successfully.
Note: Internal retries during message publishing may cause message duplication, the duplicate messages here have the same message indentifier.
The message identifer layout is redesigned, see more details here.
RIP-37: New and Unified APIs: RocketMQ proposal of new and unified APIs across different languages.
In fact, current rocketmq APIs exist some problems: