RocketMQ源码17-consumer 负载均衡（重平衡）

超、凢脫俗 2023-09-25 23:25 158阅读 0赞

前面我们在分析[Consumer消费过程][Consumer]时，有提到一个非常重要的概念，就是**重平衡**，只有在经过重平衡后，消息的拉取对象`PullMessageService`才可以去`Broker`拉取消息，那么这篇文章就单独分析下什么是重平衡?

**重平衡分析的前提是：集群消费模式**。 重平衡要做的也很简单，就是给当前消费者分配属于它的`逻辑消费队列`。

## 1.什么是重平衡? ##

`Rebalance`(重平衡)机制指的是：将一个`Topic`下的多个队列，在同一个消费者组(`consumer group`)下的多个消费者实例(`consumer instance`)之间进行重新分配。

`Rebalance`机制的本意是为了`提升消息的并行消费能力`。例如，⼀个Topic下5个队列，在只有1个消费者的情况下，这个消费者将负责消费这5个队列的消息。如果此时我们增加⼀个消费者，那么就可以给其中⼀个消费者分配2个队列，给另⼀个分配3个队列，从而提升消息的并行消费能力。

由于⼀个队列最多分配给消费者组下的⼀个消费者，因此当某个消费者组下的`消费者实例数量`大于`队列的数量`时，多余的消费者实例将分配不到任何队列。

![format_png][]

接下来以集群模式下的消息推模式`DefaultMQPushConsumerImpl`为例，看一下负载均衡的过程。

## 2. 消费者启动DefaultMQPushConsumerImpl ##

首先，消费者在启动时会做如下操作：

1.  从NameServer更新当前消费者订阅主题的路由信息；
2.  向Broker发送心跳，注册消费者；
3.  唤醒负载均衡服务，触发一次负载均衡；

public class DefaultMQPushConsumerImpl implements MQConsumerInner {
        public synchronized void start() throws MQClientException {
            // ...
            // 更新当前消费者订阅主题的路由信息
            this.updateTopicSubscribeInfoWhenSubscriptionChanged();
            this.mQClientFactory.checkClientInBroker();
            // 向Broker发送心跳
            this.mQClientFactory.sendHeartbeatToAllBrokerWithLock();
            // 唤醒负载均衡服务
            this.mQClientFactory.rebalanceImmediately();
        }
    }
    复制代码

### 2.1 更新主题路由信息 ###

为了保证消费者拿到的主题路由信息是最新的（topic下有几个消息队列、消息队列的分布信息等），在进行负载均衡之前首先要更新主题的路由信息，在`updateTopicSubscribeInfoWhenSubscriptionChanged`方法中可以看到，首先获取了当前消费者订阅的所有主题信息（一个消费者可以订阅多个主题），然后进行遍历，向NameServer发送请求，更新每一个主题的路由信息，保证路由信息是最新的：

public class DefaultMQPushConsumerImpl implements MQConsumerInner {
        private void updateTopicSubscribeInfoWhenSubscriptionChanged() {
            // 获取当前消费者订阅的主题信息
            Map<String, SubscriptionData> subTable = this.getSubscriptionInner();
            if (subTable != null) {
                // 遍历订阅的主题信息
                for (final Map.Entry<String, SubscriptionData> entry : subTable.entrySet()) {
                    final String topic = entry.getKey();
                    // 从NameServer更新主题的路由信息
                    this.mQClientFactory.updateTopicRouteInfoFromNameServer(topic);
                }
            }
        }
    }
    复制代码

### 2.2 注册消费者 ###

#### 2.2.1 发送心跳 ####

由于Broker需要感知消费者数量的增减，所以每个消费者在启动的时候，会调用`sendHeartbeatToAllBrokerWithLock`向Broker发送心跳包，进行消费者注册：

public class MQClientInstance {
        public void sendHeartbeatToAllBrokerWithLock() {
            if (this.lockHeartbeat.tryLock()) {
                try {
                    // todo 调用sendHeartbeatToAllBroker向Broker发送心跳
                    this.sendHeartbeatToAllBroker();
                    this.uploadFilterClassSource();
                } catch (final Exception e) {
                    log.error("sendHeartbeatToAllBroker exception", e);
                } finally {
                    this.lockHeartbeat.unlock();
                }
            } else {
                log.warn("lock heartBeat, but failed. [{}]", this.clientId);
            }
        }
    }
    复制代码

在`sendHeartbeatToAllBroker`方法中，可以看到从`brokerAddrTable`中获取了所有的Broker进行遍历（主从模式下也会向从节点发送请求注册），调用`MQClientAPIImpl`的`sendHearbeat`方法向每一个Broker发送心跳请求进行注册：

public class MQClientInstance {
        // Broker路由表
        private final ConcurrentMap<String/* Broker Name */, HashMap<Long/* brokerId */, String/* address */>> brokerAddrTable =
            new ConcurrentHashMap<String, HashMap<Long, String>>();
        // 发送心跳
        private void sendHeartbeatToAllBroker() {
            final HeartbeatData heartbeatData = this.prepareHeartbeatData();
            // ...
            if (!this.brokerAddrTable.isEmpty()) {
                long times = this.sendHeartbeatTimesTotal.getAndIncrement();
                // 获取所有的Broker进行遍历， key为 Broker Name， value为同一个name下的所有Broker实例（主从模式下Broker的name一致）
                Iterator<Entry<String, HashMap<Long, String>>> it = this.brokerAddrTable.entrySet().iterator();
                while (it.hasNext()) {
                    Entry<String, HashMap<Long, String>> entry = it.next();
                    String brokerName = entry.getKey(); // broker name
                    // 获取同一个Broker Name下的所有Broker实例
                    HashMap<Long, String> oneTable = entry.getValue();
                    if (oneTable != null) {
                        // 遍历所有的实例
                        for (Map.Entry<Long, String> entry1 : oneTable.entrySet()) {
                            Long id = entry1.getKey();
                            String addr = entry1.getValue();
                            if (addr != null) { // 如果地址不为空
                                // ...
                                try {
                                    // 发送心跳
                                    int version = this.mQClientAPIImpl.sendHearbeat(addr, heartbeatData, clientConfig.getMqClientApiTimeout());
                                    // ...
                                } catch (Exception e) {
                                    // ...
                                }
                            }
                        }
                    }
                }
            }
        }
    }
    复制代码

在`MQClientAPIImpl`的`sendHearbeat`方法中，可以看到构建了`HEART_BEAT`请求，然后向Broker发送：

public class MQClientAPIImpl {
       public int sendHearbeat(final String addr, final HeartbeatData heartbeatData, final long timeoutMillis
        ) throws RemotingException, MQBrokerException, InterruptedException {
            // 创建HEART_BEAT请求
            RemotingCommand request = RemotingCommand.createRequestCommand(RequestCode.HEART_BEAT, null);
            request.setLanguage(clientConfig.getLanguage());
            request.setBody(heartbeatData.encode());
            // 发送请求
            RemotingCommand response = this.remotingClient.invokeSync(addr, request, timeoutMillis);
            // ...
        }
    }
    复制代码

