RocketMq-Consumer

producer源码结构如下：

我们通常使用mq接受消息，实例化consumer的方式就是:

DefaultMQPushConsumer consumer =  new  DefaultMQPushConsumer( "MyTopic-Consume-Single" );
                                                       //实际调用了
public  DefaultMQPushConsumer(String consumerGroup) {
        this (consumerGroup, (RPCHook) null ,  new  AllocateMessageQueueAveragely());     //注意此处默认创建了一个消费负载均衡策略
}

所以我们就从DefaultMQPushConsumer开始说起吧。

DefaultMQPushConsumer继承了ClientConfig并且实现了MQPushConsumer接口。与producer类似，同时注入一个重要的属性

protected final transient DefaultMQPushConsumerImpl defaultMQPushConsumerImpl;

public  class  DefaultMQPushConsumer  extends  ClientConfig  implements  MQPushConsumer {

    protected  final  transient  DefaultMQPushConsumerImpl defaultMQPushConsumerImpl;

MQPushConsumer接口定义了一些最基本的方法，例如：

void  registerMessageListener( final  MessageListenerConcurrently messageListener);             //消费者注册监听器。
void  subscribe( final  String topic,  final  String subExpression)  throws  MQClientException;          //设置订阅的topic以及tag的方法。

ClientConfig在producer里已经介绍过了，就不重复说了。

而消费消息大致流程如下，我们具体看看各个步骤都做了什么。

consumer.setNamesrvAddr( "10.3.254.52:9876" );                                //设置namesrv，实际是调用ClientConfig.setNamesrvAddr(String namesrvAddr);
consumer.setConsumeFromWhere(ConsumeFromWhere.CONSUME_FROM_FIRST_OFFSET);   //设置消费起始位置。
consumer.setConsumeMessageBatchMaxSize( 5 );                                  //设置每次消费消息数量。
consumer.subscribe( "TopicTest" ,  "*" );                                       //设置订阅的topic和tag。
consumer.registerMessageListener( new  StockListener() );                     //注册消费端的监听器，分为普通消费监听器和顺序消费监听器。其实就是把StockListener赋值给DefaultMQPushConsumer的MessageListener属性。
consumer.start();                                                           //启动消费者。

重点看一下，启动消费者都干了些什么？

   consumer.start();该方法实际调用了DefaultMQPushConsumerImpl .start()     【以下环节都是针对普通消费顺序】

  1、首先进行状态检查，如果是CREATE_JUST才进行以下操作：

  2、将状态置为START_FAILED。

  3、this.checkConfig();进行参数检查，检查范围比较多，大致如下：

