RocketMQ原理—3.源码设计简单分析下

大纲

1.Producer作为生产者是如何创建出来的

2.Producer启动时是如何准备好相关资源的

3.Producer是如何从拉取Topic元数据的

4.Producer是如何选择MessageQueue的

5.Producer与Broker是如何进行网络通信的

6.Broker收到一条消息后是如何存储的

7.Broker是如何实时更新索引文件的

8.Broker是如何实现同步刷盘以及异步刷盘的

9.Broker是如何清理存储较久的磁盘数据的

10.Consumer作为消费者是如何创建和启动的

11.消费者组的多个Consumer会如何分配消息

12.Consumer会如何从Broker拉取一批消息

1.Producer作为生产者是如何创建出来的

(1)NameServer的启动

(2)Broker的启动

(3)Broker的注册和心跳

(4)通过Producer发送消息

(1)NameServer的启动

NameServer启动后的核心架构，如下图示：

NameServer启动后，会有一个NamesrvController组件管理控制NameServer的所有行为，包括内部会启动一个Netty服务器去监听一个9876端口号，然后接收处理Broker和客户端发送过来的请求。

(2)Broker的启动

Broker启动后的核心架构，如下图示：

Broker启动后，也会有一个BrokerController组件管理控制Broker的整体行为，包括初始化Netty服务器用于接收客户端的网络请求、启动处理请求的线程池、执行定时任务的线程池、初始化核心功能组件，同时还会发送注册请求到NameServer去注册自己。

(3)Broker的注册和心跳

Broker启动后，会向NameServer进行注册和定时发送注册请求作为心跳。NameServer会有一个后台进程定时检查每个Broker的最近一次心跳时间，如果长时间没心跳就认为Broker已经故障。如下图示：

(4)通过Producer发送消息

假设RocketMQ集群已经启动好了NameServer，而且还启动了一批Broker，同时Broker都已经把自己注册到NameServer里去了，NameServer也会定时检查这批Broker是否存活。那么就可以让开发好的业务系统去发送消息到RocketMQ集群里，于是需要创建一个Producer实例。

实际上我们开发好的系统，最终都需要创建一个Producer实例，然后通过Producer实例发送消息到RocketMQ的Broker上去。

下面是使用Producer实例发送消息到RocketMQ的代码，可以看到Producer是如何构造出来的。

DefaultMQProducer producer = new DefaultMQProducer("order_producer_group");
producer.setNamesrvAddr("localhost:9876");
producer.start();

构造Producer的过程很简单：也就是创建一个DefaultMQProducer对象实例。在构造方法中，首先会传入所属的Producer分组，然后设置一下NameServer的地址，最后调用它的start()方法启动这个Producer即可。

创建DefaultMQProducer对象实例是一个非常简单的过程：就是创建出一个对象，然后保存它的Producer分组。设置NameServer地址也是一个很简单的过程，就是保存一下NameServer地址。

所以，最关键的还是调用DefaultMQProducer的start()方法去启动Producer这个消息生产者。

2.Producer启动时是如何准备好相关资源的

(1)DefaultMQProducer的start()方法

(2)Producer在第一次向Topic发送消息时才拉取Topic的路由数据

(3)Producer在第一次向Broker发送消息时才与Broker建立网络连接

(1)DefaultMQProducer的start()方法

接下来分析Producer在启动时是如何准备好相关资源的。Producer内部必须要有独立的线程资源，以及需要和Broker已经建立好网络连接，这样才能把消息发送出去。

在构造Producer时，它内部便会构造一个真正用于执行消息发送逻辑的DefaultMQProducerImpl组件。所以，真正的Producer生产者其实是这个DefaultMQProducerImpl组件。那么这个组件在启动的时都干了什么呢？

public class DefaultMQProducer extends ClientConfig implements MQProducer {
    protected final transient DefaultMQProducerImpl defaultMQProducerImpl;
    ...
    @Override
    public void start() throws MQClientException {
        this.setProducerGroup(withNamespace(this.producerGroup));
        this.defaultMQProducerImpl.start();
        if (null != traceDispatcher) {
            try {
                traceDispatcher.start(this.getNamesrvAddr(), this.getAccessChannel());
            } catch (MQClientException e) {
                log.warn("trace dispatcher start failed ", e);
            }
        }
    }
    ...
}

public class DefaultMQProducerImpl implements MQProducerInner {
    ...
    public void start() throws MQClientException {
        this.start(true);
    }

    public void start(final boolean startFactory) throws MQClientException {
        switch (this.serviceState) {
            case CREATE_JUST:
                this.serviceState = ServiceState.START_FAILED;
                this.checkConfig();
                if (!this.defaultMQProducer.getProducerGroup().equals(MixAll.CLIENT_INNER_PRODUCER_GROUP)) {
                    this.defaultMQProducer.changeInstanceNameToPID();
                }
                this.mQClientFactory = MQClientManager.getInstance().getOrCreateMQClientInstance(this.defaultMQProducer, rpcHook);

                boolean registerOK = mQClientFactory.registerProducer(this.defaultMQProducer.getProducerGroup(), this);
                if (!registerOK) {
                    this.serviceState = ServiceState.CREATE_JUST;
                    throw new MQClientException("The producer group[" + this.defaultMQProducer.getProducerGroup() + "] has been created before, specify another name please." + FAQUrl.suggestTodo(FAQUrl.GROUP_NAME_DUPLICATE_URL), null);
                }
                this.topicPublishInfoTable.put(this.defaultMQProducer.getCreateTopicKey(), new TopicPublishInfo());
                if (startFactory) {
                    mQClientFactory.start();
                }

                log.info("the producer [{}] start OK. sendMessageWithVIPChannel={}", this.defaultMQProducer.getProducerGroup(), this.defaultMQProducer.isSendMessageWithVIPChannel());
                this.serviceState = ServiceState.RUNNING;
                break;
            case RUNNING:
            case START_FAILED:
            case SHUTDOWN_ALREADY:
                throw new MQClientException("The producer service state not OK, maybe started once, " + this.serviceState + FAQUrl.suggestTodo(FAQUrl.CLIENT_SERVICE_NOT_OK), null);
            default:
                break;
        }
        this.mQClientFactory.sendHeartbeatToAllBrokerWithLock();
        this.startScheduledTask();
    }
    ...
}