#### 2.2.2 broker心跳请求处理 ####

Broker在启动时注册了`HEART_BEAT`请求的处理器，可以看到请求处理器是`ClientManageProcessor`：

public class BrokerController {
        public void registerProcessor() {
            ClientManageProcessor clientProcessor = new ClientManageProcessor(this);
            // 注册HEART_BEAT请求的处理器ClientManageProcessor
            this.remotingServer.registerProcessor(RequestCode.HEART_BEAT, clientProcessor, this.heartbeatExecutor);
        }
    }
    复制代码

进入到`ClientManageProcessor`的`processRequest`方法，如果请求是`HEART_BEAT`类型会调用`heartBeat`方法进行处理，这里也能看还有`UNREGISTER_CLIENT`类型的请求，从名字上可以看出是与取消注册有关的（这个稍后再说）：

进入到`heartBeat`方法，可以看到，调用了`ConsumerManager`的`registerConsumer`注册消费者：

public class ClientManageProcessor extends AsyncNettyRequestProcessor implements NettyRequestProcessor {
        public RemotingCommand heartBeat(ChannelHandlerContext ctx, RemotingCommand request) {
            // ...
            for (ConsumerData data : heartbeatData.getConsumerDataSet()) {
                // ...
                // 注册Consumer
                boolean changed = this.brokerController.getConsumerManager().registerConsumer(
                    data.getGroupName(), clientChannelInfo, data.getConsumeType(), data.getMessageModel(), data.getConsumeFromWhere(),
                    data.getSubscriptionDataSet(), isNotifyConsumerIdsChangedEnable);
                // ...
            }
            // ...
            return response;
        }
    }
    复制代码

进行注册

`ConsumerManager`的`registerConsumer`方法的理逻辑如下：

1.  根据组名称获取该消费者组的信息`ConsumerGroupInfo`对象。如果获取为空，会创建一个`ConsumerGroupInfo`，记录了消费者组的相关信息；
2.  判断消费者是否发生了变更，如果如果发生了变化，会触发`CHANGE`变更事件（这个稍后再看）；
3.  触发`REGISTER`注册事件；

进入到`DefaultConsumerIdsChangeListener`的`handle`方法中，可以看到如果是`REGISTER`事件，会通过`ConsumerFilterManager`的`register`方法进行注册，注册的详细过程这里先不展开讲解：

public class DefaultConsumerIdsChangeListener implements ConsumerIdsChangeListener {
        @Override
        public void handle(ConsumerGroupEvent event, String group, Object... args) {
            if (event == null) {
                return;
            }
            switch (event) {
                case CHANGE:// 如果是消费者变更事件
                    // ...
                    break;
                case UNREGISTER: // 如果是取消注册事件
                    this.brokerController.getConsumerFilterManager().unRegister(group);
                    break;
                case REGISTER: // 如果是注册事件
                    if (args == null || args.length < 1) {
                        return;
                    }
                    Collection<SubscriptionData> subscriptionDataList = (Collection<SubscriptionData>) args[0];
                    // 进行注册
                    this.brokerController.getConsumerFilterManager().register(group, subscriptionDataList);
                    break;
                default:
                    throw new RuntimeException("Unknown event " + event);
            }
        }
    }
    复制代码

### 2.3 立即重平衡 ###

org.apache.rocketmq.client.impl.factory.`MQClientInstance#rebalanceImmediately`：

public void rebalanceImmediately() {
        this.rebalanceService.wakeup();
    }
    复制代码

这里会唤醒org.apache.rocketmq.client.impl.consumer.`RebalanceService`的run方法中的 `this.mqClientFactory.doRebalance();`:

@Override
    public void run() {
        log.info(this.getServiceName() + " service started");
    
    
        while (!this.isStopped()) {
            // todo 等待20s执行一次 内部使用了juc的CountDownLatch, 使得这里启动后仍然是阻塞的
            this.waitForRunning(waitInterval);
            // todo
            this.mqClientFactory.doRebalance();
        }
    
        log.info(this.getServiceName() + " service end");
    }
    复制代码

接下来我们重点看一下 `重平衡`。

## 3.重平衡之queue的分配 ##

> `rocketmq`中的`rebalance`是`consumer`实例自身完成的

public class RebalanceService extends ServiceThread {
        private static long waitInterval = Long.parseLong(System.getProperty(
                "rocketmq.client.rebalance.waitInterval", "20000"));
                
        //TODO:...略.....        
      
        @Override
        public void run() {
            log.info(this.getServiceName() + " service started");
    
            while (!this.isStopped()) {
                this.waitForRunning(waitInterval);
                this.mqClientFactory.doRebalance();
            }
    
            log.info(this.getServiceName() + " service end");
        }
    }
    复制代码

> 从代码中可以看到，它默认是`每隔20s`触发一次重平衡。

那么我们继续看下consumer客户端是如何完成重平衡的：

org.apache.rocketmq.client.impl.consumer.`RebalanceImpl#doRebalance`:

public void doRebalance(final boolean isOrder) {
        Map<String, SubscriptionData> subTable = this.getSubscriptionInner();
        if (subTable != null) {
            for (final Map.Entry<String, SubscriptionData> entry : subTable.entrySet()) {
                final String topic = entry.getKey();
                try {
                    // todo 客户端负载均衡：根据主题来处理负载均衡
                    this.rebalanceByTopic(topic, isOrder);
                } catch (Throwable e) {
                    if (!topic.startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX)) {
                        log.warn("rebalanceByTopic Exception", e);
                    }
                }
            }
        }
    
        this.truncateMessageQueueNotMyTopic();
    }
    复制代码

我们继续往下走： org.apache.rocketmq.client.impl.consumer.`RebalanceImpl#rebalanceByTopic`:

