【mq读书笔记】消息队列负载与重新分配(分配 新队列pullRequest入队)

回顾PullMessageService#run：

如果队列总没有PullRequest对象，线程将阻塞。

围绕PullRequest有2个问题：

1.PullRequest对象在什么时候创建并加入pullRequestQueue中以便唤醒PullMessageService县城

2.集群内多个消费者如何负载主题下的多个消费队列，并且如果有新的消费者加入时，消息队列又会如何重新分布。

重新分布实现：RebalanceService，一个MQClientInstance持有一个RebalanceService实现，并随MQClientInstance启动而启动。

默认每隔20s rebalance一次。

遍历已注册的消费者(这个consumerTable是怎么来的)，对消费者执行doRebalance

  public void doRebalance(final boolean isOrder) {
        Map<String, SubscriptionData> subTable = this.getSubscriptionInner();//在消费者调用subscribe方法时填充。
        if (subTable != null) {
            for (final Map.Entry<String, SubscriptionData> entry : subTable.entrySet()) {
                final String topic = entry.getKey();
                try {
                    this.rebalanceByTopic(topic, isOrder);
                } catch (Throwable e) {
                    if (!topic.startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX)) {
                        log.warn("rebalanceByTopic Exception", e);
                    }
                }
            }
        }

        this.truncateMessageQueueNotMyTopic();
    }

每个DefaultMQPushConsumerImpl都持有一个单独的RebalanceImpl对象，该方法遍历订阅信息对每个主题的队列进行重新负载。

RebalanceImpl#rebalanceByTopic：

从主题订阅信息缓存表中获取主体的队列消息，发送请求从Broker中该消费组内当前所有的消费者客户端ID，主题topic的队列可能分布在多个Broker上，那请求发往哪个Broker呢？

答案是随机选择一个，Broker为什么会存在消费组内所有消费者的信息呢？MQClientInstance会向所有的Broker发送心跳包，心跳中包含MQClientInstance的消费者信息。

allocate()一共有5种分配算法。

  private boolean updateProcessQueueTableInRebalance(final String topic, final Set<MessageQueue> mqSet,
        final boolean isOrder) {
        boolean changed = false;

        Iterator<Entry<MessageQueue, ProcessQueue>> it = this.processQueueTable.entrySet().iterator();
        while (it.hasNext()) {
            Entry<MessageQueue, ProcessQueue> next = it.next();
            MessageQueue mq = next.getKey();
            ProcessQueue pq = next.getValue();

            if (mq.getTopic().equals(topic)) {
　　　　　　　　　　//如果新分配的队列不包含当前旧队列，则停止消费旧队列
                if (!mqSet.contains(mq)) {
                    pq.setDropped(true);
                    if (this.removeUnnecessaryMessageQueue(mq, pq)) {
                        it.remove();
                        changed = true;
                        log.info("doRebalance, {}, remove unnecessary mq, {}", consumerGroup, mq);
                    }
                } else if (pq.isPullExpired()) {
　
                    switch (this.consumeType()) {
                        case CONSUME_ACTIVELY:
                            break;
                        case CONSUME_PASSIVELY:
                            pq.setDropped(true);
                            if (this.removeUnnecessaryMessageQueue(mq, pq)) {
                                it.remove();
                                changed = true;
                                log.error("[BUG]doRebalance, {}, remove unnecessary mq, {}, because pull is pause, so try to fixed it",
                                    consumerGroup, mq);
                            }
                            break;
                        default:
                            break;
                    }
                }
            }
        }

List<PullRequest> pullRequestList = new ArrayList<PullRequest>();
for (MessageQueue mq : mqSet) {
    if (!this.processQueueTable.containsKey(mq)) {
　　　　//如果是新非分配的队列：
        if (isOrder && !this.lock(mq)) {
            log.warn("doRebalance, {}, add a new mq failed, {}, because lock failed", consumerGroup, mq);
            continue;
        }

        this.removeDirtyOffset(mq);
        ProcessQueue pq = new ProcessQueue();
        long nextOffset = this.computePullFromWhere(mq);
        if (nextOffset >= 0) {
            ProcessQueue pre = this.processQueueTable.putIfAbsent(mq, pq);
            if (pre != null) {
                log.info("doRebalance, {}, mq already exists, {}", consumerGroup, mq);
            } else {
　　　　　　　　　　//创建队列拉取任务PullRequest，添加到PullMessageService线程的pullRequestQueue中
                log.info("doRebalance, {}, add a new mq, {}", consumerGroup, mq);
                PullRequest pullRequest = new PullRequest();
                pullRequest.setConsumerGroup(consumerGroup);
                pullRequest.setNextOffset(nextOffset);
                pullRequest.setMessageQueue(mq);
                pullRequest.setProcessQueue(pq);
                pullRequestList.add(pullRequest);
                changed = true;
            }
        } else {
            log.warn("doRebalance, {}, add new mq failed, {}", consumerGroup, mq);
        }
    }
}

this.dispatchPullRequest(pullRequestList);

RebalancePushImpl#computePullFromWhere：

offsetStore.readOffset=-1表示该消息队列刚创建。从磁盘中读取消息队列的消费进度，如果大于0则直接返回即可；如果等于-1，CONSUME_FROM_LAST_OFFSET模式下获取该消息队列当前最大的偏移量。如果小于-1，则表示该消息进度文件中存储了错误的偏移量。

如果CONSUME_FROM_FIRST_OFFSET，则在等于-1时，直接返回0从头开始。

如果CONSUME_FROM_TIMESTAMP：从消费者启动的时间戳对应的消费进度开始消费：

如果等于-1，尝试去操作消息存储时间戳为消费者启动的时间戳，如果能找到则返回找到的偏移量，否则返回0。

以上如果lastOffset小于-1，表示该消息进度文件中存储了错误的偏移量，result=-1，在后面的过程中，用偏移量-1拉取消息时会无法取到消息，但是会用-1去更新消费进度，然后将消息消费队列丢弃，在下一次消息队列负载时会再次消费

总结：RebalanceService线程每隔20s对消费者订阅的主题进行一次队列重新分配，每一次分配都会获取主题的所有队列，从Broker服务器实时查询当前该主题该消费组内消费者列表，对新分配的消息队列会创建对应PullRequest对象。在一个JVM进程中，同一个消费组同一个队列只会存在一个PullRequest对象。

每次进行队列重新负载时会从Broker实时查询出当前组内所有消费者，并且对消息队列，消费者列表进行排序，这样新加入的消费者就会在队列重新分布时分配到消费队列从而消费消息。