RocketMq-消息的投递机制

1.前言

RocketMQ的消息投递分分为两种:

• 一种是生产者往MQ Broker中投递
• 一种则是MQ broker 往消费者投递

2.RocketMQ的消息模型

RocketMQ 的消息模型整体并不复杂，如下图所示：

一个Topic(消息主题)可能对应多个实际的消息队列(MessgeQueue)
在底层实现上，为了提高MQ的可用性和灵活性，一个Topic在实际存储的过程中，采用了多队列的方式，具体形式如上图所示。每个消息队列在使用中应当保证先入先出（FIFO,First In First Out）的方式进行消费。
那么，基于这种模型，就会引申出两个问题：

• 生产者 在发送相同Topic的消息时，消息体应当被放置到哪一个消息队列(MessageQueue)中？
• 消费者 在消费消息时，应当从哪些消息队列中拉取消息？
  消息的系统间传递时，会跨越不同的网络载体，这会导致消息的传播无法保证其有序性

3.生产者(Producer)投递消息的策略

3.1 默认投递方式：基于Queue队列轮询算法投递
这种算法有个很好的特性就是，保证每一个Queue队列的消息投递数量尽可能均匀，源代码如下（TopicPublishInfo 类）：

public MessageQueue selectOneMessageQueue(final String lastBrokerName) {
        if (lastBrokerName == null) {
            return selectOneMessageQueue();
        } else {
            int index = this.sendWhichQueue.getAndIncrement();
            for (int i = 0; i < this.messageQueueList.size(); i++) {
                int pos = Math.abs(index++) % this.messageQueueList.size();
                //轮询计算
                if (pos < 0)
                    pos = 0;
                MessageQueue mq = this.messageQueueList.get(pos);
                if (!mq.getBrokerName().equals(lastBrokerName)) {
                    return mq;
                }
            }
            return selectOneMessageQueue();
        }
    }

    public MessageQueue selectOneMessageQueue() {
        int index = this.sendWhichQueue.getAndIncrement();
        int pos = Math.abs(index) % this.messageQueueList.size();
        if (pos < 0)
            pos = 0;
        return this.messageQueueList.get(pos);
    }

3.2 默认投递方式的增强：基于Queue队列轮询算法和消息投递延迟最小的策略投递
默认的投递方式比较简单，但是也暴露了一个问题，就是有些Queue队列可能由于自身数量积压等原因，可能在投递的过程比较长，对于这样的Queue队列会影响后续投递的效果。
基于这种现象，RocketMQ在每发送一个MQ消息后，都会统计一下消息投递的时间延迟，根据这个时间延迟，可以知道往哪些Queue队列投递的速度快
在这种场景下，会优先使用消息投递延迟最小的策略，如果没有生效，再使用Queue队列轮询的方式。源代码如下：

	/**
     * 根据 TopicPublishInfo 内部维护的index,在每次操作时，都会递增，
     * 然后根据 index % queueList.size(),使用了轮询的基础算法
     *
     */
    public MessageQueue selectOneMessageQueue(final TopicPublishInfo tpInfo, final String lastBrokerName) {
        if (this.sendLatencyFaultEnable) {
            try {
                int index = tpInfo.getSendWhichQueue().getAndIncrement();
                for (int i = 0; i < tpInfo.getMessageQueueList().size(); i++) {
                    //基于index和队列数量取余，确定位置
                    int pos = Math.abs(index++) % tpInfo.getMessageQueueList().size();
                    if (pos < 0)
                        pos = 0;
                    MessageQueue mq = tpInfo.getMessageQueueList().get(pos);
                    if (latencyFaultTolerance.isAvailable(mq.getBrokerName())) {
                        if (null == lastBrokerName || mq.getBrokerName().equals(lastBrokerName))
                            return mq;
                    }
                }
                
                // 从延迟容错broker列表中挑选一个容错性最好的一个 broker
                final String notBestBroker = latencyFaultTolerance.pickOneAtLeast();
                int writeQueueNums = tpInfo.getQueueIdByBroker(notBestBroker);
                if (writeQueueNums > 0) {
                     // 取余挑选其中一个队列
                    final MessageQueue mq = tpInfo.selectOneMessageQueue();
                    if (notBestBroker != null) {
                        mq.setBrokerName(notBestBroker);
                        mq.setQueueId(tpInfo.getSendWhichQueue().getAndIncrement() % writeQueueNums);
                    }
                    return mq;
                } else {
                    latencyFaultTolerance.remove(notBestBroker);
                }
            } catch (Exception e) {
                log.error("Error occurred when selecting message queue", e);
            }
          // 取余挑选其中一个队列
            return tpInfo.selectOneMessageQueue();
        }

        return tpInfo.selectOneMessageQueue(lastBrokerName);
    }