private void rebalanceByTopic(final String topic, final boolean isOrder) {
        switch (messageModel) {
            // 广播模式：不需要处理负载均衡，每个消费者都要消费，只需要更新负载信息
            case BROADCASTING: {
                // 更新负载均衡信息，这里传入的参数是mqSet，即所有队列
                Set<MessageQueue> mqSet = this.topicSubscribeInfoTable.get(topic);
                if (mqSet != null) {
                    boolean changed = this.updateProcessQueueTableInRebalance(topic, mqSet, isOrder);
                    if (changed) {
                        this.messageQueueChanged(topic, mqSet, mqSet);
                        log.info("messageQueueChanged {} {} {} {}",
                            consumerGroup,
                            topic,
                            mqSet,
                            mqSet);
                    }
                } else {
                    log.warn("doRebalance, {}, but the topic[{}] not exist.", consumerGroup, topic);
                }
                break;
            }
            // todo 集群模式
            case CLUSTERING: {
                // 从主题订阅信息缓存表中获取主题的队列信息, 获取这个topic下的所有队列（默认是4个）
                Set<MessageQueue> mqSet = this.topicSubscribeInfoTable.get(topic);
                //发送请求从Broker中获取该消费组内当前所有的消费者客户端ID，主题的队
                //列可能分布在多个Broker上，那么请求该发往哪个Broker呢？
                //RocketeMQ从主题的路由信息表中随机选择一个Broker
                List<String> cidAll = this.mQClientFactory.findConsumerIdList(topic, consumerGroup);
                if (null == mqSet) {
                    if (!topic.startsWith(MixAll.RETRY_GROUP_TOPIC_PREFIX)) {
                        log.warn("doRebalance, {}, but the topic[{}] not exist.", consumerGroup, topic);
                    }
                }
    
                if (null == cidAll) {
                    log.warn("doRebalance, {} {}, get consumer id list failed", consumerGroup, topic);
                }
    
                // 如果mqSet、cidAll任意一个为空，则忽略本次消息队列负载
                if (mqSet != null && cidAll != null) {
                    List<MessageQueue> mqAll = new ArrayList<MessageQueue>();
                    mqAll.addAll(mqSet);
    
                    // 对cidAll、mqAll进行排序
                    // 这一步很重要，同一个消费组内看到的视图应保持一致，确保同一个消费队列不会被多个消费者分配
                    Collections.sort(mqAll);
                    Collections.sort(cidAll);
    
                    // 默认是平均分配策略
                    AllocateMessageQueueStrategy strategy = this.allocateMessageQueueStrategy;
    
                    List<MessageQueue> allocateResult = null;
                    try {
                        // todo 分配算法
                        allocateResult = strategy.allocate(
                            this.consumerGroup,
                            this.mQClientFactory.getClientId(),
                            mqAll,
                            cidAll);
                    } catch (Throwable e) {
                        log.error("AllocateMessageQueueStrategy.allocate Exception. allocateMessageQueueStrategyName={}", strategy.getName(),
                            e);
                        return;
                    }
    
                    //TODO:保存了当前消费者需要消费的队列
                    Set<MessageQueue> allocateResultSet = new HashSet<MessageQueue>();
                    if (allocateResult != null) {
                        allocateResultSet.addAll(allocateResult);
                    }
    
    
                    // todo 对比消息队列是否发生变化 更新负载均衡信息，传入参数是 allocateResultSet，即当前consumer分配到的队列
                    boolean changed = this.updateProcessQueueTableInRebalance(topic, allocateResultSet, isOrder);
                    if (changed) {
                        log.info(
                            "rebalanced result changed. allocateMessageQueueStrategyName={}, group={}, topic={}, clientId={}, mqAllSize={}, cidAllSize={}, rebalanceResultSize={}, rebalanceResultSet={}",
                            strategy.getName(), consumerGroup, topic, this.mQClientFactory.getClientId(), mqSet.size(), cidAll.size(),
                            allocateResultSet.size(), allocateResultSet);
                        this.messageQueueChanged(topic, mqSet, allocateResultSet);
                    }
                }
                break;
            }
            default:
                break;
        }
    }
    复制代码

这里根据消费模式进行了判断

1.  `广播模式`：消费者要消费所有队列的数据，所以如果queue变动了，就更新消费者的消费队列，总之就是消费者要消费所有队列。
2.  `集群模式`：相同`Consumer Group`的每个`Consumer`实例平均分摊同一个`Topic`的消息。即每条消息只会被发送到`Consumer Group`中的某个`Consumer`。

> 我们这里就关注集群模式。

在继续探讨重平衡之前，先提一下queue的分配算法：

1.  `平均分配策略(默认）`

> 它会根据当前消费者在消费者集群中的位置(索引),以及`queueCount%consumerCount`的余数，计算当前消费者可以分配的queue。

> 举例：如果是4个queue,3个消费者; consumer1分配queueid=0,1;consumer2分配queueid=2,consumer3分配queueid=3。

1.  `环形平均策略`

> 环形平均策略根据消费者的顺序，依次在由queue队列组成的环形图中逐个分配；该算法不用事先计算每个Consumer需要分配几个Queue，直接一个一个分即可。

> 举例：如果是4个queue,3个消费者; consumer1分配queueid=0,3;consumer2分配queueid=1,consumer3分配queueid=2。它和平均分配不同的是，它先给consumer1分配queueid=0,consumer2分配queueid=1,consumer3分配queueid=2,然后再将多余的queueid=3分配给consumer1。

1.  `一致性hash策略`

> 该策略会将consumer的hash值作为Node节点存放到hash环上，然后将queue的hash值也放到hash环上，通过顺时针方向，距离queue最近的那个consumer就是该queue要分配的consumer。其可以有效减少由于消费者组扩容或缩容所带来的大量的Rebalance

1.  同机房策略

> 该算法会根据queue的部署机房位置和consumer的位置，过滤出当前consumer相同机房的queue。不过，这种情况下，brokerName在命名上要按照的`机房名@brokerName`格式。

1.  就近机房策略

> 它是上面同机房策略的补充。比如同机房中只有queue而没有consumer,此时就可以使用就近机房策略进行补充。

对应的接口：

/**
     * queue分配策略
     */
    public interface AllocateMessageQueueStrategy {
    
        /**
         * Allocating by consumer id
         *
         * @param consumerGroup:消费者组
         * @param currentCID:当前的消费者id
         * @param mqAll:topic下的所有队列
         * @param cidAl：消费者组下的所有消费者id
         * @return :返回当前消费者需要消费的队列
         */
        List<MessageQueue> allocate(
            final String consumerGroup,
            final String currentCID,
            final List<MessageQueue> mqAll,
            final List<String> cidAll
        );
    }
    复制代码

> 默认使用的是平均分配策略 `AllocateMessageQueueAveragely`

这里我们重点来分析平均负载策略`AllocateMessageQueueAveragely`：

public List<MessageQueue> allocate(String consumerGroup, String currentCID, 
            List<MessageQueue> mqAll, List<String> cidAll) {
        // 返回值        
        List<MessageQueue> result = new ArrayList<MessageQueue>();
    
        // 省略一些判断操作
        ...
    
    
        int index = cidAll.indexOf(currentCID);
        int mod = mqAll.size() % cidAll.size();
        // 1. 消费者数量大于队列数量：averageSize = 1
        // 2. 消费者数量小于等于队列数量：averageSize = 队列数量 / 消费者数量，还要处理个+1的操作
        int averageSize = mqAll.size() <= cidAll.size() 
            ? 1 : (mod > 0 && index < mod 
                ? mqAll.size() / cidAll.size() + 1 : mqAll.size() / cidAll.size());
        int startIndex = (mod > 0 && index < mod) ? index * averageSize : index * averageSize + mod;
        int range = Math.min(averageSize, mqAll.size() - startIndex);
        for (int i = 0; i < range; i++) {
            result.add(mqAll.get((startIndex + i) % mqAll.size()));
        }
        return result;
    }
    复制代码

这个方法中，关键的分配方法就在后面几行，如果只看代码，会感觉有点晕，这里我举一个例子来简单解释下：

