消息队列系列（三）关于消息的pull和push模式

1813次阅读  |  发布于2年以前

在使用RocketMQ的时候，我们常用的消费模式有两种类型，今天我们来深入了解下这两种消费模型：推模式，拉模式。

首先我们从代码使用角度来直观感受下这两种模式有什么区别，下边是两份简单的demo程序：

推模式

推模式的代码构建案例如下：

public class MqConsumerPushApplication {
    public static final String NAME_SERVER = "localhost:9876";
    public static MqMsgSerializer mqMsgSerializer = new FastJsonSerializer();
    public static void main(String[] args) throws MQClientException {
        DefaultMQPushConsumer defaultMQPushConsumer = new DefaultMQPushConsumer("push-consumer-application");
        defaultMQPushConsumer.setNamesrvAddr(NAME_SERVER);
        defaultMQPushConsumer.subscribe("push-topic", "*");
        defaultMQPushConsumer.registerMessageListener(new MessageListenerConcurrently() {
            @Override
            public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
                for (MessageExt msg : msgs) {
                    long timeStamp = msg.getStoreTimestamp();
                    LocalDateTime localDateTime = new Date(timeStamp).toInstant().atOffset(ZoneOffset.of("+8")).toLocalDateTime();
                    System.out.println("broker存储时间:" + localDateTime + " " + new String(msg.getBody()));
                }
                return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
            }
        });
        defaultMQPushConsumer.start();
    }
}

消费者在启动之前需要通过一个注册机制，去设置当消息发生变化时候会通知到这个消费者端。

目前支持两种api声明方式，一种是并发消息，一种是顺序消息

void registerMessageListener(final MessageListenerConcurrently messageListener);

void registerMessageListener(final MessageListenerOrderly messageListener);

如果希望消费端在启动之后动态调整注册的topic信息，可以通过调用subscribe和unsubscribe两个接口来实现。


void subscribe(final String topic, final String subExpression) throws MQClientException;

void unsubscribe(final String topic);

ps: 关于动态修改rocketmq的topic的一些思考，我自己在本地通过编写了下边这个小demo来验证了确实可以通过这种方式动态修改rocketmq的topic信息，这种方式其实还是挺方便的，尤其是在遇到一些消息堆积的情况下，老的topic会被修改为新的topic，然后生产者将消息发送到新的新的队列中，接下来消费者可以通过调用subscribe去订阅新的topic，从而实现平滑解决消息堆积的问题。

在推模式场景中，构建RocketMQ的几个核心参数分别是：

这个不必多说，就是定义需要连接访问的nameserver地址。

在集群模式下同一个消费组内部的各个消费者分别管理不同的队列，同一条消息只能被同一个消费组内部的单个消费者所消费。

这个是消费模式，目前RocketMQ支持集群模式和广播模式两大类。

CONSUME_FROM_LAST_OFFSET：从最新的消息开始消费。

CONSUME_FROM_FIRST_OFFSET：从最新的位点开始消费。

CONSUME_FROM_TIMESTAMP：从指定的时间戳开始消费，这里的实现思路是从 Broker 服务器寻找消息的存储时间小于或等于指定时间戳中最大的消息偏移量的消息，从这条消息开始消费。

这个参数对应的是消费时间戳，用于指定特定时间进行消费，格式“ yyyyMMddHHmmss”，该参数只适合用于当ConsumeFromWhere类型为CONSUME_FROM_TIMESTAMP的时候使用。

集群模式下的消费位点的详细信息会被记录到

${user.home}/store/config/consumerOffset.json文件中

广播模式下消费位点会被记录在${user.home}/.rocketmq_offsets配置文件中。

位点记录的截图如下：

这两个参数用于调整消费端线程池的大小，合理调控可以提升消费者的消费能力。这两个值通常设置成一致的数值，因为在消费端的底层使用的是无界队列 。这个参数比较适合用于一些数据库的批量写入逻辑中进行处理。

这个参数是指当采用了并发消费之后，如果broker节点上的最大消费位点与最小消费位点之差大于该值，则consumer不再向Broker拉取消息。

消费端每次拉取消息的间隔时间长度，在push模式下这个参数默认为0。通过这个参数可以更加确定了所谓的推模式其实是一种伪推，本质还是客户端不断地去拉取。

还有很多其他的相关参数，这部分的细节我就不在文中一一列举了，大家可以进入RocketMQ的源代码中进行阅读：

类名称

org.apache.rocketmq.client.consumer.DefaultMQPushConsumer

push模式其实本质就是rocketmq在客户端按照消费组开辟了不同的线程池，然后这些线程池从broker上拉取对应的消息到本地进行消费。如果希望提升消费能力可以通过调整consumeThreadMin和consumeThreadMax两个参数来提升拉取的效率，如果提升了线程核心数值之后还是没有什么太大变化的话，这个时候可以尝试通过调整以下两个参数：

拉模式

其实RocketMQ的客户端默认都是使用的pull模式，所谓的push模式也只不过是伪pull模式。

在RocketMQ 4.6.0 版本之前，拉模式提供的Api是org.apache.rocketmq.client.consumer.DefaultMQPullConsumer 对象，而随着版本的更新，后期RocketMQ提供了新的API接口：

org.apache.rocketmq.client.consumer.DefaultLitePullConsumer。

两种不同版本api的拉模式的案例代码如下所示：