其实，上述start()方法的具体逻辑暂时不需要深入分析，因为其中的逻辑并没有直接与Producer发送消息相关联。比如拉取Topic的路由数据、选择MessageQueue、跟Broker建立长连接、发送消息到Broker等这些核心逻辑，其实都封装在发送消息的方法中。

(2)Producer在第一次向Topic发送消息时才拉取Topic的路由数据

假设后续Producer要发送消息，那么就要指定往哪个Topic发送消息。因此Producer需要知道Topic的路由数据，比如Topic有哪些MessageQueue，每个MessageQueue在哪些Broker上。如下图示：

从start()方法源码可知，在Producer启动时，并不会去拉取Topic的路由数据。实际上，Producer在第一次向Topic发送消息时，才会去拉取Topic的路由数据。包括这个Topic有几个MessageQueue、每个MessageQueue在哪个Broker上。然后从中选择一个MessageQueue，接着与对应的Broker建立网络连接，最后才把消息发送过去。

(3)Producer在第一次向Broker发送消息时才与Broker建立网络连接

从start()方法源码可知，在Producer启动时，并不会和所有Broker建立网络连接。很多核心的逻辑，包括拉取Topic路由数据、选择MessageQueue、和Broker建立网络连接等，都是在Producer第一次发送消息时才进行处理的。

3.Producer是如何从拉取Topic元数据的

(1)Producer发送消息的方法

(2)Producer拉取Topic路由数据的过程

(1)Producer发送消息的方法

当调用Producer的send()方法发送消息时，最终会调用到DefaultMQProducerImpl的sendDefaultImpl()方法。

在sendDefaultImpl()方法里，开始会有一行非常关键的代码，如下所示：