3.3 顺序消息的投递方式
上述两种投递方式属于对消息投递的时序性没有要求的场景，这种投递的速度和效率比较高。而在有些场景下，需要保证同类型消息投递和消费的顺序性。
例如，假设现在有TOPIC TOPIC_SALE_ORDER,该 Topic下有4个Queue队列，该Topic用于传递订单的状态变迁，假设订单有状态：未支付、已支付、发货中(处理中)、发货成功、发货失败。
在时序上，生产者从时序上可以生成如下几个消息：
订单T0000001:未支付 --> 订单T0000001:已支付 --> 订单T0000001:发货中(处理中) --> 订单T0000001:发货失败
这种情况下，我们希望消费者消费消息的顺序和我们发送是一致的，然而，有上述MQ的投递和消费机制，我们无法保证顺序是正确的，对于顺序异常的消息，消费者即使有一定的状态容错，也不能完全处理好随机出现组合情况。
基于上述的情况，RockeMQ采用了这种实现方案：对于相同订单号的消息，通过一定的策略，将其放置在一个 queue队列中，然后消费者再采用一定的策略(一个线程独立处理一个queue,保证处理消息的顺序性)，能够保证消费的顺序性

我们先看生产者是如何能将相同订单号的消息发送到同一个queue队列的
生产者在消息投递的过程中，使用了 MessageQueueSelector 作为队列选择的策略接口，源码如下：

public interface MessageQueueSelector {
        /**
         * 根据消息体和参数，从一批消息队列中挑选出一个合适的消息队列
         * @param mqs  待选择的MQ队列选择列表
         * @param msg  待发送的消息体
         * @param arg  附加参数
         * @return  选择后的队列
         */
        MessageQueue select(final List<MessageQueue> mqs, final Message msg, final Object arg);
}

它有如下三个实现：

• SelectMessageQueueByRandom 随机分配策略
• SelectMessageQueueByHash 基于hash的分配策略
• SelectMessageQueueByMachineRoom 服务器的就近原则分配策略

我们主要看基于hash的分配策略（SelectMessageQueueByHash ）：

public class SelectMessageQueueByHash implements MessageQueueSelector {

    @Override
    public MessageQueue select(List<MessageQueue> mqs, Message msg, Object arg) {
        int value = arg.hashCode();
        if (value < 0) {
            value = Math.abs(value);
        }

        value = value % mqs.size();
        return mqs.get(value);
    }
}

其简单的一种伪代码实现：

// orderNo 传入订单号作为hash运算对象
rocketMQTemplate.asyncSendOrderly(saleOrderTopic + ":" + tag, msg,orderNo, new SendCallback() {
            @Override
            public void onSuccess(SendResult sendResult) {
                log.info("SALE ORDER NOTIFICATION SUCCESS：{}",sendResult.getMsgId());
            }
            @Override
            public void onException(Throwable throwable) {
                 //exception happens
            }
        });

4.如何为消费者分配queue队列?

RocketMQ对于消费者消费消息有两种形式：

• BROADCASTING:广播式消费，这种模式下，一个消息会被通知到每一个消费者
• CLUSTERING: 集群式消费，这种模式下，一个消息最多只会被投递到一个消费者上进行消费

我们接下来主要分析集群式消费（对于使用了消费模式为MessageModel.CLUSTERING进行消费时，需要保证一个消息在整个集群中只需要被消费一次）

我们先看为消费者分配queue的策略算法接口

public interface AllocateMessageQueueStrategy {