       3.1)consumerGroup不能为空，不能含有非法字符，长度不能超过255。

       3.2) 不能为默认的消费者组名"DEFAULT_CONSUMER"。

       3.3）消费模型不能为空，即必须是集群消费或者广播消费的一种【默认是集群消费】

       3.4）起始消费位置不能为空。【只对初次消费有效】

       3.5）消费时间戳不能为空 -- （消息回溯，默认默认值是半小时以前）【只对初次消费有效】

       3.6）消费负载均衡策略不能为空，默认是AllocateMessageQueueAveragely。下面我们看看，这个策略是怎么做到消费负载均衡的。

               public List allocate(String consumerGroup, String currentCID, List mqAll, List cidAll) ；这个方法就是做消费负载均衡的。他的参数currentCID代表这个消费者组的其中一个消费者                                 id,List mqAll代表所有的订阅的topic下所有的messageQueue, List cidAll代表消费者组的消费者集合。该方法最终会为每个消费者分配对应的messageQueue。具体算法查看源码。例如，一个8个                                     messageQueue,消费者组内有三个消费者。

               最终分配情况大致如下：

                            sonsumer0          consumer1          consumer2

                              queue0                queue3                 queue6

                              queue1                queue4                 queue7

                              queue2                queue5

        3.7）存储订阅关系的subscription不能为空，private Map/* topic */, String /* sub expression */> subscription = new HashMap();

        3.8）消费端注册的监听器不能为空，并检查是普通消费还是顺序消费，并且必须是这二者其一。

        3.9）检查消费者默认线程池最小和最大是否是在1~1000且最小值不能大于最大值。【默认最小20，最大64】每1分钟调整一次线程池，这也是针对消费者来说的，具体为如果消息堆积超过10W条，则调大线程池，最多64个线程；如果消      息堆积少于8W条，则调小线程池。

        3.10）检查单队列并行消费最大跨度consumeConcurrentlyMaxSpan，不能小于1不能大于65535。consumeConcurrentlyMaxSpan这个值默认是2000，当RocketMQ发现本地缓存的消息的最大值-最小值差距大于这个值（2000）的时候，会  触发流控——也就是说如果头尾都卡住了部分消息，达到了这个阈值就不再拉取消息。

        3.11）检查拉消息本地队列缓存消息最大数pullThresholdForQueue，不能小于1，大于65535。【默认是1000】。含义是：消费者不间断的从broker拉取消息，消息拉取到本地队列，然后本地消费线程消费本地消息队列，只是一个异步过    程，拉取线程不会等待本地消费线程，这种模式实时性非常高（本地消息队列达到解耦的效果，响应时间减少）。对消费者对本地队列有一个保护，因此本地消息队列不能无限大，否则可能会占用大量内存。ps:还记得broker启动至少需要4G的磁盘吗？还记得每条消息的最大值默认是4M吗？那这里设置的1000是巧合呢还是有意为之？

        3.12）检查pullThresholdForTopic值是否为默认的-1，如果不是则必须在1~65535之间。【表示每个topic在本地缓存最多的消息条数】

        3.13）检查消息缓存值pullThresholdSizeForQueue，不能小于1M，不能大于1024M。【默认是100M】

        3.14）检查每次批量消费规模consumeMessageBatchMaxSize，不能小于1条，不能大于1024条。【默认是1条】

        3.15）检查每次从broker批量拉取消息数量pullBatchSize，不能小于1条，不能大于1024条。【默认32条】

   4、调用this.copySubscription();Client端信号收集，拷贝订阅信息，将消费者的topic订阅关系设置到rebalanceImpl的SubscriptionInner的map中用于负载。

   5、如果是集群消费模式，则将客户端实例名由"DEFAULT"变成客户端实例的进程号。

   6、调用MQClientManager.getInstance().getAndCreateMQClientInstance(this.defaultMQPushConsumer, this.rpcHook);方法，以当前consumer作为参数实例化一个消费端实例。

   7、接着完善rebalanceImpl实例，给他设置消费者组，消费模型，消费端负载均衡策略，以及消费端实例。

   8、构建PullAPIWrapper对象，该对象封装了具体拉取消息的逻辑，PULL,PUSH模式最终都会调用PullAPIWrapper类的方法从Broker拉取消息。

   9、this.pullAPIWrapper.registerFilterMessageHook(filterMessageHookList);又是什么钩子，感觉可有可无，因为跟进去发现接口定义的方法没被实现。

10 、 this .offsetStore =  this .defaultMQPushConsumer.getOffsetStore();给offsetStore赋值，该类主要定义了，对于消费进度管理的一些方法。如果没有，则新建一个。
           若是广播消费： this .offsetStore =  new  LocalFileOffsetStore( this .mQClientFactory,  this .defaultMQPushConsumer.getConsumerGroup());
           若是集群消费： this .offsetStore =  new  RemoteBrokerOffsetStore( this .mQClientFactory,  this .defaultMQPushConsumer.getConsumerGroup());
           同时把新建的offsetStore赋值给defaultMQPushConsumer的offsetStore。

    11、this.offsetStore.load();加载消费进度，集群和广播是不一样的！

    12、建立消费线程，普通消费和顺序消费不同！