public class DefaultMQProducerImpl implements MQProducerInner {
    ...
    private SendResult sendDefaultImpl(Message msg, final CommunicationMode communicationMode, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException {
        ...
        TopicPublishInfo topicPublishInfo = this.tryToFindTopicPublishInfo(msg.getTopic());
        ...
    }
    ...
}

该行代码的意思是，每次Producer发送消息时，都会先检查一下要发送消息的那个Topic的路由数据是否在本地。如果不在，才会发送请求到NameServer去拉取Topic的路由数据，然后缓存在本地。

(2)Producer拉取Topic路由数据的过程

进入tryToFindTopicPublishInfo()方法，会发现其逻辑非常简单：就是会先检查一下自己本地是否有这个Topic的路由数据的缓存，如果没有就发送网络请求到NameServer去拉取，如果有就直接返回本地Topic路由数据缓存，如下图示：

那么Producer是如何发送网络请求到NameServer去拉取Topic路由数据的呢？这其实就对应了tryToFindTopicPublishInfo()方法内的一行代码，如下所示：

public class DefaultMQProducerImpl implements MQProducerInner {
    ...
    private TopicPublishInfo tryToFindTopicPublishInfo(final String topic) {
        TopicPublishInfo topicPublishInfo = this.topicPublishInfoTable.get(topic);
        if (null == topicPublishInfo || !topicPublishInfo.ok()) {
            this.topicPublishInfoTable.putIfAbsent(topic, new TopicPublishInfo());
            this.mQClientFactory.updateTopicRouteInfoFromNameServer(topic);
            topicPublishInfo = this.topicPublishInfoTable.get(topic);
        }

        if (topicPublishInfo.isHaveTopicRouterInfo() || topicPublishInfo.ok()) {
            return topicPublishInfo;
        } else {
            this.mQClientFactory.updateTopicRouteInfoFromNameServer(topic, true, this.defaultMQProducer);
            topicPublishInfo = this.topicPublishInfoTable.get(topic);
            return topicPublishInfo;
        }
    }
    ...
}

通过以下这行代码，Producer就可以从NameServer拉取某个Topic的路由数据，然后更新到自己本地的缓存里去。

this.mQClientFactory.updateTopicRouteInfoFromNameServer(topic);

Producer发送请求到NameServer的拉取Topic路由数据的过程：首先封装一个Request请求对象，然后通过Netty客户端发送请求到NameServer，接着会接收到NameServer返回的一个Response响应对象，于是就可以从Response响应对象里取出所需的Topic路由数据并更新到自己本地缓存里。更新时会做一些判断，比如Topic路由数据是否有改变过等，然后把Topic路由数据放入本地缓存。如下图示：

4.Producer是如何选择MessageQueue的

(1)Topic是由多个MessageQueue组成的

(2)选择MessageQueue的源码和算法

(1)Topic是由多个MessageQueue组成的

Producer发送消息时，会先检查一下要发送消息的Topic的路由数据是否在本地缓存。如果不在，就会通过底层的Netty网络通信模块发送一个请求到NameServer拉取Topic路由数据，然后缓存在Producer本地。当Producer拿到一个Topic的路由数据后，就应该选择要发送消息到这个Topic的哪一个MessageQueue上了。

因为Topic是一个逻辑上的概念，一个Topic的数据往往会分布式存储在多台Broker机器上，所以Topic本质是由多个MessageQueue组成的。

每个MessageQueue都可以在不同的Broker机器上，当然也可能一个Topic的多个MessageQueue在一个Broker机器上。如下图示：

只要Producer知道了要发送消息到哪个MessageQueue上去，其实就已经知道了这个MessageQueue在哪台Broker机器上，接着和该Broker机器建立连接，发送消息过去即可。

(2)选择MessageQueue的源码和算法

发送消息的源码在DefaultMQProducerImpl的sendDefaultImpl()方法中。该方法里只要Producer获取到Topic的路由数据，不管从本地缓存获取还是从NameServer拉取，就会执行下面的代码：

public class DefaultMQProducerImpl implements MQProducerInner {
    ...
    private SendResult sendDefaultImpl(Message msg, final CommunicationMode communicationMode, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException {
        ...
        MessageQueue mqSelected = this.selectOneMessageQueue(topicPublishInfo, lastBrokerName);
        ...
    }
    ...
}

selectOneMessageQueue()方法其实就是在选择Topic中的一个MessageQueue，然后发送消息到这个MessageQueue。下面是选择MessageQueue的算法：

public class MQFaultStrategy {
    ...
    public MessageQueue selectOneMessageQueue(final TopicPublishInfo tpInfo, final String lastBrokerName) {
        ...
        int index = tpInfo.getSendWhichQueue().incrementAndGet();
        for (int i = 0; i < tpInfo.getMessageQueueList().size(); i++) {
            int pos = Math.abs(index++) % tpInfo.getMessageQueueList().size();
            if (pos < 0) {
                pos = 0;
            }
            MessageQueue mq = tpInfo.getMessageQueueList().get(pos);
            if (latencyFaultTolerance.isAvailable(mq.getBrokerName())) {
                return mq;
            }
        }
        ...
    }
    ...
}

这是一种简单的负载均衡算法：首先获取一个自增长的Index，接着就用这个Index对Topic的MessageQueue列表进行取模运算，从而获取到一个MessageQueue列表的位置，最后返回这个位置的MessageQueue。

但是如果某个Broker故障了，那么就不能把消息发送到故障Broker的MessageQueue了。所以selectOneMessageQueue()方法里还有其他代码，用来实现Broker故障时的自动回避机制。

5.Producer与Broker是如何进行网络通信的

(1)Producer是如何把消息发送给Broker的

(2)Producer和Broker基于长连接进行通信

(1)Producer是如何把消息发送给Broker的

在DefaultMQProducerImpl.sendDefaultImpl()方法中，会先获取到MessageQueue所在的Broker名称，如下所示：

public class DefaultMQProducerImpl implements MQProducerInner {
    ...
    private SendResult sendDefaultImpl(Message msg, final CommunicationMode communicationMode, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException {
        ...
        MessageQueue mqSelected = this.selectOneMessageQueue(topicPublishInfo, lastBrokerName);
        if (mqSelected != null) {
            mq = mqSelected;
            brokersSent[times] = mq.getBrokerName();
            ...
        }
        ...
    }
    ...
}

获取到这个BrokerName后，就会调用sendKernelImpl()方法把消息发送到Broker上。

public class DefaultMQProducerImpl implements MQProducerInner {
    ...
    private SendResult sendDefaultImpl(Message msg, final CommunicationMode communicationMode, final SendCallback sendCallback, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException {
        ...
        sendResult = this.sendKernelImpl(msg, mq, communicationMode, sendCallback, topicPublishInfo, timeout - costTime);
        ...
    }

    private SendResult sendKernelImpl(final Message msg, final MessageQueue mq, final CommunicationMode communicationMode, final SendCallback sendCallback, final TopicPublishInfo topicPublishInfo, final long timeout) throws MQClientException, RemotingException, MQBrokerException, InterruptedException {
        long beginStartTime = System.currentTimeMillis();
        String brokerAddr = this.mQClientFactory.findBrokerAddressInPublish(mq.getBrokerName());
        if (null == brokerAddr) {
            tryToFindTopicPublishInfo(mq.getTopic());
            brokerAddr = this.mQClientFactory.findBrokerAddressInPublish(mq.getBrokerName());
        }
        ...
    }
    ...
}

在sendKernelImpl()方法中：

首先会通过BrokerName去本地缓存查找它的实际地址。如果找不到，就到NameServer中拉取Topic的路由数据，再次在本地缓存获取Broker的实际地址，有了这个地址才能进行网络通信。

然后会封装一个Request请求，包括请求头、发送的消息等，并且会给消息分配全局唯一ID，以及对超过4KB的消息体进行压缩。

在Request请求中，会包含生产者组、Topic名称、Topic的MessageQueue数量、MessageQueue的ID、消息发送时间、消息的flag、消息扩展属性、消息重试次数、是否批量发送等信息，如果是事务消息则带上prepared标记等。

把这些数据都封装到一个Request请求后，就会通过Netty把Request请求发送到指定的Broker上。

(2)Producer和Broker基于长连接进行通信

其中，Producer和Broker会通过Netty建立长连接，然后基于长连接进行持续通信。如下图示：

那么Broker上的Netty服务器接收到消息后，会如何进行处理？这个过程比较复杂，涉及到CommitLog、ConsumeQueue、IndexFile、Checkpoint等一系列机制，这也是RocketMQ中核心机制。

6.Broker收到一条消息后是如何存储的

(1)Broker收到消息后的处理流程

(2)Broker如何将消息写入CommitLog文件

(1)Broker收到消息后的处理流程

Broker中的Netty网络服务器获取到一条消息后：

首先，会把这条消息写入到一个CommitLog文件里。一个Broker机器上就只有一个CommitLog文件，所有Topic的消息都会写入到这个文件里。如下图示：

然后，Broker会以异步的方式把消息写入到一个ConsumeQueue文件里，因为一个Topic会有多个MessageQueue。任何一条消息都需要写入到一个MessageQueue的，一个MessageQueue其实就是对应了一个ConsumeQueue文件。所以一条写入MessageQueue的消息，必然会异步进入对应的ConsumeQueue文件，如下图示：

接着，Broker还会以异步的方式把消息写入到一个IndexFile文件里。在IndexFile文件里，会把每条消息的key和消息在CommitLog中的offset偏移量做一个索引，这样后续如果要根据消息key从CommitLog文件里查询消息，就可以根据IndexFile文件的索引来查询，如下图示：

(2)Broker如何将消息写入CommitLog文件

Broker收到一个消息后，首先会顺序写入CommitLog文件。CommitLog文件的存储目录是${ROCKETMQ_HOME}/store/commitlog，目录里会有很多CommitLog文件。每个文件默认是1GB大小，一个CommitLog文件写满了就创建一个新的CommitLog文件，文件名就是文件中的第一个偏移量。文件名如果不足20位，就用0来补齐。

00000000000000000000
000000000003052631924

Broker在把消息写入CommitLog文件时，会申请一个putMessageLock锁。也就是说，Broker写入消息到CommitLog文件时都是串行的，不会并发写入，因为并发写入文件必然会有数据错乱的问题。

下面是相关的源码片段：

public class CommitLog {
    ...
    protected final PutMessageLock putMessageLock;
    ...
    public CompletableFuture<PutMessageResult> asyncPutMessage(final MessageExtBrokerInner msg) {
        ...
        putMessageLock.lock();
        ...
        result = mappedFile.appendMessage(msg, this.appendMessageCallback, putMessageContext);
        ...
    }
    ...
}

在asyncPutMessage()方法中，获取到锁之后，会对消息做出一系列处理，包括设置消息的存储时间、创建全局唯一的消息ID、计算消息的总长度等。然后会执行MappedFile的appendMessage()方法，把消息写入到MappedFile里。

public class MappedFile extends ReferenceResource {
    ...
    public AppendMessageResult appendMessage(final MessageExtBrokerInner msg, final AppendMessageCallback cb, PutMessageContext putMessageContext) {
        return appendMessagesInner(msg, cb, putMessageContext);
    }

