RocketMQ provides two common consumption modes, Pull and Push. The implementation of the Push mode is based on the Pull mode, only that it is a packaging of the Pull mode. Therefore, the RocketMQ Push mode is not a true Push mode, but still a Pull mode.
It can be assumed that RocketMQ SDK will continuously perform message pulling tasks. For each pull:
After a message is pulled from the broker, if it is filtered out (for example, due to tag-based filtering), the pull request is re-queued into a blocking queue, and the message pull cycle continues. If the message is not filtered, it is passed to the consumer thread for processing, while the pull request is still re-queued into the blocking queue.
If no new messages are available from the broker or no messages are matched, the pull request is re-queued into the blocking queue, and the message pull cycle continues.
From here, we can see that if the user does not produce any message, as long as there is a consumer online, it will periodically request the server, which can also ensure the timeliness of message consumption. If the user wants to reduce the number of pulls,
Solutions
For consumers using the pull mode, since users have full control over the pull frequency, they should implement appropriate waiting mechanisms after each pull or use rate-limiting components to regulate the pull rate effectively.
For consumers in push mode, the PullInterval parameter can be adjusted to increase the interval between pull operations.
// Set pull interval to 60 seconds.
pushConsumer.setPullInterval(60 * 1000);
Note:
It is important to note that increasing the pull interval may lead to higher message consumption latency. Any modifications should be made with caution.
If the message production rate is low, message pulls will typically align with the long polling timeout. Currently, the SDK enforces a fixed long polling interval of 15 seconds. This means that for a single queue on a single broker, there will be at least 4 pull requests per minute. For example, with 10 Topics, each having 3 queues, and 2 brokers, the total number of pull requests would be 10*3*2*4=240, meaning 4 pull requests per second.
During operation, as messages are produced and consumed, retry topics may be generated. This requires additional pull requests for the retry queues, further increasing the overall pull frequency.