顺序消费: this .consumeMessageService = new  ConsumeMessageOrderlyService( this , (MessageListenerOrderly)  this .getMessageListenerInner());
普通消费: this .consumeMessageService =  new  ConsumeMessageConcurrentlyService( this , (MessageListenerConcurrently)  this .getMessageListenerInner());

    13、this.consumeMessageService.start();介绍这个方法之前首先说一下rocketMq的ACK机制。RocketMQ是以consumer group+queue为单位是管理消费进度的，以一个consumer offset标记这个这个消费组在这条queue上的消费进度。每次消  息成功后，本地的消费进度会被更新，然后由定时器定时同步到broker，以此持久化消费进度。但是每次记录消费进度的时候，只会把一批消息中最小的offset值为消费进度值。这钟方式和传统的一条message单独ack的方式有本质的区 别。性能上提升的同时，会带来一个潜在的重复问题——由于消费进度只是记录了一个下标，就可能出现拉取了100条消息如 2101-2200的消息，后面99条都消费结束了，只有2101消费一直没有结束的情况。在这种情况下，RocketMQ 为了保证消息肯定被消费成功，消费进度职能维持在2101，直到2101也消费结束了，本地的消费进度才会一下子更新到2200。在这种设计下，就有消费大量重复的风险。如2101在还没有消费完成的时候消费实例突然退出（机器断电，或 者被kill）。这条queue的消费进度还是维持在2101，当queue重新分配给新的实例的时候，新的实例从broker上拿到的消费进度还是维持在2101，这时候就会又从2101开始消费，2102-2200这批消息实际上已经被消费过还是会投递一次。

            毫无疑问，这个方法就是为了解决这个问题（ACK卡进度）。跟踪进去，发现启动了一个定时线程，15分钟一个周期。而运行的方法叫做cleanExpireMsg();顾名思义，清理过期消息。再联系我们说的ACK卡进度问题，就不难猜出这个方  法就是不让一直未消费成功的消息卡住整体的消费进度。继续跟入代码。Iterator> it =this.defaultMQPushConsumerImpl.getRebalanceImpl().getProcessQueueTable().entrySet().iterator(); //得到        该消费者的消费的breoker的队列集合，已经对应本地处理进度的快照【Queue consumption snapshot】，对于普通消费，该线程会检查本地缓存的消息里的第一条消息，看与当前时间相差是否超过15分钟，若不是，则跳过，该方法结束。若是则表明该消息超过超时时间还没有被消费成功，那么首先会给broker回发消息，表明该消息消费失败，让broker稍后再投递【此处建议细看原代码】。然后本地缓存里删除这条消息。这种删除，一个周期内最多删除16条超时消息。什么意 思？举个例子，假设我拉取的2101-2200，其中2201-2217都超时没消费成功，那么卡进度问题，至少要30分钟才会得到解决，也就是两轮cleanExpireMsg()的调度！

    14、将DefaultMQPushConsumerImpl注册到客户端实例中，也就是往ConcurrentMap/* group */, MQConsumerInner> consumerTable  中put该consumer。

            若未能成功注册，this.serviceState = ServiceState.CREATE_JUST;//状态置为可启动状态        this.consumeMessageService.shutdown();//停掉清理过期消息的线程。

    15、mQClientFactory.start();客户端实例启动，这里和producer客户端实例启动执行的是一模一样的代码。再啰嗦说一遍：

15.1 ） this .serviceState = ServiceState.START_FAILED;    以免客户端同一个进程中重复启动；
15.2 ） this .mQClientAPIImpl.start();   启动客户端netty与服务端建立长连接。
15.3 ） this .startScheduledTask();启动各种任务调度
       15.3 . 1 ）从NameSrv遍历TopicRouteInfo（Topic的路由信息有brokerName，queueId组成），然后更新producer和consumer的topic信息     【 30 秒一次】
       15.3 . 2 ） 清理离线的broker        【 30 秒一次】
       15.3 . 3 ）向所有在MQClientInstance.brokerAddrTable列表中的Broker发送心跳消息    【 30 秒一次】
       15.3 . 4 ）持久化consumer消费进度    【 5 秒一次】
       15.3 . 5 ）启动线程池线程数调整线程。   【每分钟调整一次】
       15.3 . 6 ） this .serviceState = ServiceState.RUNNING;   设置DefaultMQProducerImpl的ServiceState为RUNNING，使producer避免重复启动；
 15.4 ） this .pullMessageService.start();  启动拉消息服务PullMessageService。
 15.5 ） this .rebalanceService.start();  启动消费端负载均衡服务RebalanceService     //此时该线程并没有运行，等待唤醒。
 15.6 ） this .defaultMQProducer.getDefaultMQProducerImpl().start( false );        //这个默认的producer就是为了给broker回发消息！！！
 15.7 ） this .serviceState = ServiceState.RUNNING;       设置DefaultMQProducerImpl的ServiceState为RUNNING，使producer避免重复启动；

   

16 、 this .updateTopicSubscribeInfoWhenSubscriptionChanged();     //从namesrv更新topic的路由信息【建议详细阅读源码】。
17 、 this .mQClientFactory.checkClientInBroker();                 //具体操作就是使用netty给broker发送请求，检查broker状态。
18 、 this .mQClientFactory.sendHeartbeatToAllBrokerWithLock();    //向所有在MQClientInstance.brokerAddrTable列表中的Broker发送心跳消息
19 、 this .mQClientFactory.rebalanceImmediately();                //唤醒负载均衡线程。

    到这里就是消费者启动的完全过程了，但大致如下图：