假设：`messageQueue`一共有6个，`consumer`有4个，当前`consumer`的`index`为1，有了这些前提后，接下来我们就来看它的分配过程了。

1.  计算取余操作：`6 % 4 = 2`，这表明`messageQueue`不能平均分配给每个`consumer`，接下来就来看看这个`余数2`是如何处理的
2.  计算每个`consumer`平均处理的`messageQueue`数量
    
     *  这里需要注意，如果`consumer`数量大于`messageQueue`数量，那每个`consumer`最多只会分配到一个`messageQueue`，这种情况下，`余数2`不会进行处理，并且有的`consumer`处理的`messageQueue`数量为0，同一个`messageQueue`不会同时被两个及以上的`consumer`消费掉
     *  这里的`messageQueue`数量为6，`consumer`为4，计算得到每个`consumer`处理的队列数最少为1，除此之外，为了实现“平均”，有2个`consumer`会需要多处理1个`messageQueue`，按“平均”的分配原则，如果`index`小于`mod`，则会分配多1个`messageQueue`，这里的`mod`为2，结果如下：
    
    <table> 
     <thead> 
      <tr> 
       <th>消费者索引</th> 
       <th>0</th> 
       <th>1</th> 
       <th>2</th> 
       <th>3</th> 
      </tr> 
     </thead> 
     <tbody> 
      <tr> 
       <td>处理数量</td> 
       <td>2</td> 
       <td>2</td> 
       <td>1</td> 
       <td>1</td> 
      </tr> 
     </tbody> 
    </table>
3.  分配完每个`consumer`处理的`messageQueue`数量后，这些`messageQueue`该如何分配呢？从代码来看，分配时会先分配完一个`consumer`，再分配下一个`consumer`，最终结果就是这样：
    
    <table> 
     <thead> 
      <tr> 
       <th>队列</th> 
       <th>Q0</th> 
       <th>Q1</th> 
       <th>Q2</th> 
       <th>Q3</th> 
       <th>Q4</th> 
       <th>Q5</th> 
      </tr> 
     </thead> 
     <tbody> 
      <tr> 
       <td>消费者</td> 
       <td>C1</td> 
       <td>C1</td> 
       <td>C2</td> 
       <td>C2</td> 
       <td>C4</td> 
       <td>C5</td> 
      </tr> 
     </tbody> 
    </table>

从图中可以看到，在6个`messageQueue`、4个`consumer`、当前`consumer`的`index`为1的情况下，当前`consumer`会分到2个队列，分别为`Q2`/`Q3`.

> 其他分配策略 大家可自行阅读源码

## 4.重平衡核心逻辑分析 ##

/**
     * 对比消息队列是否发生变化，主要思路是遍历当前负载队列集
     * 合，如果队列不在新分配队列的集合中，需要将该队列停止消费并保
     * 存消费进度；遍历已分配的队列，如果队列不在队列负载表中
     * （processQueueTable），则需要创建该队列拉取任务PullRequest，
     * 然后添加到PullMessageService线程的pullRequestQueue中，
     * PullMessageService才会继续拉取任务
     */
    private boolean updateProcessQueueTableInRebalance(final String topic, final Set<MessageQueue> mqSet,
        final boolean isOrder) {
        boolean changed = false;
    
        /**
         * ConcurrentMap〈MessageQueue, ProcessQueue〉
         * processQueueTable是当前消费者负载的消息队列缓存表，如果缓存表
         * 中的MessageQueue不包含在mqSet中，说明经过本次消息队列负载后，
         * 该mq被分配给其他消费者，需要暂停该消息队列消息的消费。方法是
         * 将ProccessQueue的状态设置为droped=true，该ProcessQueue中的消
         * 息将不会再被消费，调用removeUnnecessaryMessageQueue方法判断是
         * 否将MessageQueue、ProccessQueue从缓存表中移除。
         * removeUnnecessaryMessageQueue在RebalanceImple中定义为抽象方
         * 法。removeUnnecessaryMessageQueue方法主要用于持久化待移除
         * MessageQueue的消息消费进度。在推模式下，如果是集群模式并且是
         * 顺序消息消费，还需要先解锁队列
         */
        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;
                    }
                }
            }
        }
    
        /**
         * 遍历本次负载分配到的队列集合，如果
         * processQueueTable中没有包含该消息队列，表明这是本次新增加的消
         * 息队列，首先从内存中移除该消息队列的消费进度，然后从磁盘中读
         * 取该消息队列的消费进度，创建PullRequest对象。这里有一个关键，
         * 如果读取到的消费进度小于0，则需要校对消费进度。RocketMQ提供了
         * CONSUME_FROM_LAST_OFFSET、CONSUME_FROM_FIRST_OFFSET、
         * CONSUME_FROM_TIMESTAMP方式，在创建消费者时可以通过调用
         * DefaultMQPushConsumer#setConsumeFromWhere方法进行设置
         */
        List<PullRequest> pullRequestList = new ArrayList<PullRequest>();
        for (MessageQueue mq : mqSet) {
            if (!this.processQueueTable.containsKey(mq)) {
    
                /**
                 * 经过消息队列重新负载（分配）后，分配到新的消息队列时，首
                 * 先需要尝试向Broker发起锁定该消息队列的请求，如果返回加锁成
                 * 功，则创建该消息队列的拉取任务，否则跳过，等待其他消费者释放
                 * 该消息队列的锁，然后在下一次队列重新负载时再尝试加锁
                 */
                // 顺序消息
                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();
                // todo PullRequest的nextOffset计算逻辑位于RebalancePushImpl#computePullFromWhere
                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 {
                        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);
                }
            }
        }
    
        // todo 将PullRequest加入PullMessageService，以便唤醒PullMessageService线程
        this.dispatchPullRequest(pullRequestList);
    
        return changed;
    }
    复制代码

1.  先将分配到的`消息队列集合`（mqSet）与`processQueueTable`做一个过滤比对

![format_png 1][]

*  上图中`processQueueTable`标注的红色部分，表示与分配到的消息队列集合mqSet互不包含。将这些队列设置`dropped`属性为true，然后查看这些队列是否可以移除出`processQueueTable`缓存变量，这里具体执行`removeUnnecessaryMessageQueue()`方法。
 *  上图中`processQueueTable`的绿色部分，表示与分配到的消息队列集合mqSet的交集。判断该`ProcessQueue`是否已经过期了，在Pull模式的不用管，如果是Push模式的，设置`dropped`属性为true，并且调用`removeUnnecessaryMessageQueue()`方法，像上面一样尝试移除Entry。

> `dropped`属性很重要，后面讲重复消费消费暂停都会提到它。

1.  为过滤后的消息队列集合（`mqSet`）中的每个`MessageQueue`创建一个`ProcessQueue`对象并存入`RebalanceImpl`的`processQueueTable`队列中（其中调用`RebalanceImpl`实例的`computePullFromWhere(MessageQueue mq)`方法获取该`MessageQueue`对象的下一个进度消费值offset，随后填充至接下来要创建的`pullRequest`对象属性中），并创建拉取请求对象—`pullRequest`添加到拉取列表—`pullRequestList`中，最后执行`dispatchPullRequest()`方法，将Pull消息的请求对象`PullRequest`依次放入`PullMessageServic`e服务线程的阻塞队列`pullRequestQueue`中，待该服务线程取出后向Broker端发起`Pull`消息的请求。

