RocketMQ -- consumer startup process

When consumers send messages, they have a concept of grouping. That is to say, there are one or more consumers with the same name, and these consumers with the same name form a consumer group.

For example, in the figure below, two group_a are a consumer group, and two group_b are a consumer group.

When a message a comes in from the broker, the message will be consumed by the two consumer groups at the same time.

We also saw that each consumer group has multiple consumers. If the message is consumed by group_a, how do the two consumers consume it?

This involves two consumption modes: cluster mode and broadcast mode.

In cluster mode, this message can only be consumed by one consumer in the consumer group. For example, group_a is a cluster mode, then only one consumer can consume at this time.

In broadcast mode, the message will be consumed by each consumer in the consumer group. For example, group_b is in broadcast mode, then both consumers will consume it.

The consumption group and consumption mode are so important, so when consumers start, they need to verify the consumption group and consumption mode.

Constructing Topic subscription information, such as the message that the consumer needs to subscribe to TopicTest, is constructed here. In this step, Topic subscription information is a map, so there will be multiple.

When the basic information is ready, start to initialize MQClientInstance and RebalanceImple (message reload implementation class).

Initialize the message progress. There are two situations according to the consumption mode:

One is the cluster mode. Since several consumers in the consumption group can only consume one, if the consumer hangs up, the other consumer needs to start consumption from the previous position, so the progress cannot be saved locally, and needs to be saved in the In the broker, the consumption progress is finally pulled from the broker.

The other is the cluster mode. The consumer's message maintains its own progress, so the progress is saved locally, and the consumption progress is eventually pulled from the local.

If the messages are consumed sequentially, create a sequential message consumption service, if not, create a concurrent message consumption service, which will be discussed in detail later.

After creation, start the corresponding message consumption service.

Register the consumer, and then start the consumer client. The startup here is the same as that of the producer, including the startup of message reloading, etc.