有两个地方我们需要回头仔细看一下： 15.3）启动拉消息服务PullMessageService。做了什么？     19、 唤醒负载均衡线程。做了什么？

    20、PullMessageService里有一个LinkedBlockingQueue pullRequestQueue，这里面存储这要从broker拉取消息的请求信息，只要这个线程一直运行着，就会不停的从里面取出请求信息，然后调用this.pullMessage(pullRequest);根据请求里consumerGroup获取对应的DefaultMQPushConsumerImpl，在调用DefaultMQPushConsumerImpl的pullMessage(pullRequest);开始真正的从broker拉取消息：

   1）pullRequest.getProcessQueue().setLastPullTimestamp(System.currentTimeMillis());  给请求里的ProcessQueue设置上次拉取消息的时间。

   2）this.makeSureStateOK();   确认consumer的状态是否为 RUNNING。

   3）检查consumer的pause属性，若是true，代表暂停，则建立一个调度线程每秒触发一次尝试拉取消息，this.executePullRequestLater(pullRequest, PULL_TIME_DELAY_MILLS_WHEN_EXCEPTION);

   4）long cachedMessageCount = processQueue.getMsgCount().get();   获取本地缓存的还未消费成功的消息条数。

        long cachedMessageSizeInMiB = processQueue.getMsgSize().get() / (1024 * 1024);   获取本地缓存的还未消费成功的消息的总大小，以M为单位。

   5）若本地缓存的还未消费成功的消息条数>1000（有没有回忆起来，之前说过这个值）或者本地缓存的还未消费成功的消息的总大小>100M，代表达到流控阈值，则建立一个调度线程，每50毫秒再次尝试拉取消息。这里个人觉得，要注意这类情况下roketMq本身的日志记录：

log.warn("the cached message count exceeds the threshold {}, so do flow control, minOffset={}, maxOffset={}, count={}, size={} MiB, pullRequest={}, flowControlTimes={}",this.defaultMQPushConsumer.getPullThresholdForQueue(), processQueue.getMsgTreeMap().firstKey(), processQueue.getMsgTreeMap().lastKey(), cachedMessageCount, cachedMessageSizeInMiB, pullRequest, queueFlowControlTimes)。也就是说，如果我们发现消费端一直没有新的消息，而实际有足够的消息。我觉得就可以检查日志，查找上述关键字，看是否因为本地原因，触发流控了。

   6）如果不是顺序消费，本地未消费消息的跨度是不能大于2000的，例如，目前我就只有两条消息没消费成功，分别是1103,3304，即便只有两条，内存几乎可以忽略不计，这时候也不会再拉取新的消息。会建立一个调度线程每50毫秒再次尝试拉取消息。那么这个状态什么时候会改变呢。两种情况，消费端成功消费了消息或者consumeMessageService到了周期，执行过期消息清理（回忆起来了没，没回忆起来，就看13、）。

        如果是顺序消费，.............................................................................................待补充

   7）final SubscriptionData subscriptionData = this.rebalanceImpl.getSubscriptionInner().get(pullRequest.getMessageQueue().getTopic());     获取请求消息下topic对应的订阅信息。这些东西是在7、处塞进去的。

   8）匿名类实现拉取消息的回调接口，采用异步方式拉取消息时，在收到Broker的响应消息之后，回调该方法执行业务调用者的回调逻辑。PullCallback pullCallback = new PullCallback() {

................}      一个void onSuccess(final PullResult pullResult)方法       一个void onException(final Throwable e)方法

先说onSuccess(final PullResult pullResult)方法  ：

        8.1）调用pullResult = DefaultMQPushConsumerImpl.this.pullAPIWrapper.processPullResult(pullRequest.getMessageQueue(), pullResult,subscriptionData)方法处理broker返回的结果。

        8.1.1）调用PullAPIWrapper.updatePullFromWhichNode(MessageQueue mq, long brokerId)方法用Broker返回的PullResultExt.suggestWhichBrokerId变量值更新PullAPIWrapper.pullFromWhichNodeTable:ConcurrentHashMap 变量中当前拉取消息PullRequest.messageQueue对象对应的BrokerId。若以messageQueue为key值从pullFromWhichNodeTable中获取的BrokerId为空则将PullResultExt.suggestWhichBrokerId存入该列表中，否则更新该MessageQueue对应的value值为suggestWhichBrokerId；          //这里其实就是说broker根据自身状态，建议从主broker还是从从broker拉取消息！

              8.1.2）若pullResult.status=FOUND，则继续下面的处理逻辑，否则设置PullResultExt.messageBinary=null并返回该PullResult对象；

              8.1.3）对PullResultExt.messageBinary变量进行解码，得到MessageExt列表。（这就是我们拉取的消息）

              8.1.4）只保留我们订阅tag集合中的MessageExt对象，构成新的MessageExt列表，取名msgListFilterAgain。

              8.1.5）给其中的每一个消息设置broker返回的MIN_OFFSET和MAX_OFFSET属性。

              8.1.6）返回pullRequst。