    /**
     * Allocating by consumer id
     *
     * @param consumerGroup 当前 consumer群组
     * @param currentCID 当前consumer id
     * @param mqAll 当前topic的所有queue实例引用
     * @param cidAll 当前 consumer群组下所有的consumer id set集合
     * @return 根据策略给当前consumer分配的queue列表
     */
    List<MessageQueue> allocate(
        final String consumerGroup,
        final String currentCID,
        final List<MessageQueue> mqAll,
        final List<String> cidAll
    );

    /**
     * 算法名称
     *
     * @return The strategy name
     */
    String getName();
}

其有如下几个实现类

• AllocateMessageQueueAveragely 平均分配算法
• AllocateMessageQueueAveragelyByCircle 环形分配算法
• AllocateMachineRoomNearby 机房临近分配算法
• AllocateMessageQueueByMachineRoom 机房分配算法
• AllocateMessageQueueConsistentHash 一致性hash算法
• AllocateMessageQueueByConfig 配置分配算法

现在我们假设有10个队列，4个消费者

4.1 AllocateMessageQueueAveragely-平均分配算法（源码自己debug看一下）
10/4=2，即表示每个消费者平均均摊2个queue；而多出来2个queue还没有分配，那么，根据消费者的顺序consumer-1、consumer-2、consumer-3、consumer-4,则多出来的2个queue将分别给consumer-1和consumer-2。最终，分摊关系如下：
consumer-1:3个;consumer-2:3个;consumer-3:2个;consumer-4:2个

4.2 AllocateMessageQueueAveragelyByCircle-环形分配算法（源码自己debug看一下）
环形，其实就是一个圆.把10个队列拼成一个圈（#0->#1->#2->#3->#4->#5->#6->#7->#8->#9->#0…这不是链型，我没画图，就是一个环，首尾连接）。最终的分配结果就是：consumer-1:3个（#0，#4，#8）;consumer-2:3个（#1，#5，#9）;consumer-3:2个（#2，#6）;consumer-4:2个（#3，#7）

4.3 AllocateMachineRoomNearby-机房临近分配算法
对于跨机房的场景，会存在网络、稳定性和隔离心的原因，该算法会根据queue的部署机房位置和消费者consumer的位置，过滤出当前消费者consumer相同机房的queue队列，然后再结合上述的算法，如基于平均分配算法在queue队列子集的基础上再挑选.

4.4 AllocateMessageQueueByMachineRoom-机房分配算法
该算法适用于属于同一个机房内部的消息，去分配queue。这种方式非常明确，基于上面的机房临近分配算法的场景，这种更彻底，直接指定基于机房消费的策略。这种方式具有强约定性，比如broker名称按照机房的名称进行拼接，在算法中通过约定解析进行分配。

4.5 AllocateMessageQueueConsistentHash-基于一致性hash算法
使用这种算法，会将consumer消费者作为Node节点构造成一个hash环，然后queue队列通过这个hash环来决定被分配给哪个consumer消费者。

4.6 AllocateMessageQueueByConfig–基于配置分配算法
这种算法单纯基于配置的，非常简单，实际使用中可能用途不大

消费者如何指定分配算法？
默认情况下，消费者使用的是AllocateMessageQueueAveragely算法，也可以自己指定

public class DefaultMQPushConsumer{    
    /**
     * Default constructor.
     */
    public DefaultMQPushConsumer() {
        this(MixAll.DEFAULT_CONSUMER_GROUP, null, new AllocateMessageQueueAveragely());
    }

    /**
     * Constructor specifying consumer group, RPC hook and message queue allocating algorithm.
     *
     * @param consumerGroup Consume queue.
     * @param rpcHook RPC hook to execute before each remoting command.
     * @param allocateMessageQueueStrategy message queue allocating algorithm.
     */
    public DefaultMQPushConsumer(final String consumerGroup, RPCHook rpcHook,
        AllocateMessageQueueStrategy allocateMessageQueueStrategy) {
        this.consumerGroup = consumerGroup;
        this.allocateMessageQueueStrategy = allocateMessageQueueStrategy;
        defaultMQPushConsumerImpl = new DefaultMQPushConsumerImpl(this, rpcHook);
    }
.....
}

参考说明：

版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/u010349169/article/details/91368332