> 消息消费队列在同一消费组不同消费者之间的负载均衡，其核心设计理念是在`一个消息消费队列在同一时间只允许被同一消费组内的一个消费者消费`，一个消息消费者能同时消费多个消息队列

关于上面的核心逻辑方法我在举个栗子：假设有两个消费者c1,c2； 队列默认是4个。  
**消费者c1第一次重平衡：**

1.  消费者c1先启动，由于只有一个消费者，所以分配给c1的队列是4个(mqSet.size()=4)；
2.  然后开始处理重平衡逻辑，第一次进来 `processQueueTable`肯定是empty的，所以先跳过遍历逻辑。
3.  遍历分配到的mqSet集合（遍历4次）

*  创建`ProcessQueue`对象
 *  读取当前`MessageQueue`的偏移量,去broker中读取
 *  将当前`MessageQueue`和`ProcessQueue` 放入`processQueueTable`中
 *  创建`PullRequest`对象，设置队列`MessageQueue`，缓存消息队列`ProcessQueue`，以及当前`MessageQueue`的偏移量，然后放入`pullRequestList`集合中

1.  然后分发`pullRequestList`，将拉取消息的请求对象`PullRequest`依次放入`PullMessageService`服务线程的阻塞队列`pullRequestQueue`中，待该服务线程取出后向Broker端发起拉取消息的请求。

**消费者c2重平衡：**

1.  消费者c2启动，先不关注它重平衡的逻辑，就假设它分配了2个队列

**消费者c1第二次重平衡**

1.  消费者c1再次重平衡，经过平均分配算法后，c1也分配了2个queue(因为c2分配了2个，他们平均分),所以mqSet.size()=2
2.  然后开始处理重平衡逻辑,由于消费者c1第一次重平衡时，`processQueueTable`已经放入了4个`queue(MessageQueue)`,所以这里开始遍历。如果`mqSet`(这里是2个)**不包含**当前entry的key(MessageQueue)，则：

*  将当前entry中的`ProcessQueue`的属性 `dropped` 设置为true.
 *  从`RemoteBrokerOffsetStore#offsetTable`属性中，移除当前queue(MessageQueue).因为这个队列已经部署了c1了。
 *  将当前entry从`processQueueTable`中移除

1.  这样遍历完，`processQueueTable` 还剩下两个entry（这两个entry的key是在mqSet集合中的)
2.  继续遍历mqSet(2个queue),但是继续判断(!`processQueueTable.containsKey(mq)`),这里肯定是false,因为前面分析过了，它是还剩下2个MessageQueue,所以跳过if,最终装`PullRequest`的容器集合是empty的,所以就没有以后了。。。。 不难发现，c1在第2次重平衡后，并没有构建全新的`pullRequestList`，所以`dispatchPullRequest(pullRequestList)`方法内部不会做任何逻辑。这样c1还是有4个`PullRequest`, 那么第2次重平衡好像就没有什么用处了？
    
     *  不是的，这就是前面提到的一个`非常重要的属性设置`**dropped=true**
     *  在拉取消息时，首先就会判断这个属性
    
        public void pullMessage(final PullRequest pullRequest) {
            final ProcessQueue processQueue = pullRequest.getProcessQueue();
            //TODO:如果是dropped=true,则本次拉取请求直接丢弃，不会在将PullRequest放回阻塞队列中
            if (processQueue.isDropped()) {
                log.info("the pull request[{}] is dropped.", pullRequest.toString());
                return;
            }
        
            //TODO:.......
        }    
        复制代码

> 如果是`dropped=true`,则本次拉取请求直接丢弃，不会在将`PullRequest`放回阻塞队列中,这样c1就只消费2个队列了。所以在消息拉取之前，首先判断该队列是否被丢弃，如果已丢弃，则直接放弃本次拉取任务。

## 5.重平衡导致的重复消费 ##

我们直接看消费相关的代码：

> `ConsumeMessageConcurrentlyService`

public void run() {
        /**
         * 先检查processQueue的dropped，如果设置为true，则停止该队列的消费。在进行消息重新负
         * 载时，如果该消息队列被分配给消费组内的其他消费者，需要将
         * droped设置为true，阻止消费者继续消费不属于自己的消息队列
         */
        if (this.processQueue.isDropped()) {
            log.info("the message queue not be able to consume, because it's dropped. group={} {}", ConsumeMessageConcurrentlyService.this.consumerGroup, this.messageQueue);
            return;
        }
    
        // 取出消息监听器 获取消息监听器MessageListenerConcurrently
        MessageListenerConcurrently listener = ConsumeMessageConcurrentlyService.this.messageListener;
        ConsumeConcurrentlyContext context = new ConsumeConcurrentlyContext(messageQueue);
        ConsumeConcurrentlyStatus status = null;
        /**
         * 恢复重试消息主题名。这是为什么呢？这是由消息重试
         * 机制决定的，RocketMQ将消息存入CommitLog文件时，如果发现消息的
         * 延时级别delayTimeLevel大于0，会先将重试主题存入消息的属性，然
         * 后将主题名称设置为SCHEDULE_TOPIC_XXXX，以便之后重新参与消息消
         * 费
         */
        defaultMQPushConsumerImpl.resetRetryAndNamespace(msgs, defaultMQPushConsumer.getConsumerGroup());
    
        ...
        try {
            ...
            // todo 执行具体的消息消费，调用应用程序消息监听器的
            //consumeMessage方法，进入具体的消息消费业务逻辑，返回该批消息
            //的消费结果，即CONSUME_SUCCESS（消费成功）或
            //RECONSUME_LATER（需要重新消费）
            status = listener.consumeMessage(Collections.unmodifiableList(msgs), context);
        } 
        ...
        
        ...
    
        /**
         * 执行业务消息消费后，在处理结果前再次验证一次
         * ProcessQueue的isDropped状态值。如果状态值为true，将不对结果进
         * 行任何处理。也就是说，在消息消费进入第四步时，如果因新的消费
         * 者加入或原先的消费者出现宕机，导致原先分配给消费者的队列在负
         * 载之后分配给了别的消费者，那么消息会被重复消费
         */
        if (!processQueue.isDropped()) {
            // todo
            ConsumeMessageConcurrentlyService.this.processConsumeResult(status, context, this);
        } else {
            log.warn("processQueue is dropped without process consume result. messageQueue={}, msgs={}", messageQueue, msgs);
        }
    }
    复制代码

而导致重复消费的就是在处理消费结果这里：

//TODO:可能会导致重复消费
    if (!processQueue.isDropped()) {
        ConsumeMessageConcurrentlyService.this.processConsumeResult(status, context, this);
    } else {
        log.warn("processQueue is dropped without process consume result. messageQueue={}, msgs={}", messageQueue, msgs);
    }
    复制代码