如果pullResult.getPullStatus()=FOUND；

          8.2）该PullRequest对象的nextOffset变量值表示本次消费的开始偏移量，赋值给临时变量prevRequestOffset；

          8.3）取PullResult.nextBeginOffset的值（Broker返回的下一次消费进度的偏移值）赋值给PullRequest.nextOffset变量值；

          8.4）记录一下该次的拉取消耗时间。

         8.5）若PullResult.MsgFoundList列表为空，则调用DefaultMQPushConsumerImpl.executePullRequestImmediately(PullRequest pullRequest)方法将该拉取请求对象PullRequest重新延迟放入PullMessageService线程的pullRequestQueue队列中，然后跳出该onSucess方法；否则继续下面的逻辑；

          8.6）firstMsgOffset = pullResult.getMsgFoundList().get(0).getQueueOffset();   获取第一个消息消费进度。

          8.7）记录一下该消费者在此topic下此次拉取消息的数量。

          8.8）processQueue.putMessage(pullResult.getMsgFoundList())   将MessageExt列表存入ProcessQueue.msgTreeMap:TreeMap变量中，放入此变量的目的是：第一在顺序消费时从该变量列表中取消息进行消费，第二可以用此变量中的消息做流控；大致逻辑如下：

               A）遍历List列表，以每个MessageExt对象的queueOffset值为key值，将MessageExt对象存入msgTreeMap:TreeMap变量中；该变量类型根据key值大小排序；

               B）更新ProcessQueue.msgCount变量，记录消息个数；

              C）经过第A步处理之后，若msgTreeMap变量不是空并且ProcessQueue.consuming为false（初始化为false）则置consuming为true（在该msgTreeMap变量消费完之后再置为false）、置临时变量dispatchToConsume为true；否则置临时变量dispatchToConsume为false表示没有待消费的消息或者msgTreeMap变量中存入了数据还未消费完，在没有消费完之前不允许在此提交消费请求，在消费完msgTreeMap之后置consuming为false；

              D）取List列表的最后一个MessageExt对象，该对象的properties属性中取MAX_OFFSET的值，减去该MessageExt对象的queueOffset值，即为Broker端该topic和queueId下消息队列中未消费的逻辑队列的大小，将该值存入ProcessQueue.msgAccCnt变量，用于MQClientInstance. adjustThreadPool()方法动态调整线程池大小（在MQClientInstance中启动定时任务定时调整线程池大小）；

              E）返回临时变量dispatchToConsume值；                //此处的msgTreeMap很重要，流控就依赖他的一些属性

          8.9）调用ConsumeMessageService.submitConsumeRequest(List msgs,ProcessQueue processQueue,MessageQueue messageQueue, boolean dispathToConsume)方法，其中dispathToConsume的值由上一步所得,在顺序消费时使用，为true表示可以消费；大致逻辑如下：

              A）若是 顺序消费 ，则调用ConsumeMessageOrderlyService. submitConsumeRequest(List msgs, ProcessQueue processQueue, MessageQueue messageQueue, boolean dispathToConsume)方法；在该方法中，若上次的msgTreeMap变量中的数据还未消费完（即在2.4步中返回dispathToConsume=false）则不执行任何逻辑；若dispathToConsume=true（即上一次已经消费完了）则以ProcessQueue和MessageQueue对象为参数初始化ConsumeMessageOrderlyService类的内部线程类ConsumeRequest；然后将该线程类放入ConsumeMessageOrderlyService.consumeExecutor线程池中。从而可以看出顺序消费是从ProcessQueue对象的TreeMap树形列表中取消息的。

             B）若是 并发消费 ，则调用ConsumeMessageConcurrentlyService.submitConsumeRequest(List msgs, ProcessQueue processQueue, MessageQueue messageQueue, boolean dispatchToConsume)方法；在该方法中，则根据批次中最大信息条数（由DefaultMQPushConsumer.consumeMessageBatchMaxSize设置,默认为1）来决定是否分提交到线程池中，大致逻辑为:首先比较List列表的个数是否大于了批处理的最大条数，若没有则以该List队列、ProcessQueue对象、MessageQueue对象初始化ConsumeMessageConcurrentlyService的内部类 ConsumeRequest 的对象，并放入ConsumeMessageConcurrentlyService.consumeExecutor线程池中；否则遍历List列表，每次从List列表中取consumeMessageBatchMaxSize个MessageExt对象构成新的List列表，然后以新的MessageExt队列、ProcessQueue对象、MessageQueue对象初始化ConsumeMessageConcurrentlyService的内部类 ConsumeRequest 的对象并放入ConsumeMessageConcurrentlyService.consumeExecutor线程池中，直到该队列遍历完为止。从而可以看出并发消费是将从Broker获取的MessageExt消息列表分配到各个 ConsumeRequest 线程中进行并发消费。 

            8.10）检查拉取消息的间隔时间（DefaultMQPushConsumer.pullInterval，默认为0），若大于0，则调用DefaultMQPushConsumerImpl. executePullRequestLater方法，在间隔时间之后再将PullRequest对象放入PullMessageService线程的pullRequestQueue队列中；若等于0（表示立即再次进行拉取消息），则调用DefaultMQPushConsumerImpl. executePullRequestImmediately方法立即继续下一次拉取消息，从而形成一个循环不间断地拉取消息的过程；