package org.idea.mq.framework.rocketmq.consumer;
import org.apache.rocketmq.client.consumer.DefaultLitePullConsumer;
import org.apache.rocketmq.client.consumer.DefaultMQPullConsumer;
import org.apache.rocketmq.client.consumer.PullResult;
import org.apache.rocketmq.client.exception.MQBrokerException;
import org.apache.rocketmq.client.exception.MQClientException;
import org.apache.rocketmq.common.consumer.ConsumeFromWhere;
import org.apache.rocketmq.common.message.MessageExt;
import org.apache.rocketmq.common.message.MessageQueue;
import org.apache.rocketmq.remoting.exception.RemotingException;

import java.time.LocalDateTime;
import java.time.ZoneOffset;
import java.util.*;
/**
 * @Author linhao
 * @Date created in 5:30 下午 2022/4/20
 */
public class MqConsumerPullApplication {
    public static final String NAME_SERVER = "localhost:9876";
    public static final String TOPIC = "A-msg-topic";
    private static final Map<Integer, Long> OFFSET_TABLE = new HashMap<Integer, Long>();
    /**
     * 新版本的消费模式
     *
     * @throws MQClientException
     */
    public static void newPullConsumerDemo() throws MQClientException {
        DefaultLitePullConsumer pullConsumer = new DefaultLitePullConsumer("pulConsumerGroup");
        pullConsumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);
        pullConsumer.subscribe("pull-topic", "*");
        pullConsumer.setAutoCommit(true);
        pullConsumer.setNamesrvAddr(NAME_SERVER);
        pullConsumer.start();
        while (true) {
            List<MessageExt> messageExtList = pullConsumer.poll();
            for (MessageExt msg : messageExtList) {
                long timeStamp = msg.getStoreTimestamp();
                LocalDateTime localDateTime = new Date(timeStamp).toInstant().atOffset(ZoneOffset.of("+8")).toLocalDateTime();
                System.out.println("broker存储时间:" + localDateTime + " " + new String(msg.getBody()));
            }
        }
    }
    /**
     * 老版本的消费模式
     */
    public static void oldPullConsumerDemo() throws MQClientException, RemotingException, InterruptedException, MQBrokerException {
        DefaultMQPullConsumer pullConsumer = new DefaultMQPullConsumer("pullConsumerGroup");
        pullConsumer.setNamesrvAddr(NAME_SERVER);
        pullConsumer.start();
        while (true) {
            Set<MessageQueue> messageQueues = pullConsumer.fetchSubscribeMessageQueues(TOPIC);
            for (MessageQueue messageQueue : messageQueues) {
                PullResult pullResult = pullConsumer.pullBlockIfNotFound(messageQueue, null, getMessageQueueOffset(messageQueue), 32);
                putMessageQueueOffset(messageQueue, pullResult.getNextBeginOffset());
                switch (pullResult.getPullStatus()) {
                    case FOUND:
                        List<MessageExt> messageExtList = pullResult.getMsgFoundList();
                        for (MessageExt m : messageExtList) {
                            System.out.println(new String(m.getBody()));
                        }
                        break;
                    case NO_MATCHED_MSG:
                        break;
                    case NO_NEW_MSG:
                        break;
                    case OFFSET_ILLEGAL:
                        break;
                }
            }
        }
    }
    // 保存上次消费的消息下标
    private static void putMessageQueueOffset(MessageQueue mq, long nextBeginOffset) {
        OFFSET_TABLE.put(mq.getQueueId(), nextBeginOffset);
    }
    private static Long getMessageQueueOffset(MessageQueue messageQueue) {
        Long offset = OFFSET_TABLE.get(messageQueue.getQueueId());
        if (offset == null) {
            return 0L;
        }
        return offset;
    }
    public static void main(String[] args) throws MQClientException, RemotingException, InterruptedException, MQBrokerException {
        oldPullConsumerDemo();
    }
}

对比新老API我们可以看出，新的Api内部对于拉取消息做了更加友好的封装，当拉取消息的时候可以直接使用pullConsumer.poll()函数趣获取，不需要像使用pullConsumer.fetchSubscribeMessageQueues(TOPIC)的方式指定对应的topic后再去拉取消息，使用起来更加方便。

和push模式相似，采用pull模式去消费消息的时候，内部也有很多相似的配置，这块的配置属性看名字就很好理解了，重复的内容我就不打算再在文章中进行详细介绍了。

pull模式和push模式的对比

pull模式在消费完消息之后不需要手动返回ack确认信号，它会在底层默认返回ACK信息，而push模式在消费完之后需要手动返回ack确认信号。

pull模式比较适合用于一些大数据集群的消息消费场景。例如处理一些批量计算任务，每次间隔5分钟或者10分钟就执行一次批处理计算。pull模式可以支持指定每个消费者开启多个消息拉取线程取处理。

push模式在互联网企业中应用会更加广泛些，其设计初衷是为了尽可能地消费掉存储在broker节点中的消息信息，而消息推送速率是由broker来决定，并非由客户端所决定。

push模式常应用于一些自研的im服务器，订单创建，支付通知等业务场景中。

最后留下一道思考题给各位读者：

如果让我们手写实现一个简单的RocketMQ，你会怎么设计呢？

最近自己手写了一个迷你版本的MQ，发现内部涉及到的技术细节点非常之多，在后续的章节中会和大家慢慢分享。

Copyright© 2013-2020

All Rights Reserved 京ICP备2023019179号-8