因为走到这里，`说明消费者已经消费完了`，但是可能由于重平衡可能导致我现在正消费的队列`dropped=true`，所以它不会去处理消费结果，而`不处理消费结果就是不会去更新消费偏移量`，这样同一个消费者组里的其他消费者可能还会消费到这条消息。这样就产生了重复消费。

> 注意：一条消息，被同一个消费者组里的不同消费者都消费过，这也是重复消费。

## 6. Rebalance的触发 ##

### 6.1 消费者启动时触发 ###

在文章开头已经讲过，消费者在启动时会进行一次负载均衡，这里便不再赘述。

### 6.2 消费者变更时触发 ###

在消费者注册时讲到，如果发现消费者有变更会触发变更事件，当处于以下两种情况之一时会被判断为消费者发生了变化，需要进行负载均衡：

*  当前注册的消费者对应的`Channel`对象之前不存在；
 *  当前注册的消费者订阅的主题信息发生了变化，也就是`消费者订阅的主题有新增或者删除`；

public class ConsumerManager {
        
        /**
         *  注册消费者
         * @param group 消费者组名称
         * @param clientChannelInfo 注册的消费者对应的Channel信息
         * @param consumeType 消费类型
         * @param messageModel 
         * @param consumeFromWhere 消费消息的位置
         * @param subList 消费者订阅的主题信息
         * @param isNotifyConsumerIdsChangedEnable 是否通知变更
         * @return
         */
        public boolean registerConsumer(final String group, final ClientChannelInfo clientChannelInfo,
            ConsumeType consumeType, MessageModel messageModel, ConsumeFromWhere consumeFromWhere,
            final Set<SubscriptionData> subList, boolean isNotifyConsumerIdsChangedEnable) {
            // 根据组名称获取消费者组信息
            ConsumerGroupInfo consumerGroupInfo = this.consumerTable.get(group);
            if (null == consumerGroupInfo) { // 如果为空新增
                ConsumerGroupInfo tmp = new ConsumerGroupInfo(group, consumeType, messageModel, consumeFromWhere);
                ConsumerGroupInfo prev = this.consumerTable.putIfAbsent(group, tmp);
                consumerGroupInfo = prev != null ? prev : tmp;
            }
            // 更新Channel
            boolean r1 =
                consumerGroupInfo.updateChannel(clientChannelInfo, consumeType, messageModel,
                    consumeFromWhere);
            // 更新订阅信息
            boolean r2 = consumerGroupInfo.updateSubscription(subList);
            // 如果有变更
            if (r1 || r2) {
                if (isNotifyConsumerIdsChangedEnable) {
                    // 通知变更，consumerGroupInfo中存储了该消费者组下的所有消费者的channel
                    this.consumerIdsChangeListener.handle(ConsumerGroupEvent.CHANGE, group, consumerGroupInfo.getAllChannel());
                }
            }
            // 注册Consumer
            this.consumerIdsChangeListener.handle(ConsumerGroupEvent.REGISTER, group, subList);
            return r1 || r2;
        }
    }
    复制代码

#### 6.2.1 Channel变更 ####

在`updateChannel`方法中，首先将变更状态`updated`初始化为false，然后根据消费者的channel从`channelInfoTable`路由表中获取对应的`ClientChannelInfo`对象：

*  如果`ClientChannelInfo`对象获取为空，表示之前不存在该消费者的channel信息，将其加入到路由表中，变更状态置为true，表示消费者有变化；
 *  如果获取不为空，判断clientid是否一致，如果不一致更新为最新的channel信息，但是变更状态`updated`不发生变化；

也就是说，**如果注册的消费者之前不存在，那么将变更状态置为true，表示消费者数量发生了变化。**

// key为消费者对应的channle，value为chanel信息
       private final ConcurrentMap<Channel, ClientChannelInfo> channelInfoTable =
            new ConcurrentHashMap<Channel, ClientChannelInfo>(16);
            
       public boolean updateChannel(final ClientChannelInfo infoNew, ConsumeType consumeType,
            MessageModel messageModel, ConsumeFromWhere consumeFromWhere) {
            boolean updated = false; // 变更状态初始化为false
            this.consumeType = consumeType;
            this.messageModel = messageModel;
            this.consumeFromWhere = consumeFromWhere;
            // 从channelInfoTable中获取对应的Channel信息, 
            ClientChannelInfo infoOld = this.channelInfoTable.get(infoNew.getChannel());
            if (null == infoOld) { // 如果为空
                // 新增
                ClientChannelInfo prev = this.channelInfoTable.put(infoNew.getChannel(), infoNew);
                if (null == prev) { // 如果之前不存在
                    log.info("new consumer connected, group: {} {} {} channel: {}", this.groupName, consumeType,
                        messageModel, infoNew.toString());
                    // 变更状态置为true
                    updated = true;
                }
                infoOld = infoNew;
            } else {
                // 如果之前存在，判断clientid是否一致，如果不一致更新为最新的channel
                if (!infoOld.getClientId().equals(infoNew.getClientId())) { 
                    log.error("[BUG] consumer channel exist in broker, but clientId not equal. GROUP: {} OLD: {} NEW: {} ", this.groupName, infoOld.toString(), infoNew.toString());
                    this.channelInfoTable.put(infoNew.getChannel(), infoNew);
                }
            }
            this.lastUpdateTimestamp = System.currentTimeMillis();
            infoOld.setLastUpdateTimestamp(this.lastUpdateTimestamp);
            return updated;
        }
    复制代码

#### 6.2.2 主题信息订阅变更 ####

`updateSubscription`方法中，主要`判断了消费的主题订阅信息是否发生了变化`，`subscriptionTable`中记录了之前记录的订阅信息：

1.  判断是否有新增的主题订阅信息，主要是通过`subscriptionTable`是否存在某个主题进行判断的：
    
     *  如果不存在，表示之前没有订阅过某个主题的信息，将其加入到`subscriptionTable`中，并将变更状态置为true，表示主题订阅信息有变化；
     *  如果`subscriptionTable`中存在某个主题的订阅信息，表示之前就已订阅，将其更新为最新的，但是变更状态不发生变化；
2.  判断是否有删除的主题，主要是通过`subscriptionTable`和`subList`的对比进行判断的，如果有删除的主题，将变更状态置为true；

**如果消费者订阅的主题发生了变化，比如有新增加的主题或者删除了某个主题的订阅，会被判断为主题订阅信息发生了变化。**