如果pullResult.getPullStatus()=NO_NEW_MSG或者NO_MATCHED_MSG：

       取PullResult.nextBeginOffset的值（Broker返回的下一次消费进度的偏移值）赋值给PullRequest.nextOffset变量值；

      更新消费进度offset。调用DefaultMQPushConsumerImpl.correctTagsOffset(PullRequest pullRequest)方法。若没有获取到消息（即ProcessQueue.msgCount等于0）则更新消息进度。对于LocalFileOffsetStore或RemoteBrokerOffsetStore类，均调用updateOffset(MessageQueue mq, long offset, boolean increaseOnly)方法，而且方法逻辑是一样的，以MessageQueue对象为key值从offsetTable:ConcurrentHashMap变量中获取values值，若该values值为空，则将MessageQueue对象以及offset值（在3.1步中获取的PullResult.nextBeginOffset值）存入offsetTable变量中，若不为空，则比较已经存在的值，若大于已存在的值才更新； 

       调用DefaultMQPushConsumerImpl.executePullRequestImmediately方法立即继续下一次拉取。

如果pullResult.getPullStatus()=OFFSET_ILLEGAL

      取PullResult.nextBeginOffset的值（Broker返回的下一次消费进度的偏移值）赋值给PullRequest.nextOffset变量值；

      设置PullRequest.processQueue.dropped等于true，将此该拉取请求作废；

      创建一个匿名Runnable线程类，然后调用DefaultMQPushConsumerImpl.executeTaskLater(Runnable r, long timeDelay)方法将该线程类放入PullMessageService.scheduledExecutorService: ScheduledExecutorService调度线程池中，在10秒钟之后（可能有地方正在使用，避免受到影响）执行该匿名线程类；该匿名线程类的run方法逻辑如下：

        A）调用OffsetStore.updateOffset(MessageQueue mq, long offset, boolean increaseOnly)方法更新更新消费进度offset；

       B）调用OffsetStore.persist(MessageQueue mq)方法：对于广播模式下offsetStore初始化为LocalFileOffsetStore对象，该对象的persist方法没有处理逻辑；对于集群模式下offsetStore初始化为RemoteBrokerOffsetStore对象，该对象的persist方法中，首先以入参MessageQueue对象为key值从RemoteBrokerOffsetStore.offsetTable: ConcurrentHashMap变量中获取偏移量offset值，然后调用updateConsumeOffsetToBroker(MessageQueue mq, long offset)方法向Broker发送UPDATE_CONSUMER_OFFSET请求码的消费进度信息； 
       C）以PullRequest对象的messageQueue变量为参数调用RebalanceImpl.removeProcessQueue(MessageQueue mq)方法，在该方法中，首先从RebalanceImpl.processQueueTable: ConcurrentHashMap变量中删除MessageQueue记录并返回对应的ProcessQueue对象；然后该ProcessQueue对象的dropped变量设置为ture；最后以MessageQueue对象和ProcessQueue对象为参数调用removeUnnecessaryMessageQueue方法删除未使用的消息队列的消费进度。【主要是删除远程broker的未使用的消息队列的消费进度】

onException方法

延迟提交拉取消息请求，3秒钟之后再将该PullRequest请求重新放入PullMessageService线程的pullRequestQueue队列中；

   9）集群模式下计算提交的消费进度。

  10）计算请求的 订阅表达式 和 是否进行filtersrv过滤消息

  11）计算拉取消息系统标识（一些与运算，暂时不知道什么用）

 

12 ) this .pullAPIWrapper.pullKernelImpl(                   // 执行拉取。下面对参数做一下说明
        pullRequest.getMessageQueue(),                    //拉取消息的目标的queue【包含topic,brokername,brokerid】
        subExpression,                                    //订阅的tag
        subscriptionData.getExpressionType(),
        subscriptionData.getSubVersion(),                 //订阅的版本号
        pullRequest.getNextOffset(),                      //拉取队列开始位置
        this .defaultMQPushConsumer.getPullBatchSize(),    //每次拉取的数量
        sysFlag,                                          //拉取消息系统标识
        commitOffsetValue,                                //提交消费进度
        BROKER_SUSPEND_MAX_TIME_MILLIS,                   //broker挂起请求最大时间
        CONSUMER_TIMEOUT_MILLIS_WHEN_SUSPEND,             //请求broker超时时长
        CommunicationMode.ASYNC,                          //拉取模式为异步
        pullCallback                                      //拉取回调
);