    public AppendMessageResult appendMessagesInner(final MessageExt messageExt, final AppendMessageCallback cb, PutMessageContext putMessageContext) {
        ...
        ByteBuffer byteBuffer = writeBuffer != null ? writeBuffer.slice() : this.mappedByteBuffer.slice();
        byteBuffer.position(currentPos);
        AppendMessageResult result;
        if (messageExt instanceof MessageExtBrokerInner) {
            result = cb.doAppend(this.getFileFromOffset(), byteBuffer, this.fileSize - currentPos, (MessageExtBrokerInner) messageExt, putMessageContext);
        } else if (messageExt instanceof MessageExtBatch) {
            result = cb.doAppend(this.getFileFromOffset(), byteBuffer, this.fileSize - currentPos, (MessageExtBatch) messageExt, putMessageContext);
        } else {
            return new AppendMessageResult(AppendMessageStatus.UNKNOWN_ERROR);
        }
        this.wrotePosition.addAndGet(result.getWroteBytes());
        this.storeTimestamp = result.getStoreTimestamp();
        return result;
    }
    ...
}

上述源码中，其实最关键的是cb.doAppend()这行代码。cb.doAppend()会把消息追加到MappedFile映射的一块内存里去，并没有直接刷入到磁盘上的CommitLog文件，如下图示。至于具体什么时候才会把内存里的数据刷入磁盘上的CommitLog文件，这就要看配置的刷盘策略了。

另外，不管是同步刷盘还是异步刷盘，如果配置了主从同步，一旦将消息写入到CommitLog文件之后，接下来都会进行主从同步复制。

7.Broker是如何实时更新索引文件的

(1)消息如何进入CommitLog

(2)消息如何进入ConsumeQueue和IndexFile

(1)消息如何进入CommitLog

Broker收到一条消息后，会先把消息写入到CommitLog里。但是刚开始写入也仅仅是写入到MappedFile映射的一块内存，后续才会根据刷盘策略决定是否立即把数据从内存刷入磁盘。如下图示：

(2)消息如何进入ConsumeQueue和IndexFile

Broker启动时会启动一个叫ReputMessageService的线程，这个线程会把写入CommitLog的消息转发出去，也就是将消息写入(转发)到ConsumeQueue和IndexFile。如下图示：

在DefaultMessageStore的start()方法里，会启动这个ReputMessageService线程。而DefaultMessageStore的start()方法是在Broker启动时被调用的，所以相当于Broker启动时就会启动这个ReputMessageService线程。

public class BrokerController {
    ...
    public void start() throws Exception {
        //启动消息存储组件
        if (this.messageStore != null) {
            this.messageStore.start();
        }
        ...
    }
    ...
}

public class DefaultMessageStore implements MessageStore {
    ...
    public void start() throws Exception {
        ...
        this.reputMessageService.setReputFromOffset(maxPhysicalPosInLogicQueue);
        this.reputMessageService.start();
        ...
    }
    ...
}

下面是ReputMessageService线程的源码：

public class DefaultMessageStore implements MessageStore {
    ...
    class ReputMessageService extends ServiceThread {
        ...
        @Override
        public void run() {
            DefaultMessageStore.log.info(this.getServiceName() + " service started");
            while (!this.isStopped()) {
                try {
                    Thread.sleep(1);
                    this.doReput();
                } catch (Exception e) {
                    DefaultMessageStore.log.warn(this.getServiceName() + " service has exception. ", e);
                }
            }
            DefaultMessageStore.log.info(this.getServiceName() + " service end");
        }

        private void doReput() {
            ...
            DispatchRequest dispatchRequest = DefaultMessageStore.this.commitLog.checkMessageAndReturnSize(result.getByteBuffer(), false, false);
            ...
            DefaultMessageStore.this.doDispatch(dispatchRequest);
            ...
        }
        ...
    }

    public void doDispatch(DispatchRequest req) {
        for (CommitLogDispatcher dispatcher : this.dispatcherList) {
            dispatcher.dispatch(req);
        }
    }
    ...
}

由上述代码可知：在ReputMessageService线程里，每隔1毫秒就会把最近写入CommitLog的消息进行一次转发。其中会通过doReput()方法将消息转发到ConsumeQueue和IndexFile中。

在doReput()方法里，会从CommitLog中去获取到一个DispatchRequest，也就是从CommitLog中获取一份需要进行转发的消息。

接着，就会通过调用doDispatch()方法将消息转发到ConsumeQueue和IndexFile里，其中会通过遍历CommitLogDispatcher来实现。因为这个CommitLogDispatcher的实现类有两个，分别负责把消息转发到ConsumeQueue和IndexFile。

ConsumeQueueDispatcher的写入逻辑，就是找到当前Topic的messageQueueId对应的一个ConsumeQueue文件。一个MessageQueue会对应多个ConsumeQueue文件，只要找到一个即可，然后就可以把消息写入其中。

public class DefaultMessageStore implements MessageStore {
    ...
    class CommitLogDispatcherBuildConsumeQueue implements CommitLogDispatcher {
        @Override
        public void dispatch(DispatchRequest request) {
            final int tranType = MessageSysFlag.getTransactionValue(request.getSysFlag());
            switch (tranType) {
                case MessageSysFlag.TRANSACTION_NOT_TYPE:
                case MessageSysFlag.TRANSACTION_COMMIT_TYPE:
                    DefaultMessageStore.this.putMessagePositionInfo(request);
                    break;
                case MessageSysFlag.TRANSACTION_PREPARED_TYPE:
                case MessageSysFlag.TRANSACTION_ROLLBACK_TYPE:
                    break;
            }
        }
    }

