Shulou(Shulou.com)05/31 Report--

This article mainly introduces the sample analysis of sequential messages, repeated messages, transaction messages and message storage in RocketMQ. It is very detailed and has a certain reference value. Interested friends must read it!

Sequential message

As the name implies, it is necessary to ensure that the message set that needs to be consumed sequentially is sent to the same message queue, and a receipt is given after the successful consumption of the message.

The message producer implements the specified message queue method when sending the message. [take the order number and do a modular operation and throw it into the selector. Selector ensures that all users with the same module will be delivered to the same queue.

That is, the same order number-- > has the same module-- > has the same queue.

Repeat message

Repetitive messages are mainly implemented on the business side. The business logic of the consumer side to process the message is idempotent, ensuring that each message has a unique number and that the successful message processing occurs at the same time as the log of the de-duplicated table.

Transaction message

Transaction messages should be processed in cooperation with the sender and subscriber respectively. Sender:

When you send a Prepared message in the first stage, you will get the address of the message.

The second phase is the implementation of local affairs.

The third stage accesses the message through the address obtained in the first stage and modifies the status of the message. Periodically scan the transaction messages in the message cluster, process Prepared messages to confirm to the sender and process the messages according to the sender policy

Subscriber side: the business implements message processing in the transaction, and solves the problem of failed message processing by retry, which is always solved manually.

Message storage

The message storage of RocketMQ is done by consume queue and commit log together.

Consume queue is the logical queue of messages, which is equivalent to the directory of dictionaries, and is used to specify the location of messages on the physical file commit log.

The files are organized according to topic and queueId. In the figure, TopicA has two queues 0Power1, so TopicA and QueueId=0 form a ConsumeQueue,TopicA and a QueueId=1 to form another ConsumeQueue.

ConsumeQueue storage: CommitLog Offset refers to the actual offset of the message in the CommitLog file and the size of the message in the Size storage.

Message Tag HashCode stores the hash value of the Tag of the message: it is mainly used for message filtering at subscription time (if Tag is specified at subscription time, the subscribed message will be found quickly according to HashCode).

The retry queue is grouped according to the GroupName of the consumer side. If the consumer side consumption fails, the message will be sent to the retry queue.

The dead letter queue is grouped according to the GroupName of the consumer end. If the consumer end consumption fails and still fails after a specified number of retries, it will be sent to the dead letter queue.

Commit Log: the physical file in which messages are stored. The commit log on each broker is shared by all queue on the machine, without any distinction.

These are all the contents of the article "sample Analysis of Sequential messages, repeated messages, transaction messages and message Storage in RocketMQ". Thank you for reading! Hope to share the content to help you, more related knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.