如果拉取请求发生异常时，提交延迟拉取消息请求。

this.executePullRequestLater(pullRequest, PULL_TIME_DELAY_MILLS_WHEN_EXCEPTION);

看一下this.pullAPIWrapper.pullKernelImpl实际上是怎么执行消息的拉取工作的：

       获取broker信息，主要包含brokerAddr,是否是从broker,以及broker的版本号，

FindBrokerResult findBrokerResult =  this .mQClientFactory.findBrokerAddressInSubscribe(mq.getBrokerName(), this .recalculatePullFromWhichNode(mq),  false );  //this.recalculatePullFromWhichNode(mq)是获取推荐brokerId的。

       如果null == findBrokerResult，此时需要从nameServer更新topic路由信息，再次调用

this .mQClientFactory.findBrokerAddressInSubscribe(mq.getBrokerName(), this .recalculatePullFromWhichNode(mq),  false );

若此时findBrokerResult仍然为null，则抛出broker不存在的异常。

如果findBrokerResult不为null  ：  检查版本号，如果版本号<4.1.0同时expressionType（过滤表达式）！=tag则抛出未升级到支持文件消息的版本，新版本除了tag过滤消息，还可以用sql过滤。

构建请求头：

PullMessageRequestHeader requestHeader =  new  PullMessageRequestHeader();
requestHeader.setConsumerGroup( this .consumerGroup);                    //塞入消费者组
requestHeader.setTopic(mq.getTopic());                                 //塞入订阅的topic
requestHeader.setQueueId(mq.getQueueId());                             //塞入订阅的broker的queueID
requestHeader.setQueueOffset(offset);                                  //本次拉取消息的位置
requestHeader.setMaxMsgNums(maxNums);                                  //本次拉取消息的数量
requestHeader.setSysFlag(sysFlagInner);                               // 应该是用来判断是否使用文件过滤器
requestHeader.setCommitOffset(commitOffset);                          //消费者提交的消费进度
requestHeader.setSuspendTimeoutMillis(brokerSuspendMaxTimeMillis);    //拉取消息请求被挂起的超时时间
requestHeader.setSubscription(subExpression);                         //订阅的tag
requestHeader.setSubVersion(subVersion);                              // 一个时间戳，某个消费者每更新了订阅信息，就会新生成一个
requestHeader.setExpressionType(expressionType);                      //过滤表达式
                                                                     //然后判断是否使用了文件过滤，如果是的话，那么broker的地址应该就是对应的文件服务器的地址。
if  (PullSysFlag.hasClassFilterFlag(sysFlagInner)) {
    brokerAddr = computPullFromWhichFilterServer(mq.getTopic(), brokerAddr);
}