    public void putMessagePositionInfo(DispatchRequest dispatchRequest) {
        ConsumeQueue cq = this.findConsumeQueue(dispatchRequest.getTopic(), dispatchRequest.getQueueId());
        cq.putMessagePositionInfoWrapper(dispatchRequest, checkMultiDispatchQueue(dispatchRequest));
    }
    ...
}

IndexDispatcher的写入逻辑，就是在IndexFile里构建对应的索引。

public class DefaultMessageStore implements MessageStore {
    ...
    class CommitLogDispatcherBuildIndex implements CommitLogDispatcher {
        @Override
        public void dispatch(DispatchRequest request) {
            if (DefaultMessageStore.this.messageStoreConfig.isMessageIndexEnable()) {
                DefaultMessageStore.this.indexService.buildIndex(request);
            }
        }
    }
    ...
}

(3)总结

当Broker把消息写入CommitLog后，会有一个后台线程每隔1毫秒拉取CommitLog中最新的一批消息，然后分别转发到ConsumeQueue和IndexFile中。

8.Broker是如何实现同步刷盘以及异步刷盘的

(1)Broker收到消息后的存储流程

(2)消息的刷盘时机和策略

(3)Broker是如何处理刷盘的

(1)Broker收到消息后的存储流程

Broker首先会将消息写入CommitLog，并且是先写入MappedFile映射的一块内存，而不是先写入磁盘。然后会有一个后台线程把CommitLog里的消息写入到ConsumeQueue和IndexFile里，如下图示：

(2)消息的刷盘时机和策略

当需要写入CommitLog的数据进入到MappedFile映射的一块内存后，就会开始执行刷盘策略。如果是同步刷盘，那么就会直接把内存里的数据写入磁盘文件。如果是异步刷盘，那么就会过一段时间后再把数据刷入磁盘文件。

在往CommitLog写数据时，会调用CommitLog的asyncPutMessage()方法，在这个方法的末尾有两行很关键的代码。一个是调用submitFlushRequest()方法，用于决定如何进行刷盘。一个是调用submitReplicaRequest()方法，用于决定如何把消息同步给Slave Broker。如下所示：

public class CommitLog {
    ...
    public CompletableFuture<PutMessageResult> asyncPutMessages(final MessageExtBatch messageExtBatch) {
        ...
        //用于决定如何进行刷盘
        CompletableFuture<PutMessageStatus> flushOKFuture = submitFlushRequest(result, messageExtBatch);
        //用于决定如何把消息同步给Slave Broker
        CompletableFuture<PutMessageStatus> replicaOKFuture = submitReplicaRequest(result, messageExtBatch);
        return flushOKFuture.thenCombine(replicaOKFuture, (flushStatus, replicaStatus) -> {
            if (flushStatus != PutMessageStatus.PUT_OK) {
                putMessageResult.setPutMessageStatus(flushStatus);
            }
            if (replicaStatus != PutMessageStatus.PUT_OK) {
                putMessageResult.setPutMessageStatus(replicaStatus);
            }
            return putMessageResult;
        });
    }
    ...
}

(3)Broker是如何处理刷盘的

接下来进入submitFlushRequest()方法看看Broker是如何处理刷盘的。

public class CommitLog {
    ...
    public CompletableFuture<PutMessageStatus> submitFlushRequest(AppendMessageResult result, MessageExt messageExt) {
        //Synchronization flush——同步刷盘
        if (FlushDiskType.SYNC_FLUSH == this.defaultMessageStore.getMessageStoreConfig().getFlushDiskType()) {
            final GroupCommitService service = (GroupCommitService) this.flushCommitLogService;
            if (messageExt.isWaitStoreMsgOK()) {
                GroupCommitRequest request = new GroupCommitRequest(result.getWroteOffset() + result.getWroteBytes(), this.defaultMessageStore.getMessageStoreConfig().getSyncFlushTimeout());
                flushDiskWatcher.add(request);
                service.putRequest(request);
                return request.future();
            } else {
                service.wakeup();
                return CompletableFuture.completedFuture(PutMessageStatus.PUT_OK);
            }
        }
        //Asynchronous flush——异步刷盘
        else {
            if (!this.defaultMessageStore.getMessageStoreConfig().isTransientStorePoolEnable()) {
                flushCommitLogService.wakeup();
            } else  {
                commitLogService.wakeup();
            }
            return CompletableFuture.completedFuture(PutMessageStatus.PUT_OK);
        }
    }
    ...
}

上述代码，就会根据配置的两种不同的刷盘策略，来分别进行处理的。

一.同步刷盘的策略是如何处理的

首先会构建一个GroupCommitRequest，然后提交给GroupCommitService去进行处理，接着调用request.future()等待同步刷盘成功。

具体的刷盘是由GroupCommitService执行的，它的doCommit()方法会执行同步刷盘的逻辑，代码如下：

public class CommitLog {
    ...
    class GroupCommitService extends FlushCommitLogService {
        ...
        private void doCommit() {
            ...
            CommitLog.this.mappedFileQueue.flush(0);
            ...
        }
        ...
    }
    ...
}

上述代码一层一层调用下去，可发现最终刷盘其实是靠MappedByteBuffer的force()方法，如下所示：

public class MappedFile extends ReferenceResource {
    ...
    public int flush(final int flushLeastPages) {
        ...
        this.mappedByteBuffer.force();
        ...
    }
    ...
}

这个MappedByteBuffer就是JDK NIO包下的API，MappedByteBuffer的force()方法会强迫将写入内存的数据刷入到磁盘文件里，执行完force()方法就代表同步刷盘成功了。

二.异步刷盘的策略是如何处理的

此时会唤醒一个flushCommitLogService组件。由于FlushCommitLogService是一个线程，它是一个抽象父类，它的子类是CommitRealTimeService。所以真正唤醒的是FlushCommitLogService的子类CommitRealTimeService线程。

在该线程里，会每隔一定时间执行一次刷盘，最大间隔是10s。所以一旦执行异步刷盘，那么最多10秒就会执行一次刷盘。

9.Broker是如何清理存储较久的磁盘数据的

(1)定时检查是否要删除磁盘上的文件

(2)触发删除文件的条件

(3)删除文件的具体操作

(1)定时检查是否要删除磁盘上的文件

默认情况下，Broker会启动一个后台线程，这个后台线程会自动检查CommitLog文件、ConsumeQueue文件，因为这些文件都会存在多个。如果发现比较旧的、超过72小时的文件，那么就会清理这些文件。

所以，默认情况下，Broker只会将消息保留3天，当然我们也可以通过fileReservedTime来自定义配置这个时间。

这个定时检查过期数据文件的线程，在DefaultMessageStore这个类里。在DefaultMessageStore的start()方法中，会调用addScheduleTask()方法每隔10s定时执行一个后台检查任务。如下所示：

public class DefaultMessageStore implements MessageStore {
    ...
    public void start() throws Exception {
        ...
        this.addScheduleTask();
        ...
    }