public class ConsumerGroupInfo {
        // 记录了订阅的主题信息，key为topic，value为订阅信息
        private final ConcurrentMap<String/* Topic */, SubscriptionData> subscriptionTable =
            new ConcurrentHashMap<String, SubscriptionData>();   
        
        
        public boolean updateSubscription(final Set<SubscriptionData> subList) {
            boolean updated = false;
            // 遍历订阅的主题信息
            for (SubscriptionData sub : subList) {
                //根据主题获取订阅信息
                SubscriptionData old = this.subscriptionTable.get(sub.getTopic());
                // 如果获取为空
                if (old == null) {
                    // 加入到subscriptionTable
                    SubscriptionData prev = this.subscriptionTable.putIfAbsent(sub.getTopic(), sub);
                    if (null == prev) {
                        updated = true; // 变更状态置为true
                        log.info("subscription changed, add new topic, group: {} {}", this.groupName, sub.toString());
                    }
                } else if (sub.getSubVersion() > old.getSubVersion()) { // 如果版本发生了变化
                    if (this.consumeType == ConsumeType.CONSUME_PASSIVELY) {
                        log.info("subscription changed, group: {} OLD: {} NEW: {}", this.groupName, old.toString(), sub.toString());
                    }
                    // 更新为最新的订阅信息
                    this.subscriptionTable.put(sub.getTopic(), sub);
                }
            }
            Iterator<Entry<String, SubscriptionData>> it = this.subscriptionTable.entrySet().iterator();
            // 进行遍历，这一步主要是判断有没有取消订阅的主题
            while (it.hasNext()) {
                Entry<String, SubscriptionData> next = it.next();
                String oldTopic = next.getKey();
                boolean exist = false;
                // 遍历最新的订阅信息
                for (SubscriptionData sub : subList) {
                    // 如果在旧的订阅信息中存在就终止，继续判断下一个主题
                    if (sub.getTopic().equals(oldTopic)) {
                        exist = true;
                        break;
                    }
                }
                // 走到这里，表示有取消订阅的主题
                if (!exist) {
                    log.warn("subscription changed, group: {} remove topic {} {}",this.groupName, oldTopic, next.getValue().toString());
                    // 进行删除
                    it.remove();
                    // 变更状态置为true
                    updated = true;
                }
            }
            this.lastUpdateTimestamp = System.currentTimeMillis();
            return updated;
        }
    }
    复制代码

#### 6.2.3 变更请求发送 ####

上面讲解了两种被判定为消费者发生变化的情况，被判定为变化之后，会触调用`DefaultConsumerIdsChangeListener`中的`handle`方法触发变更事件，在方法中传入了消费者组下的所有消费者的channel对象，会发送变更请求通知该消费者组下的所有消费者，进行负载均衡。

`DefaultConsumerIdsChangeListener`中处理变更事件时，会对消费组下的所有消费者遍历，调用`notifyConsumerIdsChanged`方法向每一个消费者发送变更请求:

public class ConsumerManager {
       
        public boolean registerConsumer(final String group, final ClientChannelInfo clientChannelInfo,
            ConsumeType consumeType, MessageModel messageModel, ConsumeFromWhere consumeFromWhere,
            final Set<SubscriptionData> subList, boolean isNotifyConsumerIdsChangedEnable) {
            // ...
            // 更新Channel
            boolean r1 =
                consumerGroupInfo.updateChannel(clientChannelInfo, consumeType, messageModel,
                    consumeFromWhere);
            // 更新订阅信息
            boolean r2 = consumerGroupInfo.updateSubscription(subList);
            // 如果有变更
            if (r1 || r2) {
                if (isNotifyConsumerIdsChangedEnable) {
                    // 触发变更事件，consumerGroupInfo中存储了该消费者组下的所有消费者的channel
                    this.consumerIdsChangeListener.handle(ConsumerGroupEvent.CHANGE, group, consumerGroupInfo.getAllChannel());
                }
            }
            // ...
        }
    }
    
    // DefaultConsumerIdsChangeListener
    public class DefaultConsumerIdsChangeListener implements ConsumerIdsChangeListener {
        @Override
        public void handle(ConsumerGroupEvent event, String group, Object... args) {
            if (event == null) {
                return;
            }
            switch (event) {
                case CHANGE:// 如果是消费者变更事件
                    case CHANGE:
                    if (args == null || args.length < 1) {
                        return;
                    }
                    // 获取所有的消费者对应的channel
                    List<Channel> channels = (List<Channel>) args[0];
                    if (channels != null && brokerController.getBrokerConfig().isNotifyConsumerIdsChangedEnable()) {
                        for (Channel chl : channels) {
                            // 向每一个消费者发送变更请求
                            this.brokerController.getBroker2Client().notifyConsumerIdsChanged(chl, group);
                        }
                    }
                    break;
                 // ...
            }
        }
    }
    复制代码

请求的发送是在`Broker2Client`的`notifyConsumerIdsChanged`方法中实现的，可以看到会创建`NOTIFY_CONSUMER_IDS_CHANGED`请求并发送：

public class Broker2Client {
        public void notifyConsumerIdsChanged(
            final Channel channel,
            final String consumerGroup) {
            if (null == consumerGroup) {
                log.error("notifyConsumerIdsChanged consumerGroup is null");
                return;
            }
            NotifyConsumerIdsChangedRequestHeader requestHeader = new NotifyConsumerIdsChangedRequestHeader();
            requestHeader.setConsumerGroup(consumerGroup);
            // 创建变更通知请求
            RemotingCommand request =
                RemotingCommand.createRequestCommand(RequestCode.NOTIFY_CONSUMER_IDS_CHANGED, requestHeader);
            try {
                // 发送请求
                this.brokerController.getRemotingServer().invokeOneway(channel, request, 10);
            } catch (Exception e) {
                log.error("notifyConsumerIdsChanged exception. group={}, error={}", consumerGroup, e.toString());
            }
        }
    }
    复制代码

#### 6.2.4 变更通知请求处理 ####

消费者对Broker发送的`NOTIFY_CONSUMER_IDS_CHANGED`的请求处理在`ClientRemotingProcessor`的`processRequest`方法中，它会调用`notifyConsumerIdsChanged`方法进行处理，在`notifyConsumerIdsChanged`方法中可以看到触发了一次负载均衡：

public class ClientRemotingProcessor extends AsyncNettyRequestProcessor implements NettyRequestProcessor {
        
        @Override
        public RemotingCommand processRequest(ChannelHandlerContext ctx,
            RemotingCommand request) throws RemotingCommandException {
            switch (request.getCode()) {
                case RequestCode.CHECK_TRANSACTION_STATE:
                    return this.checkTransactionState(ctx, request);
                case RequestCode.NOTIFY_CONSUMER_IDS_CHANGED: // NOTIFY_CONSUMER_IDS_CHANGED请求处理
                    // 处理变更请求
                    return this.notifyConsumerIdsChanged(ctx, request); 
                // ...
                default:
                    break;
            }
            return null;
        }
        
        public RemotingCommand notifyConsumerIdsChanged(ChannelHandlerContext ctx,
            RemotingCommand request) throws RemotingCommandException {
            try {
                // ...
                // 触发负载均衡
                this.mqClientFactory.rebalanceImmediately();
            } catch (Exception e) {
                log.error("notifyConsumerIdsChanged exception", RemotingHelper.exceptionSimpleDesc(e));
            }
            return null;
        }
    }
    复制代码