//接着调用
PullResult pullResult =  this .mQClientFactory.getMQClientAPIImpl().pullMessage（brokerAddr,
requestHeader,
timeoutMillis,
communicationMode,
pullCallback）;
//进而调用
public  PullResult pullMessage(）;
//我们拉取消息是采用异步的，所以调用
this .pullMessageAsync(addr, request, timeoutMillis, pullCallback);
//进而调用netty客户端发拉取取消息的请求：
this .remotingClient.invokeAsync（addr, request, timeoutMillis,  new  InvokeCallback(){.........}）; //   这里采用匿名内部内创建一个监听器，用于接受消息拉取成功后的回调信息。
//然后成功收到broker的返回信息就调用
pullCallback.onSuccess(pullResult);
//否则调用
pullCallback.onException（）；
后续在producer发消息中就讲过了，netty的一下东西。

拉取消息流程如下图：

     到此，我们解决了回头看的两个疑问中的15.3（ 到这里就是消费者启动的完全过程了，有两个地方我们需要回头仔细看一下： 15.3）启动拉消息服务PullMessageService。做了什么？     19、 唤醒负载均衡线程。做了什么？），接下来，我们看看在DefaultMQPushConsumer启动时唤醒的负载均衡线程，做了什么：

     当唤醒rebalanceImpl时，在集群消费模式下，他会执行如下操作：

首先通过topic获取订阅的queue的set集合、然后通过消费者组名和topic给broker发送请求，获取该消费者组下的消费者id集合。

Set mqSet =  this .topicSubscribeInfoTable.get(topic);
List cidAll =  this .mQClientFactory.findConsumerIdList(topic, consumerGroup);

      将这两个集合排序，然后将他们作为参数调用此方法，做负载均衡

List allocateResultallocateResult = strategy.allocate( this .consumerGroup, this .mQClientFactory.getClientId(),mqAll,cidAll);

说白了就是，我告诉你我这个消费者组有几个消费者，我要订阅的topic下的所有的broker的queue的集合，你给我用指定策略分配一下，看看我的当前这个消费者应该订阅那几个queue。

//然后调用
updateProcessQueueTableInRebalance( final  String topic,  final  Set mqSet,  final  boolean  isOrder);
//在负载均衡线程内
ConcurrentMap processQueueTable  记录了每个订阅的queue与本地对应的处理进度。
如果发现传入的mqSet不包含它本身记录的MessageQueue，则说明他之前记录的要订阅的queue在负载均衡之后不再订阅了，
则在本地和broker同时持久化对应MessageQueue的消费进度，在本地和broker删除对应MessageQueue的消费进度。
然后将rebalanceImpl中processQueueTable对应的记录删除。而且如果发现本地消息缓存的ProcessQueue已经超过 2 分钟没有拉取消息，
即使负载均衡后仍然包含该MessageQueue，也做不包含该MessageQueue的一样的处理。

         然后调用computePullFromWhere计算从broker拉取消息的位置，拿我们常用的CONSUME_FROM_FIRST_OFFSET 来说：会调用long lastOffset = offsetStore.readOffset(mq, ReadOffsetType.READ_FROM_STORE);得到消费进度。

由于通常消费进度每隔一段时间就会持久化到文件里，所以一般情况下，我们也是存文件中获取消费进度，而不是从内存。然后ProcessQueue pre = this.processQueueTable.putIfAbsent(mq, pq);插入一条新的记录。

构造拉取请求：

PullRequest pullRequest =  new  PullRequest();
pullRequest.setConsumerGroup(consumerGroup);     //设置消费者组
pullRequest.setNextOffset(nextOffset);      //设置拉取位置
pullRequest.setMessageQueue(mq);        //设置从哪个queue拉取消息
pullRequest.setProcessQueue(pq);         //设置本地对应存的queue
pullRequestList.add(pullRequest);         //添加请求
然后将这些请求逐个放入PullMessageService 的  private  final  LinkedBlockingQueue pullRequestQueue 中。然后...请看 20 、

到此我们的负载均衡后，订阅队列改变后，还要通知broker：public void messageQueueChanged(String topic, Set mqAll, Set mqDivided) {..........}

在此方法中1、取当前时间赋值给subscriptionData.setSubVersion(newVersion);

如果我们限制了topic级别的消息缓存数（通常没有），那么会将本地每个queue的缓存数更新为pullThresholdForTopic / currentQueueCount     限制总数 / 队列数

同理，如果我们在topic级别限制了消息缓存的大小（通常没有），那么会将本地每个queue的缓存大小更新为pullThresholdSizeForTopic / currentQueueCount  限制总大小 / 队列数

最后调用this.getmQClientFactory().sendHeartbeatToAllBrokerWithLock();向broker发送心跳，告知这些信息。

接下来我们看看给broker发送心跳信息，主要是执行一下两个方法，

this.sendHeartbeatToAllBroker();
this.uploadFilterClassSource();

跟入第一个方法，首先获取心跳数据
HeartbeatData heartbeatData = this.prepareHeartbeatData();
在此方法中，首先会设置ClientId,然后根据各个consumer给heartbeatData的Set getConsumerDataSet设置值，其中ConsumerData，每个ConsumerData包括consumerGroup，获取消费方式（pull/push）,消费模型（集群/广播），从哪里开始消费，订阅的tag以及编码。

至于Set getProducerDataSet()，只给ProducerData设置producerGroup。

然后获取private final ConcurrentMap/* Broker Name */, HashMap/* brokerId */, String/* address */>> brokerAddrTable 所有broker的addr，调用下面的方法

int version = this.mQClientAPIImpl.sendHearbeat(addr, heartbeatData, 3000);

将请求码设置成RequestCode.HEART_BEAT，然后对heartbeatData进行编码，最后使用netty发送给broker，这里的超时时间设置的3秒。

而this.uploadFilterClassSource();则是向broker更新文件过滤类，这个我们暂时没用，所以暂时略过，后面可能会在FileterSrv细说。目前可以参考FileterSrv作用。

发送完成后会将broker返回的信息用于更新 this.brokerVersionTable.get(brokerName).put(addr, version);

最后RebalanceImplthis.truncateMessageQueueNotMyTopic();会将不再订阅的topic对应的本地的处理队列删除。整个流程大致如下

那么，到这里，DefaultMQPushConsumer拉取消息的整个流程就结束了。里面有些细节的地方没有说得很详细，也是因为DefaultMQPushConsumer拉取消息的确实比较复杂。后面会回过头来补充和总结这部分的。