    private void addScheduleTask() {
        this.scheduledExecutorService.scheduleAtFixedRate(new Runnable() {
            @Override
            public void run() {
                DefaultMessageStore.this.cleanFilesPeriodically();
            }
        }, 1000 * 60, this.messageStoreConfig.getCleanResourceInterval(), TimeUnit.MILLISECONDS);
        ...
    }
    ...
}

在这个任务中，就会执行DefaultMessageStore的cleanFilesPeriodically()方法。其实也就是会周期性地清理掉磁盘上超过72小时的CommitLog、ConsumeQueue文件。

cleanFilesPeriodically()方法中包含了清理CommitLog和ConsumeQueue文件的逻辑：

public class DefaultMessageStore implements MessageStore {
    ...
    private void cleanFilesPeriodically() {
        this.cleanCommitLogService.run();
        this.cleanConsumeQueueService.run();
    }
    ...
}

(2)触发删除文件的条件

条件一：如果当前时间是预先设置的凌晨4点，就会触发执行一次删除文件的逻辑，这个时间是默认的

条件二：如果磁盘空间不足了也就是超过了85%的使用率，就会马上触发执行一次删除文件的逻辑

条件一指的是：如果磁盘没有满 ，那么每天会进行一次删除磁盘文件的操作，默认在凌晨4点执行，因为那个时候基本是业务低峰期。

条件二指的是：如果磁盘使用率超过85%了，那么此时可以允许继续在磁盘里写入数据，但会马上触发一次删除文件的操作。

注意：如果磁盘使用率超过90%了，那么此时是不允许再往磁盘里写入新数据的，同时会马上删除文件。因为一旦磁盘满了，那么写入磁盘就会失败，此时MQ就会出现故障。

(3)删除文件的具体操作

在删除文件时，无非就是对文件进行遍历。如果一个文件超过72小时都没修改过了，此时就可以删除了，哪怕有的消息可能还没有被消费，此时也不会再让消费者去消费了，直接删除掉。

10.Consumer作为消费者是如何创建和启动的

(1)Cosumer是如何创建和启动的

(2)Consumer启动时的三个核心组件总结

(1)Cosumer是如何创建和启动的

一般会通过DefaultMQPushConsumerImpl来创建Consumer，然后调用它的start()方法进行启动。

在执行start()方法启动Consumer的过程中，就会执行如下代码让Consumer和Broker建立长连接。只有建立了长连接，Consumer才能不断地从Broker中拉取消息。其中，MQClientFactory也是基于Netty来实现的。

public class DefaultMQPushConsumerImpl implements MQConsumerInner {
    ...
    public synchronized void start() throws MQClientException {
        ...
        this.mQClientFactory = MQClientManager.getInstance().getOrCreateMQClientInstance(this.defaultMQPushConsumer, this.rpcHook);
        ...
    }
    ...
}

接着看start()方法的如下代码：

public class DefaultMQPushConsumerImpl implements MQConsumerInner {
    ...
    public synchronized void start() throws MQClientException {
        ...
        this.rebalanceImpl.setConsumerGroup(this.defaultMQPushConsumer.getConsumerGroup());
        this.rebalanceImpl.setMessageModel(this.defaultMQPushConsumer.getMessageModel());
        this.rebalanceImpl.setAllocateMessageQueueStrategy(this.defaultMQPushConsumer.getAllocateMessageQueueStrategy());
        this.rebalanceImpl.setmQClientFactory(this.mQClientFactory);
        ...
    }
    ...
}

上述代码的RebalanceImpl就是专门负责Consumer重平衡的。如果ConsumerGroup中加入了一个新的Consumer，那么就会重新分配每个Consumer消费的MessageQueue。如果ConsumerGroup里某个Consumer宕机了，那么也会重新分配MessageQueue，这就是所谓的重平衡。

接着看start()方法的如下代码：

public class DefaultMQPushConsumerImpl implements MQConsumerInner {
    ...
    public synchronized void start() throws MQClientException {
        ...
        this.pullAPIWrapper = new PullAPIWrapper(mQClientFactory, this.defaultMQPushConsumer.getConsumerGroup(), isUnitMode());
        this.pullAPIWrapper.registerFilterMessageHook(filterMessageHookList);
        ...
    }
    ...
}

这个PullAPIWrapper就是消费者专门用来拉取消息的API组件。

接着看start()方法的如下代码：

public class DefaultMQPushConsumerImpl implements MQConsumerInner {
    ...
    public synchronized void start() throws MQClientException {
        ...
        if (this.defaultMQPushConsumer.getOffsetStore() != null) {
            this.offsetStore = this.defaultMQPushConsumer.getOffsetStore();
        } else {
            switch (this.defaultMQPushConsumer.getMessageModel()) {
                case BROADCASTING:
                    this.offsetStore = new LocalFileOffsetStore(this.mQClientFactory, this.defaultMQPushConsumer.getConsumerGroup());
                    break;
                case CLUSTERING:
                    this.offsetStore = new RemoteBrokerOffsetStore(this.mQClientFactory, this.defaultMQPushConsumer.getConsumerGroup());
                    break;
                default:
                    break;
            }
            this.defaultMQPushConsumer.setOffsetStore(this.offsetStore);
        }
        this.offsetStore.load();
        ...
    }
    ...
}

上面代码中的OffsetStore其实就是用来存储和管理Consumer消费进度offset的一个组件。

(2)Consumer启动时的三个核心组件总结

DefaultMQPushConsumerImpl的start()方法最核心的就是这三个组件。

首先Consumer刚启动，需要根据Rebalancer组件进行重平衡，确定自己要分配哪些MessageQueue之后才去拉取消息。

然后在拉取消息时，需要根据PullAPI组件通过底层网络通信发送请求进行拉取。

接着在拉取消息的过程中，需要根据OffsetStore组件来维护offset消费进度。

如果ConsumerGroup中多了Consumer或者少了Consumer，那么就需要根据Rebalancer组件来进行重平衡。

11.消费者组的多个Consumer会如何分配消息

(1)Consumer的负载均衡问题

(2)重平衡组件如何分配MessageQueue

(1)Consumer的负载均衡问题

当一个业务系统部署多台机器时，每个系统里都启动了一个Consumer。多个Consumer会组成一个ConsumerGroup，也就是消费者组。此时就会有一个消费者组内的多个Consumer同时消费一个Topic，而且这个Topic是有多个MessageQueue分布在多个Broker上的。如下图示：

那么问题来了：如果一个业务系统部署在两台机器上，对应一个消费者组里就有两个Consumer。而业务系统需要消费的一个Topic有三个MessageQueue，那么应该怎么分配呢？这就涉及到Consumer的负载均衡问题了。

前面介绍Consumer启动时，就介绍了几个关键的组件，分别是：重平衡组件、消息拉取组件、消费进度组件。其中的重平衡组件，就是专门负责处理多个Consumer的负载均衡问题的。

(2)重平衡组件如何分配MessageQueue

那么这个RebalancerImpl重平衡组件是如何将多个MessageQueue均匀的分配给一个消费者组内的多个Consumer的？

实际上，每个Consumer在启动后，都会向所有的Broker进行注册，并且持续保持自己的心跳，让每个Broker都能感知到一个消费者组内有哪些Consumer。下图中没有画出Consumer向每个Broker进行注册以及心跳，只能大致示意一下。

每个Consumer在启动后，重平衡组件都会随机挑选一个Broker，从里面获取该消费者组里有哪些Consumer存在。

当重平衡组件知道了消费者组内有哪些Consumer后，接下来就好办了。无非就是把Topic下的MessageQueue均匀地分配给这些Consumer。这时候其实有几种算法可以进行分配，但比较常用的一种算法就是平均分配。

假设现在一共有3个MessageQueue，有2个Consumer。那么就会给1个Consumer分配2个MessageQueue，给另外1个Consumer分配剩余的1个MessageQueue。

假设现在一共有4个MessageQueue，有2个Consumer。那么就可以2个Consumer各自分配2个MessageQueue。

总之一切都是平均分配，尽量保证每个Consumer的负载差不多。这样，一旦MessageQueue负载确定后，Consumer就知道自己要消费哪几个MessageQueue的消息，于是就可以连接到那个Broker上，从里面不停拉取消息过来进行消费。

12.Consumer会如何从Broker拉取一批消息

(1)什么是消费者组

(2)集群模式消费 vs 广播模式消费

(3)MessageQueue和ConsumeQueue以及CommitLog之间的关系

(4)MessageQueue与消费者的关系

(5)Push消费模式 vs Pull消费模式

(6)Broker如何读取消息返回给消费者

(7)消费者如何处理消息、进行ACK响应以及提交消费进度

(8)消费者组出现宕机或扩容应如何处理

(9)消费源码的流程

(1)什么是消费者组

一.消费者组举例

消费者组的意思就是给一组消费者起一个名字。比如有一个Topic叫TopicOrderPaySuccess，库存系统、积分系统、营销系统、仓储系统都要去消费这个Topic中的数据，那么此时应该给这四个系统分别起一个消费者组名字，如下所示：

stock_consumer_group、marketing_consumer_group、
credit_consumer_group、wms_consumer_group

设置消费者组的方式如下所示：

DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("stock_consumer_group");

假设库存系统部署了4台机器，每台机器上的消费者组的名字都是stock_consumer_group，那么这4台机器就同属于一个消费者组。以此类推，每个系统的几台机器都是属于各自的消费者组。

下图展示了两个系统，每个系统都有2台机器，每个系统都有一个自己的消费者组。

二.不同消费者组之间的关系

假设库存系统和营销系统作为两个消费者组，都订阅了TopicOrderPaySuccess这个订单支付成功消息的Topic，此时如果订单系统作为生产者发送了一条消息到这个Topic，那么这条消息会被如何消费呢？

一般情况下，这条消息进入Broker后，库存系统和营销系统作为两个消费者组，每个组都会拉取到这条消息。也就是说，这个订单支付成功的消息，库存系统会获取到一条，营销系统也会获取到一条，它们俩都会获取到这条消息。

但库存系统这个消费者组里有两台机器，是两台机器都获取到这条消息、还是只有一台机器会获取到这条消息？

一般情况下，库存系统的两台机器中只有一台机器会获取到这条消息，营销系统也是同理。

下图展示了对于同一条订单支付成功的消息，库存系统的一台机器获取到了、营销系统的一台机器也获取到了。所以在消费时，不同的系统应该设置不同的消费者组。如果不同的消费者组订阅了同一个Topic，对Topic里的同一条消息，每个消费者组都会获取到这条消息。

(2)集群模式消费 vs 广播模式消费

对于一个消费者组而言，它获取到一条消息后，如果消费者组内部有多台机器，到底是只有一台机器可以获取到这个消息，还是每台机器都可以获取到这个消息？这就是集群模式和广播模式的区别。

默认情况下都是集群模式：即一个消费者组获取到一条消息，只会交给组内的一台机器去处理，不是每台机器都可以获取到这条消息的。

但是可以通过如下设置来改变为广播模式：

consumer.setMessageModel(MessageModel.BROADCASTING);

如果修改为广播模式，那么对于消费者组获取到的一条消息，组内每台机器都可以获取到这条消息。但是相对而言广播模式用的很少，基本上都是使用集群模式来进行消费的。

(3)MessageQueue和ConsumeQueue以及CommitLog之间的关系

在创建Topic时，需要设置Topic有多少个MessageQueue。Topic中的多个MessageQueue会分散在多个Broker上，一个Broker上的一个MessageQueue会有多个ConsumeQueue文件。但在一个Broker运行过程中，一个MessageQueue只会对应一个ConsumeQueue文件。

对于Broker而言，存储在一个Broker上的所有Topic及MessageQueue数据都会写入一个统一的CommitLog文件，一个Broker收到的所有消息都会往CommitLog文件里面写。

对于Topic的各个MessageQueue而言，则是通过各个ConsumeQueue文件来存储属于MessageQueue的消息在CommitLog文件中的物理地址(即offset偏移量)。

(4)MessageQueue与消费者的关系

一个Topic上的多个MessageQueue是如何让一个消费者组中的多台机器来进行消费的？可以简单理解为，它会均匀将MessageQueue分配给消费者组的多台机器来消费。

举个例子，假设TopicOrderPaySuccess有4个MessageQueue，这4个MessageQueue分布在两个Master Broker上，每个Master Broker上有2个MessageQueue。然后库存系统作为一个消费者组，库存系统里有两台机器。那么正常情况下，最好就是让这两台机器各自负责2个MessageQueue的消费。比如库存系统的机器01从Master Broker01上消费2个MessageQueue，库存系统的机器02从Master Broker02上消费2个MessageQueue。这样就能把消费的负载均摊到两台Master Broker上。

所以大致可以认为一个Topic的多个MessageQueue会均匀分摊给消费者组内的多个机器去消费。

这里的一个原则是：一个MessageQueue只能被一个消费者机器去处理，但是一台消费者机器可以负责多个MessageQueue的消息处理。

(5)Push消费模式 vs Pull消费模式

一.一般选择Push消费模式

既然一个消费者组内的多台机器会分别负责一部分MessageQueue的消费的，那么每台机器都必须要连接到对应的Broker，尝试消费里面MessageQueue对应的消息。于是就涉及到两种消费模式了，一个是Push模式、一个是Pull模式。

这两个消费模式本质上是一样的，都是消费者主动发送请求到Broker去拉取一批消息进行处理。

Push消费模式是基于Pull消费模式来实现的，只不过它的名字叫做Push而已。在Push模式下，Broker会尽可能实时把新消息交给消费者进行处理，它的消息时效性会更好。

一般我们使用RocketMQ时，消费模式通常都选择Push模式来，因为Pull模式的代码写起来更加复杂和繁琐，而且Push模式底层本身就是基于Pull模式来实现的，只不过时效性更好而已。

二.Push消费模式的实现思路

当消费者发送请求到Broker去拉取消息时，如果有新的消息可以消费，那么就马上返回一批消息到消费机器去处理。消费者处理完之后，会接着发送请求到Broker机器去拉取下一批消息。

所以，消费者机器在Push模式下处理完一批消息，会马上发起请求拉取下一批消息，消息处理的时效性非常好，看起来就像Broker一直不停的推送消息到消费机器一样。

此外，Push模式下有一个请求挂起和长轮询的机制：当拉取消息的请求发送到Broker，Broker却发现没有新的消息可以处理时，就会让处理请求的线程挂起，默认是挂起15秒。然后在挂起期间，Broker会有一个后台线程，每隔一会就检查一下是否有新的消息。如果有新的消息，就主动唤醒被挂起的请求处理线程，然后把消息返回给消费者。

可见，常见的Push消费模式，本质也是消费者不断发送请求到Broker去拉取一批一批的消息。

(6)Broker如何读取消息返回给消费者

Broker在收到消费者的拉取请求后，是如何将消息读取出来，然后返回给消费者的？这涉及到ConsumeQueue和CommitLog。

假设一个消费者发送了拉取请求到Broker，表示它要拉取MessageQueue0中的消息，然后它之前都没拉取过消息，所以就从这个MessageQueue0中的第一条消息开始拉取。

于是，Broker就会找到MessageQueue0对应的ConsumeQueue0，从里面找到第一条消息的offset。接着Broker就需要根据ConsumeQueue0中找到的第一条消息的地址，去CommitLog中根据这个offset地址读取出这条消息的数据，然后把这条消息的数据返回给消费者。

所以消费者在消费消息时，本质就是：首先根据要消费的MessageQueue以及开始消费的位置，去找到对应的ConsumeQueue。然后在ConsumeQueue中读取要消费的消息在CommitLog中的offset偏移量。接着到CommitLog中根据offset读取出完整的消息数据，最后将完整的消息数据返回给消费者。

(7)消费者如何处理消息、进行ACK响应以及提交消费进度

消费者拉取到一批消息后，就会将这批消息传入注册的回调函数，如下所示：

consumer.registerMessageListener(new MessageListenerConcurrently() {
    @Override
    public ConsumeConcurrentlyStatus consumeMessage(List<MessageExt> msgs, ConsumeConcurrentlyContext context) {
        //处理消息
        //标记该消息已经被成功消费
        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
    }
});

当消费者处理完这批消息后，消费者就会提交目前的一个消费进度到Broker上，然后Broker就会存储消费者的消费进度。

比如现在对ConsumeQueue0的消费进度就是在offset=1的位置，那么Broker会记录下一个ConsumeOffset来标记该消费者的消费进度。这样下次这个消费者组只要再次拉取这个ConsumeQueue的消息，就可以从Broker记录的消费位置开始继续拉取，不用重头开始拉取了。

(8)消费者组出现宕机或扩容应如何处理

此时会进入一个Rebalance环节，也就是重新给各个消费者分配各自需要处理的MessageQueue。

比如现在机器01负责MessageQueue0和MessageQueue1，机器02负责MessageQueue2和MessageQueue3。如果现在机器02宕机了，那么机器01就会接管机器02之前负责的MessageQueue2和MessageQueue3。如果此时消费者组加入了一台机器03，那么就可以把机器02负责的MessageQueue3转移给机器03，然后机器01只负责一个MessageQueue2的消费，这就是负载重平衡。

(9)消费源码的流程

拉取消息的源码入口在DefaultMQPushConsumerImpl类的pullMessage()方法，里面涉及了：拉取请求、消息流量控制、通过PullAPIWrapper与服务端进行网络交互、服务端根据ConsumeQueue文件拉取消息等事情。