### 6.3 消费者停止时触发 ###

消费者在停止时，需要将当前消费者负责的消息队列分配给其他消费者进行消费，所以在`shutdown`方法中会调用`MQClientInstance`的`unregisterConsumer`方法取消注册：

public class DefaultMQPushConsumerImpl implements MQConsumerInner {
       public synchronized void shutdown(long awaitTerminateMillis) {
            switch (this.serviceState) {
                case CREATE_JUST:
                    break;
                case RUNNING:
                    this.consumeMessageService.shutdown(awaitTerminateMillis);
                    this.persistConsumerOffset();
                    // 取消注册
                    this.mQClientFactory.unregisterConsumer(this.defaultMQPushConsumer.getConsumerGroup());
                    this.mQClientFactory.shutdown();
                    // ...
                    break;
                case SHUTDOWN_ALREADY:
                    break;
                default:
                    break;
            }
        }
    }
    复制代码

在`unregisterConsumer`方法中，又调用了`unregisterClient`方法取消注册，与注册消费者的逻辑相似，它会向所有的Broker发送取消注册的请求：

public class MQClientInstance {
        public synchronized void unregisterConsumer(final String group) {
            this.consumerTable.remove(group);
            // 取消注册
            this.unregisterClient(null, group);
        }
        
        private void unregisterClient(final String producerGroup, final String consumerGroup) {
            // 获取所有的Broker
            Iterator<Entry<String, HashMap<Long, String>>> it = this.brokerAddrTable.entrySet().iterator();
            // 进行遍历
            while (it.hasNext()) {
                // ...
                if (oneTable != null) {
                    for (Map.Entry<Long, String> entry1 : oneTable.entrySet()) {
                        String addr = entry1.getValue();
                        if (addr != null) {
                            try {
                                // 发送取消注册请求
                                this.mQClientAPIImpl.unregisterClient(addr, this.clientId, producerGroup, consumerGroup, clientConfig.getMqClientApiTimeout());
                                // ...
                            } // ...
                        }
                    }
                }
            }
        }
    }
    复制代码

取消注册请求的发送是在`MQClientAPIImpl`中`unregisterClient`方法实现的，可以看到构建了`UNREGISTER_CLIENT`请求并发送：

public class MQClientAPIImpl { 
        public void unregisterClient(final String addr, final String clientID, final String producerGroup,  final String consumerGroup, final long timeoutMillis) throws RemotingException, MQBrokerException, InterruptedException {
            // ...
            requestHeader.setConsumerGroup(consumerGroup);
            // 构建UNREGISTER_CLIENT请求
            RemotingCommand request = RemotingCommand.createRequestCommand(RequestCode.UNREGISTER_CLIENT, requestHeader);
            // 发送请求
            RemotingCommand response = this.remotingClient.invokeSync(addr, request, timeoutMillis);
            // ...
        }
    }
    复制代码

与注册消费者的请求处理一样，Broker对`UNREGISTER_CLIENT`的请求同样是在`ClientManageProcessor`的`processRequest`中处理的，对于`UNREGISTER_CLIENT`请求是调用unregisterClient方法处理的，里面又调用了`ConsumerManager`的`unregisterConsumer`方法进行取消注册：

public class ClientManageProcessor extends AsyncNettyRequestProcessor implements NettyRequestProcessor {
        @Override
        public RemotingCommand processRequest(ChannelHandlerContext ctx, RemotingCommand request)
            throws RemotingCommandException {
            switch (request.getCode()) {
                case RequestCode.HEART_BEAT: // 处理心跳请求
                    return this.heartBeat(ctx, request);
                case RequestCode.UNREGISTER_CLIENT: // 取消注册请求
                    return this.unregisterClient(ctx, request);
                case RequestCode.CHECK_CLIENT_CONFIG:
                    return this.checkClientConfig(ctx, request);
                default:
                    break;
            }
            return null;
        }
        
        public RemotingCommand unregisterClient(ChannelHandlerContext ctx, RemotingCommand request)
            throws RemotingCommandException {
            // ...
            {
                final String group = requestHeader.getConsumerGroup();
                if (group != null) {
                    // ...
                    // 取消消费者的注册
                    this.brokerController.getConsumerManager().unregisterConsumer(group, clientChannelInfo, isNotifyConsumerIdsChangedEnable);
                }
            }
            response.setCode(ResponseCode.SUCCESS);
            response.setRemark(null);
            return response;
        }
    }
    复制代码

在`ConsumerManager`的`unregisterConsumer`方法中，可以看到触发了取消注册事件，之后如果开启了允许通知变更，会触发变更事件，变更事件在上面已经讲解过，它会通知消费者组下的所有消费者进行一次负载均衡：

public class ConsumerManager {    
        public void unregisterConsumer(final String group, final ClientChannelInfo clientChannelInfo,
            boolean isNotifyConsumerIdsChangedEnable) {
            ConsumerGroupInfo consumerGroupInfo = this.consumerTable.get(group);
            if (null != consumerGroupInfo) {
                consumerGroupInfo.unregisterChannel(clientChannelInfo);
                if (consumerGroupInfo.getChannelInfoTable().isEmpty()) {
                    ConsumerGroupInfo remove = this.consumerTable.remove(group);
                    if (remove != null) {
                        // 触发取消注册事件
                        this.consumerIdsChangeListener.handle(ConsumerGroupEvent.UNREGISTER, group);
                    }
                }
                // 触发消费者变更事件
                if (isNotifyConsumerIdsChangedEnable) {
                    this.consumerIdsChangeListener.handle(ConsumerGroupEvent.CHANGE, group, consumerGroupInfo.getAllChannel());
                }
            }
        }
    }
    复制代码

### 6.4 消费者定时触发 ###

在`RebalanceService`的run方法中，可以看到设置了等待时间，`默认是20s`，所以消费者本身也会定时执行负载均衡：

public class RebalanceService extends ServiceThread {
        private static long waitInterval = Long.parseLong(System.getProperty("rocketmq.client.rebalance.waitInterval", "20000"));
      
        @Override
        public void run() {
            log.info(this.getServiceName() + " service started");
            while (!this.isStopped()) {
                this.waitForRunning(waitInterval); // 等待
                // 负载均衡
                this.mqClientFactory.doRebalance();
            }
            log.info(this.getServiceName() + " service end");
        }
    }
    复制代码

## 7.总结 ##

本文主要是从源码角度分析了`RocketMQ`的重平衡过程，也分析了产生重复消费的原因。简单总结下：

1.  queue的分配算法
2.  重平衡的代码分析
3.  重复消费产生的原因
4.  `Rebalance`的触发时机

作者：hsfxuebao  
链接：https://juejin.cn/post/7220380791510040635

[Consumer]: https://link.juejin.cn?target=
[format_png]: https://img-blog.csdnimg.cn/img_convert/db0084cd776aa13fc1cc0e6598662bb0.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/bb6bce4b86dbd3ee3b29dc5bab18fa53.webp?x-oss-process=image/format,png