Preface
This article records the FAQ during the use of Rocketmq
1. Must the consumer group maintain the same subscription relationship? The
consumer group must ensure that the consumer relationship and logic are completely consistent. When the business service cluster is updated, the subscription relationship may be inconsistent. At this time, only the intersection is reliable consumption, and the difference is unreliable consumption. Assuming that service A has three nodes a1, a2, and a3, and subscribes to topic1, then when A is updating, it adds subscription to topic2. When publishing, it may appear that a1 subscribes to t1t2, and a2a3 still only subscribes to t1. At this time, t1 consumes as usual, and t2 can be consumed from time to time but not consumed, which is unreliable. This inconsistency must be corrected quickly.
2. My consumer group has many nodes, and often cannot consume the
same message. There is one and only one node in the consumer group that will consume it, so if you can't consume it, it may be that another consumer group consumes it. It is worth noting that we must ensure that the consumer group is not mixed in by other applications. This problem is very common. For example, the robot service accidentally joined the cluster consumption as an order service consumer group (maybe it is the first time to go online because of copying someone else's configuration code).
3. Rocketmq has achieved that the same consumer group will only consume once, so do you still need to do business consumption idempotence?
There is a gray server in the production, and the service version is larger than the official server. Because the two can be in different subscription relationships, Cannot be in the same consumer group (each in app_v1, app_v2). Then at this time, the news of their intersection subscriptions will be consumed twice because they are not in the same consumer group.
Therefore, even if the rocket can only consume once with the consumer group, we have to add idempotence to the consumption logic.
4. Will there be a backlog of messages in continuous production when there is no consumer group? How to solve it?
There will be a backlog, and if there has been no consumer group, it will follow a certain strategy, such as clearing it up after 48 hours. However, we still need to be vigilant, if there is a huge backlog within 48 hours, there will still be a risk of hanging.
If the message is important, then you need to increase the nodes of the consumer group to increase the consumption speed.
If the message is not important, you can reset the commitlog offset. The entrance in the open source backend is: topic-reset consumer offset
If the consumer group needs to be delayed (re) online, and the producer's production rate is very high, it is recommended to delete the registered consumer group in the rocketmq background before the consumer group goes online to prevent the backlog.
5. The consumer group is no longer in use
. Do you need to display logout? Yes. After the first consumption of the consumer group is established, he will add a stub to the binding relationship between the topic and the consumer group, and match it with the corresponding commitlog. So when your consumer group is no longer in use, you must explicitly go to the background to clean up, otherwise the backlog of the consumer group's commitlog will always be counted, and this count will affect the message storage cycle.
6. For consumer groups, topics need to be created in rocketm in advance before they can be used.
If you keep this habit, it is excellent, but the first production topic can be created automatically without pre-creating it, of course (it is said) It can also be set to not create silently.
If the consumer group consumes in advance when there is no producer, it will receive a no topic handler warning. This warning can be ignored (provided that it is clear that the producer will be launched later to help you adjust the error).