RocketMQ Consumption Modes: Push vs Pull, Long Polling, O...

TL;DR

Scenario: RocketMQ consumer selection and online consumption backlog, delay, duplicate consumption troubleshooting
Conclusion: RocketMQ “Push” essence is client long polling pull; differences mainly in rhythm control and offset management responsibility
Output: Push/Pull mechanism comparison + cluster workflow + common fault quick reference and fix path

RocketMQ Consumption Modes

RocketMQ provides two message subscription modes, PUSH mode and PULL mode:

1. PUSH Mode (MQPushConsumer)

Surface is Broker actively pushing messages to Consumer
Actual implementation is through long polling mechanism maintained inside Consumer
Typical use scenario: businesses needing real-time message consumption, such as order processing, instant notifications, etc.
Advantage: Developer friendly, automatically handles message pulling and consumption progress management

2. PULL Mode (MQPullConsumer)

Consumer proactively initiates pull requests to Broker
Developer needs to control pull frequency and message processing logic
Typical application scenario: batch processing tasks, scheduled tasks and other non-real-time scenarios
Advantage: Consumption rhythm completely controlled by application

Implementation Mechanism说明

Although the two modes are conceptually different, underlying both based on pull mechanism. PUSH mode is essentially implemented through:

Consumer registers with Broker after startup
Internal thread periodically (default 5 seconds) initiates pull request to Broker
Returns immediately when new messages exist; when no messages, Broker holds request (up to 15 seconds max)
If new message arrives during this period, Broker responds immediately

Technical Details Comparison

Feature	PUSH Mode	PULL Mode
Message Acquisition	Auto polling, default 5 second interval	Must explicitly call pullBlockIfNotFound
Consumption Progress Management	Auto commit offset	Manual offset management
Exception Handling	Built-in retry mechanism	Need to implement retry logic yourself

RocketMQ Cluster Workflow

1. NameServer Startup

NameServer starts and listens on specified port, serving as routing control center waiting for Broker, Producer and Consumer connections.

2. Broker Startup

Broker starts and maintains long connection with all NameServers, periodically sending heartbeat packets containing Broker info and Topic data.

3. Message Production Flow

When producer starts:

Establishes long connection with any NameServer
Gets Broker info for target Topic
Uses round-robin to select queue
Establishes connection with target Broker and sends message

4. Message Consumption Flow

When consumer starts:

Connects to any NameServer
Gets Broker info for subscribed Topic
Directly establishes consumption channel with relevant Broker
Starts consuming messages

Push Mode

Core Characteristics

Push mode is a message push mechanism where server actively pushes messages to consumer in real-time. Typical application scenarios include instant messaging, real-time data monitoring and other fields with high timeliness requirements.

Advantage Analysis

High Real-time: Messages pushed immediately after generation, ensuring lowest latency
Server Initiative: Consumer doesn’t need to poll, reducing invalid requests
Resource Savings: Avoids waste from consumer frequent queries

Potential Issues

Consumer Pressure: When facing burst traffic, server may instantly push large number of messages
Processing Capacity Bottleneck: Consumer processing capacity is usually limited, message backlog may occur
Cascading Failures: Severe cases can cause consumer service crash

Response Strategies

Rate Limiting: Server implements message push rate limiting
Elastic Scaling: Consumer implements auto scaling mechanism
Degradation Plan: Set message importance classification

Pull Mode

Advantages

High Real-time: Consumer can proactively pull messages as needed, reducing message transmission latency
Controllable Consumption: Consumer can decide pull frequency and quantity based on its own processing capacity
High Resource Utilization: Server doesn’t need to maintain state information for each consumer

Disadvantages

Limited Consumer Processing Capacity: When consumer processing capacity is insufficient, message backlog easily occurs
Polling Overhead: Consumer needs to continuously poll to check for new messages, may generate additional network overhead

Optimization Solutions

Dynamically adjust pull frequency: Automatically adjust pull interval based on processing capacity
Batch processing: Appropriately increase number of messages pulled each time
Consumer load balancing: Deploy multiple consumer instances to share processing pressure

Detailed Comparison: Push vs Pull

Push Mode Implementation Principle

consumer.registerMessageListener(new MessageListenerConcurrently() {
    @Override
    public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
        // Business processing logic
        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
    }
});

Pull Mode Implementation Details

Get message queue collection:

Set<MessageQueue> mqs = consumer.fetchSubscribeMessageQueues("TopicTest");

Traverse and process each message queue:

PullResult pullResult = consumer.pull(mq, "*", offset, 32);

Error Quick Reference

Symptom	Root Cause	Fix
Consumption delay suddenly increases, backlog surges	Consumer thread pool/business processing slows	Check Consumer end processing time, concurrency
Same message consumed multiple times	At-least-once semantics, crash before ack	Business idempotency
Consumption offset chaotic, jumping or rollback	Manual offset management logic error	Verify offset storage and write-back frequency
Frequent Rebalance, consumption jitter	Consumer instances frequently go online/offline	Verify heartbeat/timeout configuration
Some queues not consumed for long time	Uneven queue allocation	Compare each MessageQueue’s consumption progress
Pull mode can’t pull messages	Subscription expression/Tag mismatch	Verify subscription expression