RocketMQ

一、基础概念

RcoketMQ 是一款低延迟、高可靠、可伸缩、易于使用的消息中间件。具有以下特性：

1.支持发布/订阅（Pub/Sub）和点对点（P2P）消息模型
2.在一个队列中可靠的先进先出（FIFO）和严格的顺序传递
3.支持拉（pull）和推（push）两种消息模式
4.单一队列百万消息的堆积能力
5.支持多种消息协议，如 JMS、MQTT 等
6.分布式高可用的部署架构,满足至少一次消息传递语义
7.提供 docker 镜像用于隔离测试和云集群部署
8.提供配置、指标和监控等功能丰富的 Dashboard

1.2 核心组件

Producer

消息生产者，生产者的作用就是将消息发送到 MQ，生产者本身既可以产生消息，如读取文本信息等。也可以对外提供接口，由外部应用来调用接口，再由生产者将收到的消息发送到 MQ。

RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。同步和异步方式均需要Broker返回确认信息，单向发送不需要。

Producer Group

生产者组，简单来说就是多个发送同一类消息的生产者称之为一个生产者组。

如果发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。

Consumer

消息消费者，简单来说，消费 MQ 上的消息的应用程序就是消费者，至于消息是否进行逻辑处理，还是直接存储到数据库等取决于业务需要。

从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。

Consumer Group

消费者组，和生产者类似，消费同一类消息的多个 consumer 实例组成一个消费者组。

消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。要注意的是，消费者组的消费者实例必须订阅完全相同的Topic。

RocketMQ 支持两种消息模式：集群消费（Clustering）和广播消费（Broadcasting）。

Broker

Broker 是 RocketMQ 系统的主要角色，其实就是前面一直说的 MQ。Broker 接收来自生产者的消息，储存以及为消费者拉取消息的请求做好准备。

Broker Server也存储消息相关的元数据，包括消费者组、消费进度偏移和主题和队列等

Broker 在实际部署过程中对应一台服务器，每个 Broker 可以存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的 Broker。Message Queue 用于存储消息的物理地址，每个Topic中的消息地址存储于多个 Message Queue 中。

Name Server

Name Server 充当路由消息的提供者。生产者或消费者能够通过Name Server查找各主题相应的Broker IP列表。多个Namesrv实例组成集群，但相互独立，没有信息交换。

Topic （主要用来区分不同的业务）
Topic 是一种消息的逻辑分类，表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。

比如说你有订单类的消息，也有库存类的消息，那么就需要进行分类，一个是订单 Topic 存放订单相关的消息，一个是库存 Topic 存储库存相关的消息。

不同的topic相互独立彼此不受影响。

另外一个topic默认有4个队列？。

topic存放在不同的broker，不同broker之间的关系是怎样的，主备关系？

Tag
为消息设置的标志，用于同一主题下区分不同类型的消息。来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同标签。

标签能够有效地保持代码的清晰度和连贯性，并优化RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消费逻辑，实现更好的扩展性。

一般在相同业务模块中通过引入标签来标记不同用途的消息。

消息（Message）

消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个主题。RocketMQ中每个消息拥有唯一的Message ID，且可以携带具有业务标识的Key。

系统提供了通过Message ID和Key查询消息的功能。例如你需要一个业务 key 来查找 broker 上的消息，方便在开发过程中诊断问题。（在实践在主要还是通过Message ID在broker上查看消息的具体信息）

Message 还有一个可选的 tag 设置，以便消费端可以基于 tag 进行过滤消息。

1.1 技术架构

Apache RocketMQ是一个具有低延迟、高性能和可靠性、万亿级容量同时具备灵活的可伸缩性的分布式消息和流处理平台，它由四个部分组成:name servers, brokers, producers 和 consumers。它们所有都可以水平扩展避免单点故障。就像下图所示：

名称服务集群 NameServer cluster

NameServer服务提供了轻量级的服务发现和路由。每个NameServer服务记录完整的路由信息，提供一致的读写服务，支持快速存储扩展.

NameServer是一个非常简单的Topic路由注册中心，其角色类似Dubbo中的zookeeper，支持Broker的动态注册与发现。主要包括两个功能：

1.Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；

2.路由信息管理，每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息。然后Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。它更像是一个配置中心，配置了broker的IP，topic等关键信息。

NameServer通常也是集群的方式部署，各实例间相互不进行信息通讯（即牺牲了一致性保证了可用性）。

Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，Broker仍然可以向其它NameServer同步其路由信息，Producer,Consumer仍然可以动态感知Broker的路由的信息。

代理服务集群 Broker Cluster

Broker通过提供轻量级主题和队列机制来处理消息存储。它们支持Push和Pull模型，包含容错机制(2个副本或3个副本)，提供了极强的峰值处理里能力和按照时间顺序存储数以百万记的消息存储能力。此外，代理提供了灾难恢复、丰富的度量统计和警报机制，这些都是在传统的消息传递系统中缺乏的。

Broker主要负责消息的存储、投递和查询以及服务高可用保证，为了实现这些功能，Broker包含了以下几个重要子模块。

• Remoting Module：整个Broker的实体，负责处理来自clients端的请求。
• Client Manager：负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息
• Store Service：提供方便简单的API接口处理消息存储到物理硬盘和查询功能。
• HA Service：高可用服务，提供Master Broker 和 Slave Broker之间的数据同步功能。
• Index Service：根据特定的Message key对投递到Broker的消息进行索引服务，以提供消息的快速查询。

生产者集群 Producer Cluster

produce支持分布式部署，分布式的produce通过broker集群提供的各种负载均衡策略将消息发送到broker集群中。发送过程支持快速失败是低延迟的。
 

消费者集群 Consumer Cluster

消费者也支持在推送和者拉取模式下分布式部署，它还支持集群消费和消息广播。

提供实时的消息订阅机制，能够满足大多数消费者的需求。

1.3 部署架构和工作流程

RocketMQ 网络部署特点

• NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。

• Broker部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。 注意：当前RocketMQ版本在部署架构上支持一Master多Slave，但只有BrokerId=1的从服务器才会参与消息的读负载。

• Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer获取Topic路由信息，并向提供Topic 服务的Master建立长连接，且定时向Master发送心跳。Producer完全无状态，可集群部署。

• Consumer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer获取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息，也可以从Slave订阅消息，消费者在向Master拉取消息时，Master服务器会根据拉取偏移量与最大偏移量的距离（判断是否读老消息，产生读I/O），以及从服务器是否可读等因素建议下一次是从Master还是Slave拉取。

RocketMQ工作流程

结合部署架构图，描述集群工作流程：

1.首先启动 NameServer，NameServer起来后监听端口。等待 Broker、Producer、Consumer 来连接，并提供各种查询服务。相当于一个路由控制中心。

2.接着启动 BrokerServer，每隔 30s 定时向所有的 NameServer 发送心跳包(即广播的方式，此方式可以保证每个NameServer的最终一致性)，心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。

注册成功后，NameServer集群中就有Topic跟Broker的映射关系。

NameServer 收到 Broker 心跳包后，更新相关信息，且会每隔 10s 检查上次 Broker 发送心跳的时间，若超过 120s 就判定 Broker 下线，并移除此 Broker 所有信息。（此机制虽然保证了高可用，但最终有可能因为网络波动等导致每个NameServer的broker节点数量不一致）

3.创建Topic，收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic。

4.启动 Producer，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，默认轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息。Broker 收到数据进行存储，并构建消费队列和索引文件。

注意：Producer会先根据消息的Topic从本地缓存的TopicPublishInfoTable获取路由信息。如果没有则更新路由信息会从NameServer上重新拉取，同时Producer会默认每隔30s向NameServer拉取一次路由信息。

5.Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，选择其中的某一个或者某几个消息队列来拉取消息并进行消费消费消息。

相关组件流程

Producer 消息发送流程

1. 消息生产者启动
2. 消息验证
3. 查找主题路由信息
4. 选择消息队列
5. 发送消息

Consumer 消费消息流程

1. 消息消费者启动
2. 跟其中一台NameServer建立长连接
3. 根据负载均衡策略选择 Broker
4. 封装消息拉取请求，向 Broker 发出请求
5. Broker 接收请求，通过验证、流控等后，查找并按照消息 tag 的 hash 过滤后返回消息（表达式过滤）
6. Consumer 接收消息后再次验证 tag，消费后向 Broker 返回消费状态
7. Broker 存储消费进度
    

思考：

1.发送消息时自动创建Topic，如何落在具体的broker上？

2.生产者和消费者是如何通信的？

他们之间无法直接通信，需要通过name server作为中介并通过topic找到对应的broker进行通信。生产者与broker建立链接通信发送消息，消费者通过broker建立连接拉起消息。

生产者只能和broker中mater建立连接通信发送消息，而消费者可以和broker中的master和Slave订阅消息，，但只有BrokerId=1的从服务器才会参与消息的读负载。

4.broker集群的主从模式职能如何化分？

5.Name Server集群与Kafka中zk集群有和不同？

Name Server集群充当路由的角色：他存储了broker集群信息，并建立了topic与broker的路由映射关系，供生产者和消费者进行消息路由。

zk集群：主要充当Broker Controller的选举功能。

二、安装部署和环境搭建

1.配置环境

Java环境配置

查看java的安装路径： which java

配置Java和RocketMQ的环境变量

若当前不在根目录下则使用 cd 切换到根目录下，具体操作见如下代码：

Lucky:~ administrator$ touch ~/.bash_profile             //创建.bash_profile文件
Lucky:~ administrator$ open ~/.bash_profile             //打开.bash_profile文件

我本地的配置如下：

export M2_HOME=/Users/daiwei/desktop/develop/soft/apache-maven-3.6.1
export PATH=$PATH:$M2_HOME/bin
export HOMEBREW_BOTTLE_DOMAIN=https://mirrors.ustc.edu.cn/homebrew-bottles

export JAVA_HOME=$(/usr/libexec/java_home)
export PATH=$JAVA_HOME/bin:$PATH
export CLASS_PATH=$JAVA_HOME/lib


export ROCKETMQ_HOME=/Users/daiwei/Desktop/develop/rocketmq-all-4.3.2-bin-release

最后执行；source ~/.bash_profile命令使配置生效

启动namesrv

修改 namesrv的jvm配置

#修改此处的内存大小，默认为4g，一般我们的虚拟机内存不会太大 
#所以此处修改为256m，可以根据自己机器的配置合理设置 
JAVA_OPT="${JAVA_OPT} ‐server ‐Xms256m ‐Xmx256m ‐Xmn128m ‐XX:MetaspaceSi ze=64m ‐XX:MaxMetaspaceSize=128m"

启动 namesrv

nohup sh mqnamesrv & 

然后查看对应的日志

tail -f nohup.out

启动后效果如图：

启动 broker

修改 runbroker.sh配置

# JVM Configuration #======================================================================= ==================== 
# 默认需要内存大小为8g 
JAVA_OPT="${JAVA_OPT} ‐server ‐Xms256m ‐Xmx256m ‐Xmn128m"

启动 broker 

nohup sh mqbroker -n localhost:9876 autoCreateTopicEnable=true 

启动后效果如图：

三、核心机制

1.1 Consumer拉起消息模型

拉取式消费（Pull Consumer）

Consumer消费的一种类型，应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息，应用就会启动消费过程

推动式消费（Push Consumer）

Consumer消费的一种类型，应用不需要主动调用Consumer的拉消息方法，在底层已经封装了拉取的调用逻辑，在用户层面看来是broker把消息推送过来的，其实底层还是consumer去broker主动拉取消息。该模式下Broker收到数据后会主动推送给消费端，该消费模式一般实时性较高。

RocketMQ是基于长轮训的方式来实现push模型，中和了传统push模型给消费者压力的缺陷。是一种平衡了实时和压力的方式。

具体机制如下：

①消费者有一个后台线程，会去处理拉取消息（PullRequest）
②先去判断有没有过多消息没有消费，如果有的话，那么就间隔一定时间再次从①开始执行拉取消息的逻辑
③消费者没有过多消息没有消费，那么就会直接向MQ发送拉取消息的请求，有消息就返回，没有消息就hold住请求，等有新的消息到的时候才返回
④消费者获取到消息之后，会去找用户自定义的消息处理逻辑的实现（MessageListener的实现）去消费消息，同时会再次拉取消息，继续从①开始执行逻辑
————————————————
版权声明：本文为CSDN博主「Young丶」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/agonie201218/article/details/126394228

总结：和设计模式观察者模式的推-拉模型还是有一定的区别。

默认是哪一种？

1.2 消费组集群消费模型

集群消费（Clustering）

集群消费模式下,相同Consumer Group的每个Consumer实例平均分摊消息。注意一个消费者可能消费多个队列，但一个队列只会有一个消费者消费。

故一个topic的队列数量直接决定了其支持的消费者的最大数，如果topic的队列数量小于消费者的数量，那部分消费者将无法消费消息。

集群消费模式适用于每条消息只需要被处理一次的场景，也就是说整个消费组会Topic收到全量的消息，而消费组内的消费分担消费这些消息，因此可以通过扩缩消费者数量，来提升或降低消费能力，具体示例如下图所示，是最常见的消费方式。

RocketMQ Push Consumer默认为集群模式

也可以通过代码配置对于消费模式

consumer.setMessageModel(MessageModel.CLUSTERING);

广播消费（Broadcasting）

广播消费模式下，相同Consumer Group的每个Consumer实例都接收全量的消息。其主要使用场景：刷新本地缓存。

广播消费模式适用于每条消息需要被消费组的每个消费者处理的场景，也就是说消费组内的每个消费者都会收到订阅Topic的全量消息，因此即使扩缩消费者数量也无法提升或降低消费能力，具体示例如下图所示。

1.3 顺序消费

消息有序指的是一类消息消费时，能按照发送的顺序来消费。例如：一个订单产生了三条消息分别是订单创建、订单付款、订单完成。消费时要按照这个顺序消费才能有意义，但是同时订单之间是可以并行消费的。RocketMQ可以严格的保证消息有序。

顺序消费的原理

在默认的情况下消息发送会采取Round Robin轮询方式把消息发送到不同的queue(分区队列)；而消费消息的时候从多个queue上拉取消息，这种情况发送和消费是不能保证顺序。

但是如果控制发送的顺序消息只依次发送到同一个queue中，消费的时候只从这个queue上依次拉取，则就保证了顺序。

全局有序（严格顺序消息）

对于指定的一个 Topic，所有消息按照严格的先入先出（FIFO）的顺序进行发布和消费。

当发送和消费参与的queue只有一个，则是全局有序，且先到的消息必须消费完才能消费后到的消息，显然性能是最差的。

适用场景：性能要求不高，所有的消息严格按照 FIFO 原则进行消息发布和消费的场景

分区有序（普通顺序消息）

对于指定的一个 Topic，所有消息根据 sharding key 进行区块分区。 同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费。 Sharding key 是顺序消息中用来区分不同分区的关键字段，和普通消息的 Key 是完全不同的概念。

适用场景：性能要求高，以 sharding key 作为分区字段，在同一个区块中严格的按照 FIFO 原则进行消息发布和消费的场景。

例如：一个订单产生了三条消息分别是订单创建、订单付款、订单完成，订单号相同的消息会被先后发送到同一个队列中，消费时，同一个OrderId获取到的肯定是同一个队列。

消费时要按照这个顺序消费才能有意义，但是同时订单之间是可以并行消费的。RocketMQ可以严格的保证消息有序。

顺序消费和并发消费的配置

RocketMQ提供了顺序消费的方式， 顺序消费设置与并发消费API层面只有一处不同，在注册消费回调接口时传入MessageListenerOrderly接口的实现。

consumer.registerMessageListener(new MessageListenerOrderly() {
            AtomicLong consumeTimes = new AtomicLong(0);
            @Override
            public ConsumeOrderlyStatus consumeMessage(List msgs, ConsumeOrderlyContext context) {
                System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
                this.consumeTimes.incrementAndGet();
                if ((this.consumeTimes.get() % 2) == 0) {
                    return ConsumeOrderlyStatus.SUCCESS;
                } else if ((this.consumeTimes.get() % 5) == 0) {
                    context.setSuspendCurrentQueueTimeMillis(3000);
                    return ConsumeOrderlyStatus.SUSPEND_CURRENT_QUEUE_A_MOMENT;
                }
                return ConsumeOrderlyStatus.SUCCESS;
            }
        });

而并发消费：是MessageListenerConcurrently的实现，其接口如下

public class Consumer {
  public static void main(String[] args) throws InterruptedException, MQClientException {
    // 初始化consumer，并设置consumer group name
    DefaultMQPushConsumer consumer = new DefaultMQPushConsumer("please_rename_unique_group_name");
   
    // 设置NameServer地址 
    consumer.setNamesrvAddr("localhost:9876");
    //订阅一个或多个topic，并指定tag过滤条件，这里指定*表示接收所有tag的消息
    consumer.subscribe("TopicTest", "*");
    //注册回调接口来处理从Broker中收到的消息
    consumer.registerMessageListener(new MessageListenerConcurrently() {
      @Override
      public ConsumeConcurrentlyStatus consumeMessage(List msgs, ConsumeConcurrentlyContext context) {
        System.out.printf("%s Receive New Messages: %s %n", Thread.currentThread().getName(), msgs);
        // 返回消息消费状态，ConsumeConcurrentlyStatus.CONSUME_SUCCESS为消费成功
        return ConsumeConcurrentlyStatus.CONSUME_SUCCESS;
      }
    });
    // 启动Consumer
    consumer.start();
    System.out.printf("Consumer Started.%n");
  }
}

思考

1.队列和消费者的关系？

一个队列除了广播模式下，只会在一个消费组下的一个实例消费，但一个消费者实例可以订阅消费同一topic下的多个队列。

1.3订阅与发布

消息的发布是指某个生产者向某个topic发送消息；消息的订阅是指某个消费者关注了某个topic中带有某些tag的消息，进而从该topic消费数据。

1.4 消息过滤

消息过滤是指消息生产者向Topic中发送消息时，设置消息属性对消息进行分类，消费者订阅Topic时，根据消息属性设置过滤条件对消息进行过滤，只有符合过滤条件的消息才会被投递到消费端进行消费。

消费者订阅Topic时若未设置过滤条件，无论消息发送时是否有设置过滤属性，Topic中的所有消息都将被投递到消费端进行消费。

RocketMQ支持的消息过滤方式有两种，Tag过滤和SQL92过滤。

消息过滤目前是在Broker端实现的，优点是减少了对于Consumer无用消息的网络传输，缺点是增加了Broker的负担、而且实现相对复杂。

1.Filter功能进行消息过滤

使用Filter功能，需要在启动配置文件当中配置以下选项

enablePropertyFilter=true

消费者将接收包含TAGA或TAGB或TAGC的消息。但是限制是一个消息只能有一个标签，这对于复杂的场景可能不起作用。在这种情况下，可以使用SQL表达式筛选消息。

SQL特性可以通过发送消息时的属性来进行计算。在RocketMQ定义的语法下，可以实现一些简单的逻辑，下面是一个例子

 ‐‐‐‐‐‐‐‐‐‐‐‐
2 | message |
3 |‐‐‐‐‐‐‐‐‐‐| a > 5 AND b = 'yangguo'
4 | a = 10 | ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐> Gotten
5 | b = 'abc'|
6 | c = true |
7 ‐‐‐‐‐‐‐‐‐‐‐‐
8 ‐‐‐‐‐‐‐‐‐‐‐‐
9 | message |
10 |‐‐‐‐‐‐‐‐‐‐| a > 5 AND b = 'yangguo'
11 | a = 1 | ‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐> Missed
12 | b = 'abc'|
13 | c = true |
14 ‐‐‐‐‐‐‐‐‐‐‐‐

2.RocketMQ TAG 过滤

以下图电商交易场景为例，从客户下单到收到商品这一过程会生产一系列消息，以如下消息为例：

• 订单消息
• 支付消息
• 物流消息

这些消息会发送到名称为Trade_Topic的Topic中，被各个不同的系统所订阅，以如下系统为例：

• 支付系统：只需订阅支付消息。
• 物流系统：只需订阅物流消息。
• 实时计算系统：需要订阅所有和交易相关的消息。
• 交易成功率分析系统：需订阅订单和支付消息。

过滤示意图如下所示

对于物流系统和支付系统来说，它们都只订阅单个Tag，此时只需要在调用subcribe接口时明确标明Tag即可。

consumer.subscribe("TagFilterTest", "TagA");

rocketmq-client包对订阅的时候有关注Tags，在消息到达的时候，按照订阅的tags进行过滤，用户监听消息的时候就只会收到自己关注的tag。

@see RocketMQ TAG 过滤原理 https://www.codeleading.com/article/8138673249/

1.5 消息可靠性机制

RocketMQ支持消息的高可靠，影响消息可靠性的几种情况：

1. Broker非正常关闭
2. Broker异常Crash
3. OS Crash
4. 机器掉电，但是能立即恢复供电情况
5. 机器无法开机（可能是cpu、主板、内存等关键设备损坏）
6. 磁盘设备损坏

1)、2)、3)、4) 四种情况都属于硬件资源可立即恢复情况，RocketMQ在这四种情况下能保证消息不丢，或者丢失少量数据（依赖刷盘方式是同步还是异步）。

5)、6)属于单点故障，且无法恢复，一旦发生，在此单点上的消息全部丢失。RocketMQ在这两种情况下，通过异步复制，可保证99%的消息不丢，但是仍然会有极少量的消息可能丢失。通过同步双写技术可以完全避免单点，同步双写势必会影响性能，适合对消息可靠性要求极高的场合，例如与Money相关的应用。注：RocketMQ从3.0版本开始支持同步双写。

1.Producer端消息发送几种方式

Sync：同步的发送方式，会等待发送结果后才返回。
Async：异步的发送方式，发送完后，立刻返回。Client 在拿到 Broker 的响应结果后，会回调指定的 callback（此时用户可以自定义是否要进行失败重发，以防止消息丢失）。 这个 API 也可以指定 Timeout，不指定也是默认的 3000ms.
Oneway：比较简单，发出去后，什么都不管直接返回。此方式可能会发生消息丢失。

消息重投机制

生产者在发送消息时，同步消息失败会重投，异步消息有重试，oneway没有任何保证。

消息重投保证消息尽可能发送成功、不丢失，但可能会造成消息重复，消息重复在RocketMQ中是无法避免的问题。消息重复在一般情况下不会发生，当出现消息量大、网络抖动，消息重复就会是大概率事件。另外，生产者主动重发、consumer负载变化也会导致重复消息。

如下方法可以设置发送端消息重试策略：

• retryTimesWhenSendFailed:同步发送失败重投次数，默认为2，因此生产者会最多尝试发送retryTimesWhenSendFailed + 1次。不会选择上次失败的broker，尝试向其他broker发送，最大程度保证消息不丢。超过重投次数，抛出异常，由客户端保证消息不丢。当出现RemotingException、MQClientException和部分MQBrokerException时会重投。
• retryTimesWhenSendAsyncFailed:异步发送失败重试次数，异步重试不会选择其他broker，仅在同一个broker上做重试，不保证消息不丢。
• retryAnotherBrokerWhenNotStoreOK:消息刷盘（主或备）超时或slave不可用（返回状态非SEND_OK），是否尝试发送到其他broker，默认false。十分重要消息可以开启。

2.RocketMQ broker消息刷盘机制

同步刷盘：

如上图所示，只有在消息真正持久化至磁盘后RocketMQ的Broker端才会真正返回给Producer端一个成功的ACK响应。

同步刷盘对MQ消息可靠性来说是一种不错的保障，但是性能上会有较大影响，一般适用于金融业务应用该模式较多。

异步刷盘：

能够充分利用OS的PageCache的优势，只要消息写入PageCache即可将成功的ACK返回给Producer端。

消息刷盘采用后台异步线程提交的方式进行，降低了读写延迟，提高了MQ的性能和吞吐量。但异步线程在执行数据同步到磁盘时如果出现失败，则有可能造成消息丢失。

默认为异步刷盘

另外如果要保证绝对的不丢失，要等master节点同步到从节点之后再发送ACK确认。

3.RocketMQ Consumer ACK机制

RocketMQ Consumer ACK默认是手动提交的。

消息消费后会返回ACK确认，如果没有收到ACK确认，回在重试队列重试。

 1.10 消息重试（重试队列）

Consumer消费消息失败后，要提供一种重试机制，令消息再消费一次。

Consumer消费消息失败通常可以认为有以下几种情况：

• 由于消息本身的原因，例如反序列化失败，消息数据本身无法处理（例如话费充值，当前消息的手机号被注销，无法充值）等。这种错误通常需要跳过这条消息，再消费其它消息，而这条失败的消息即使立刻重试消费，99%也不成功，所以最好提供一种定时重试机制，即过10秒后再重试。
• 由于依赖的下游应用服务不可用，例如db连接不可用，外系统网络不可达等。遇到这种错误，即使跳过当前失败的消息，消费其他消息同样也会报错。这种情况建议应用sleep 30s，再消费下一条消息，这样可以减轻Broker重试消息的压力。

RocketMQ内部封装了消息重试的处理流程，无需开发人员手动处理，并且支持了生产端、消费端两端的重试机制。

Consumer消费某条消息失败，则RocketMQ会在重试间隔时间后，将消息重新投递给Consumer消费，若达到最大重试次数后消息还没有成功被消费，则消息将被投递至死信队列

1.顺序消费和并发消费的重试机制

顺序消费和并发消费的重试机制并不相同，顺序消费消费失败后会先在客户端本地重试直到最大重试次数，这样可以避免消费失败的消息被跳过，消费下一条消息而打乱顺序消费的顺序。

而并发消费消费失败后会将消费失败的消息重新投递回服务端broker，再等待服务端重新投递回来，在这期间会正常消费队列后面的消息。

并发消费失败后并不是投递回原Topic，而是投递到一个特殊Topic，其命名为%RETRY%ConsumerGroupName。这和Kafka是不一样的，在这方面rocketMQ个人觉得是要优于Kafka的

集群模式下并发消费每一个ConsumerGroup会对应一个特殊Topic，并会订阅该Topic。 两者参数差别如下

 消费端并发消费消息重试配置

消息重试次数默认为16次，如果消息重试 16 次后仍然失败，消息将不再投递。

注意： 一条消息无论重试多少次，这些重试消息的 Message ID 不会改变。所以就需要我们消费者端做好消费幂等操作。

重试原理

RocketMQ会为每个消费组都设置一个Topic名称为“%RETRY%+consumerGroup”的重试队列（这里需要注意的是，这个Topic的重试队列是针对消费组，而不是针对每个Topic设置的），用于暂时保存因为各种异常而导致Consumer端无法消费的消息。

考虑到异常恢复起来需要一些时间，会为重试队列设置多个重试级别，每个重试级别都有与之对应的重新投递延时，重试次数越多投递延时就越大。

RocketMQ对于重试消息的处理是先保存至Topic名称为“SCHEDULE_TOPIC_XXXX”的延迟队列中，后台定时任务按照对应的时间进行Delay后重新保存至“%RETRY%+consumerGroup”的重试队列中。然后消息将重新路由到消费组中进行重试。

如果重试一直失败，消息该归为何处？

RocketMQ中消息重试超过一定次数后（默认16次）就会被放到死信队列中。

消息重试机制会引起消息堆积吗？

不会，顺序消费可能会，并发消费不会

生产和消费端重试对比：

1 默认重试次数：Product默认是2次，而Consumer默认是16次。

2 重试时间间隔：Product是立刻重试，而Consumer是有一定时间间隔的。

3 Product在异步情况重试失效，而对于Consumer在广播情况下重试失效。

1.13 死信队列

1.产生死信队列的条件

死信队列用于处理无法被正常消费的消息。当一条消息初次消费失败，消息队列会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明消费者在正常情况下无法正确地消费该消息，此时，消息队列 不会立刻将消息丢弃，而是将其发送到该消费者对应的特殊队列中。

RocketMQ将这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），将存储死信消息的特殊队列称为死信队列（Dead-Letter Queue），死信队列是死信Topic下分区数唯一的单独队列。

因此产生死信队列的条件时：超过重试阀值仍然无法被正常消费的消息

2.死信队列的定义

如果产生了死信消息，那对应的ConsumerGroup的死信Topic名称为%DLQ%ConsumerGroupName，死信队列的消息将不会再被消费，因为消费者没有订阅过该死信topic

可以利用RocketMQ Admin工具或者RocketMQ Dashboard上查询到对应死信消息的信息。

在RocketMQ中，可以通过使用console控制台对死信队列中的消息进行重发来使得消费者实例再次进行消费。

1.6 至少一次

至少一次(At least Once)指每个消息必须投递一次。Consumer先Pull消息到本地，消费完成后，才向服务器返回ack，如果没有消费一定不会ack消息，所以RocketMQ可以很好的支持此特性。

这种机制也可以处理消费端消息丢失的问题。

1.7 回溯消费

回溯消费是指Consumer已经消费成功的消息，由于业务上需求需要重新消费，要支持此功能，Broker在向Consumer投递成功消息后，消息仍然需要保留。

并且重新消费一般是按照时间维度，例如由于Consumer系统故障，恢复后需要重新消费1小时前的数据，那么Broker要提供一种机制，可以按照时间维度来回退消费进度。

RocketMQ支持按照时间回溯消费，时间维度精确到毫秒。

消费点位

当建立一个新的消费者组时，需要决定是否需要消费已经存在于 Broker 中的历史消息
 org.apache.rocketmq.common.consumer.ConsumeFromWhere
 CONSUME_FROM_LAST_OFFSET 将会忽略历史消息，并消费之后生成的任何消息。
 CONSUME_FROM_FIRST_OFFSET 将会消费每个存在于 Broker 中的信息。你也可以使用
 CONSUME_FROM_TIMESTAMP 来消费在指定时间戳后产生的消息。

1.8 事务消息

1.定位

RocketMQ事务消息（Transactional Message）是指应用本地事务和发送消息操作可以被定义到全局事务中，要么同时成功，要么同时失败。

rocketmq的事务消息只能保证本地事务和消息发送流程的原子性，不能保证消费端后续流程的原子性，如果消费端事务消费失败，则只能通过补偿的方式来保证双方的一致性

RocketMQ的事务消息提供类似 X/Open XA 的分布事务功能，通过事务消息能达到分布式事务的最终一致。

最终一致性

RocketMQ是一种最终一致性的分布式事务，就是说它保证的是消息最终一致性，而不是像2PC、3PC、TCC那样强一致分布式事务，至于为什么说它是最终一致性事务下面会详细说明。

2.核心术语

Half Message(半消息)

是指暂不能被Consumer消费的消息。Producer 已经把消息成功发送到了 Broker 端，但此消息被标记为暂不能投递状态，处于该种状态下的消息称为半消息。需要 Producer对消息的二次确认后，Consumer才能去消费它。

消息回查

由于网络闪段，生产者应用重启等原因。导致 Producer 端一直没有对 Half Message(半消息) 进行 二次确认。这是Brock服务器会定时扫描长期处于半消息的消息，会主动询问 Producer端 该消息的最终状态(Commit或者Rollback),该消息即为 消息回查。

3.RocketMQ实现分布式事务原理

Apache RocketMQ在4.3.0版中已经支持分布式事务消息，这里RocketMQ采用了2PC的思想来实现了提交事务消息，同时增加一个补偿逻辑来处理二阶段超时或者失败的消息。

如下图所示。

上图说明了事务消息的大致方案，其中分为两个流程：正常事务消息的发送及提交、事务消息的补偿流程。

1.事务消息发送及提交：

(1) 发送消息（half消息）。

(2) 服务端响应消息写入结果。

(3) 根据发送结果执行本地事务（如果写入失败，此时half消息对业务不可见，本地逻辑不执行）。

(4) 根据本地事务状态执行Commit或者Rollback（Commit操作生成消息索引，消息对消费者可见）

2.补偿流程：

(1) 对没有Commit/Rollback的事务消息（pending状态的消息），从服务端发起一次“回查”

(2) Producer收到回查消息，检查回查消息对应的本地事务的状态

(3) 根据本地事务状态，重新Commit或者Rollback

其中，补偿阶段用于解决消息Commit或者Rollback发生超时或者失败的情况。

思考

1.事务消息在一阶段如何对用户不可见？

在RocketMQ事务消息的主要流程中，一阶段的消息如何对用户不可见。其中，事务消息相对普通消息最大的特点就是一阶段发送的消息对用户是不可见的。那么，如何做到写入消息但是对用户不可见呢？

RocketMQ事务消息的做法是：如果消息是half消息，将备份原消息的主题与消息消费队列，然后改变主题为RMQ_SYS_TRANS_HALF_TOPIC。

由于消费组未订阅该主题，故消费端无法消费half类型的消息，然后RocketMQ会开启一个定时任务，从Topic为RMQ_SYS_TRANS_HALF_TOPIC中拉取消息并从生产者组获取一个服务提供者发送回查事务状态请求，根据事务状态来决定是提交或回滚消息。

在RocketMQ中，消息在服务端的存储结构如下，每条消息都会有对应的索引信息，Consumer通过ConsumeQueue这个二级索引来读取消息实体内容，其流程如下：

RocketMQ的具体实现策略是：写入的如果事务消息，对消息的Topic和Queue等属性进行替换，同时将原来的Topic和Queue信息存储到消息的属性中，正因为消息主题被替换，故消息并不会转发到该原主题的消息消费队列，消费者无法感知消息的存在，不会消费。

其实改变消息主题是RocketMQ的常用“套路”，回想一下延时消息的实现机制。

我自己总结起来就是：topic临时变了，其他的如Queue里面的消息都未改变，当消息可用发出去时，broker将RMQ_SYS_TRANS_HALF_TOPIC里面的消息写入到真实的topic上去。

2.Commit和Rollback操作如何对用户可见？

在完成一阶段写入一条对用户不可见的消息后，二阶段如果是Commit操作，则需要让消息对用户可见；如果是Rollback则需要撤销一阶段的消息。

先说Rollback的情况。对于Rollback，本身一阶段的消息对用户是不可见的，其实不需要真正撤销消息（实际上RocketMQ也无法去真正的删除一条消息，因为是顺序写文件的）。

但是区别于这条消息没有确定状态（Pending状态，事务悬而未决），需要一个操作来标识这条消息的最终状态。

RocketMQ事务消息方案中引入了Op消息的概念，用Op消息标识事务消息已经确定的状态（Commit或者Rollback）。如果一条事务消息没有对应的Op消息，说明这个事务的状态还无法确定（可能是二阶段失败了）。引入Op消息后，事务消息无论是Commit或者Rollback都会记录一个Op操作。Commit相对于Rollback只是在写入Op消息前创建Half消息的索引。

3.Op消息的底层实现？

RocketMQ将Op消息写入到全局一个特定的Topic中通过源码中的方法—TransactionalMessageUtil.buildOpTopic()；

这个Topic是一个内部的Topic（像Half消息的Topic一样），不会被用户消费。Op消息的内容为对应的Half消息的存储的Offset，这样通过Op消息能索引到Half消息进行后续的回查操作。

4.Half消息的如何流转到真正的消费队列里面去的？

在执行二阶段Commit操作时，需要构建出Half消息的索引。

一阶段的Half消息由于是写到一个特殊的Topic，所以二阶段构建索引时需要读取出Half消息，并将Topic和Queue替换成真正的目标的Topic和Queue，之后通过一次普通消息的写入操作来生成一条对用户可见的消息。

所以RocketMQ事务消息二阶段其实是利用了一阶段存储的消息的内容，在二阶段时恢复出一条完整的普通消息，然后走一遍消息写入流程。

5.如何处理二阶段失败的消息？

如果在RocketMQ事务消息的二阶段过程中失败了，例如在做Commit操作时，出现网络问题导致Commit失败，那么需要通过一定的策略使这条消息最终被Commit。

RocketMQ采用了一种补偿机制，称为“回查”。

Broker端对未确定状态的消息发起回查，将消息发送到对应的Producer端（同一个Group的Producer），由Producer根据消息来检查本地事务的状态，进而执行Commit或者Rollback。

Broker端通过对比Half消息和Op消息进行事务消息的回查并且推进CheckPoint（记录那些事务消息的状态是确定的）。

值得注意的是，rocketmq并不会无休止的的信息事务状态回查，默认回查15次，如果15次回查还是无法得知事务状态，rocketmq默认回滚该消息。

6.在二阶段消息commit后，消费者事务执行失败怎么办？

基于rocketmq的特性，消费者消费失败，会进行消息重拾，如果消息重拾达到阈值后还是没有成功，则可通过手动的等方式去维护消费端业务使其成功。

1.9 延迟队列

定时消息（延迟队列）是指消息发送到broker后，不会立即被消费，等待特定时间投递给真正的topic。

broker有配置项messageDelayLevel（即自己实现了延迟队列），默认值为“1s 5s 10s 30s 1m 2m 3m 4m 5m 6m 7m 8m 9m 10m 20m 30m 1h 2h”，18个level。可以配置自定义messageDelayLevel。

注意，messageDelayLevel是broker的属性，不属于某个topic。发消息时，设置delayLevel等级即可：msg.setDelayLevel(level)。level有以下三种情况：

• level == 0，消息为非延迟消息
• 1<=level<=maxLevel，消息延迟特定时间，例如level==1，延迟1s
• level > maxLevel，则level== maxLevel，例如level==20，延迟2h

1.rocketmq实现延迟队列原理

定时消息会暂存在名为SCHEDULE_TOPIC_XXXX的topic中，并根据delayTimeLevel存入特定的queue，queueId = delayTimeLevel – 1，即一个queue只存相同延迟的消息，保证具有相同发送延迟的消息能够顺序消费。broker会调度地消费SCHEDULE_TOPIC_XXXX，将消息写入真实的topic。

需要注意的是，定时消息会在第一次写入和调度写入真实topic时都会计数，因此发送数量、tps都会变高。

1.12 流量控制

生产者流控，因为broker处理能力达到瓶颈；消费者流控，因为消费能力达到瓶颈。

生产者流控：

• commitLog文件被锁时间超过osPageCacheBusyTimeOutMills时，参数默认为1000ms，返回流控。
• 如果开启transientStorePoolEnable == true，且broker为异步刷盘的主机，且transientStorePool中资源不足，拒绝当前send请求，返回流控。
• broker每隔10ms检查send请求队列头部请求的等待时间，如果超过waitTimeMillsInSendQueue，默认200ms，拒绝当前send请求，返回流控。
• broker通过拒绝send 请求方式实现流量控制。

注意，生产者流控，不会尝试消息重投。

消费者流控：

• 消费者本地缓存消息数超过pullThresholdForQueue时，默认1000。
• 消费者本地缓存消息大小超过pullThresholdSizeForQueue时，默认100MB。
• 消费者本地缓存消息跨度超过consumeConcurrentlyMaxSpan时，默认2000。

消费者流控的结果是降低拉取频率。

四、底层核心实现原理

1.消息存储底层实现

消息存储是RocketMQ中最为复杂和最为重要的一部分，本节将分别从RocketMQ的消息存储整体架构、PageCache与Mmap内存映射以及RocketMQ中两种不同的刷盘方式三方面来分别展开叙述。

RocketMQ主要的存储文件包括commitlog文件、consumequeue文件、indexfile文件。

Broker在收到消息之后，会把消息保存到commitlog的文件当中。
同时在分布式的存储当中，每个broker都会保存一部分topic的数据，同时，每个topic对应的messagequeue队列下都会生成consumequeue文件用于保存commitlog的物理位置偏移量offset。
indexfile中会保存key和offset的对应关系。
 

1.消息存储整体架构

(1) CommitLog：消息主体以及元数据的存储主体，存储Producer端写入的消息主体内容,消息内容不是定长的。
单个文件大小默认1G ，文件名长度为20位，左边补零，剩余为起始偏移量，比如00000000000000000000代表了第一个文件，起始偏移量为0，文件大小为1G=1073741824；
当第一个文件写满了，第二个文件为00000000001073741824，起始偏移量为1073741824，以此类推。消息主要是顺序写入日志文件，当文件满了，写入下一个文件；

CommitLog文件保存于${Rocket_Home}/store/commitlog目录中。

(2) ConsumeQueue：消息消费队列，引入的目的主要是提高消息消费的性能，由于RocketMQ是基于主题topic的订阅模式，消息消费是针对主题进行的，如果要遍历commitlog文件中根据topic检索消息是非常低效的。

Consumer即可根据ConsumeQueue来查找待消费的消息。

其中，ConsumeQueue（逻辑消费队列）作为消费消息的索引，保存了指定Topic下的队列消息在CommitLog中的起始物理偏移量offset，消息大小size和消息Tag的HashCode值。

consumequeue文件可以看成是基于topic的commitlog索引文件，故consumequeue文件夹的组织方式如下：
topic/queue/file三层组织结构，具体存储路径为：$HOME/store/consumequeue/{topic}/{queueId}/{fileName}。

消费者在消费的时候先从consumequeue中根据偏移量定位到具体的commitlog物理文件，然后根据一定的规则（offset和文件大小取模）在commitlog中快速定位。

同样consumequeue文件采取定长设计，每一个条目共20个字节，分别为8字节的commitlog物理偏移量、4字节的消息长度、8字节tag hashcode，单个文件由30W个条目组成，可以像数组一样随机访问每一个条目，每个ConsumeQueue文件大小约5.72M；

(3) IndexFile：IndexFile（索引文件）提供了一种可以通过key或时间区间来查询消息的方法。
Index文件的存储位置是：$HOME \store\index${fileName}，文件名fileName是以创建时的时间戳命名的，固定的单个IndexFile文件大小约为400M，一个IndexFile可以保存 2000W个索引。
IndexFile的底层存储设计为在文件系统中实现HashMap结构，故rocketmq的索引文件其底层实现为hash索引。

在上面的RocketMQ的消息存储整体架构图中可以看出，RocketMQ采用的是混合型的存储结构，即为Broker单个实例下所有的队列共用一个日志数据文件（即为CommitLog）来存储。
RocketMQ的混合型存储结构(多个Topic的消息实体内容都存储于一个CommitLog中)针对Producer和Consumer分别采用了数据和索引部分相分离的存储结构，Producer发送消息至Broker端，然后Broker端使用同步或者异步的方式对消息刷盘持久化，保存至CommitLog中。
只要消息被刷盘持久化至磁盘文件CommitLog中，那么Producer发送的消息就不会丢失。正因为如此，Consumer也就肯定有机会去消费这条消息。
当无法拉取到消息后，可以等下一次消息拉取，同时服务端也支持长轮询模式，如果一个消息拉取请求未拉取到消息，Broker允许等待30s的时间，只要这段时间内有新消息到达，将直接返回给消费端。
这里，RocketMQ的具体做法是，使用Broker端的后台服务线程—ReputMessageService不停地分发请求并异步构建ConsumeQueue（逻辑消费队列）和IndexFile（索引文件）数据。

页缓存与内存映射

页缓存（PageCache)是OS对文件的缓存，用于加速对文件的读写。
一般来说，程序对文件进行顺序读写的速度几乎接近于内存的读写速度，主要原因就是由于OS使用PageCache机制对读写访问操作进行了性能优化，将一部分的内存用作PageCache。
对于数据的写入，OS会先写入至Cache内，随后通过异步的方式由pdflush内核线程将Cache内的数据刷盘至物理磁盘上。
对于数据的读取，如果一次读取文件时出现未命中PageCache的情况，OS从物理磁盘上访问读取文件的同时，会顺序对其他相邻块的数据文件进行预读取。

在RocketMQ中，ConsumeQueue逻辑消费队列存储的数据较少，并且是顺序读取，在page cache机制的预读取作用下，Consume Queue文件的读性能几乎接近读内存，即使在有消息堆积情况下也不会影响性能。
而对于CommitLog消息存储的日志数据文件来说，读取消息内容时候会产生较多的随机访问读取，严重影响性能。如果选择合适的系统IO调度算法，比如设置调度算法为“Deadline”（此时块存储采用SSD的话），随机读的性能也会有所提升。

另外，RocketMQ主要通过MappedByteBuffer对文件进行读写操作。

其中，利用了NIO中的FileChannel模型将磁盘上的物理文件直接映射到用户态的内存地址中（这种Mmap的方式减少了传统IO将磁盘文件数据在操作系统内核地址空间的缓冲区和用户应用程序地址空间的缓冲区之间来回进行拷贝的性能开销）。
将对文件的操作转化为直接对内存地址进行操作，从而极大地提高了文件的读写效率（正因为需要使用内存映射机制，故RocketMQ的文件存储都使用定长结构来存储，方便一次将整个文件映射至内存）。

3.消息删除机制

为了避免内存与磁盘的浪费，RocketMQ有专门的删除机制来删除过期的文件。

消息消费队列文件与消息存储文件（ Commitlog ）共用一套过期文件机制。

清理的逻辑

如果非当前写文件在一定时间间隔内没有再次被更新，则认为是过期文件，可以被删除， RocketMQ 不会关注这个文件上的消息是否全部被消费。通过在 Broker配置文件中设置 fileReservedTime 来改变过期时间，默认为48，单位为小时。触发文件清除操作的是一个定时任务，而且只有定时任务可以执行这个操作，默认每 10s 执行一次。

过期判断
fileReservedTime是允许文件保留的最长时间，当文件最后一次更新的时间到现在的时间超过这个时间了。那么这个文件将被删除。

还有两个参数：

• deletePhysicFilesInterval：删除间隔默认100ms，若是有多个文件同时过期，并不会同时删除多个文件，而是间隔deletePhysicFilesInterval时间后继续删除。
• destroyMapedFileIntervalForcibly：当删除某个文件的时候，若是该文件还在被引用，将阻止删除操作。destroyMapedFileIntervalForcibly则表示当第一次删除拒绝之后，删除免疫的时间，在这个时间内将一直拒绝删除，超过这个时间之后，则可以被删除。
   

删除条件

1.指定时间删除
可以通过deleteWhen设置一天执行一次删除文件的操作，默认是凌晨4点。

2.磁盘满删除
DiskSpaceCleanForciblyRatio参数是磁盘占用的阈值。

检查磁盘是否充足，若是磁盘占用超过百分之85(默认)，则会触发过期文件删除操作。
 

参考资料

1.RocketMQ中的消息存储结构及删除机制_rocketmq 删除消息_π大星的日常的博客-CSDN博客

 

2.零拷贝技术

磁盘数据拷贝流程

以文件下载为例，服务端的主要任务是：
将服务端主机磁盘中的文件不做修改地从已连接的socket发出去

我们通常用下面的代码完成：

while((n = read(diskfd, buf, BUF_SIZE)) > 0)
    write(sockfd, buf , n);

基本操作就是循环的从磁盘读入文件内容到缓冲区，再将缓冲区的内容发送到socket。
但是由于Linux的I/O操作默认是缓冲I/O。这里面主要使用的也就是read和write两个系统调用，我们并不知道操作系统在其中做了什么。实际上在以上I/O操作中，发生了多次的数据拷贝。

操作系统底层I/O过程如下图所示：

当应用程序访问某块数据时，操作系统首先会检查，是不是最近访问过此文件，文件内容是否缓存在内核缓冲区，
如果是，操作系统则直接根据read系统调用提供的buf地址，将内核缓冲区的内容拷贝到buf所指定的用户空间缓冲区中去。
如果不是，操作系统则首先将磁盘上的数据拷贝的内核缓冲区，这一步目前主要依靠DMA来传输，然后再把内核缓冲区上的内容拷贝到用户缓冲区中。
接下来，write系统调用再把用户缓冲区的内容拷贝到网络堆栈相关的内核缓冲区中，最后socket再把内核缓冲区的内容发送到网卡上。

什么是零拷贝技术？

零拷贝主要的任务就是避免CPU将数据从一块存储拷贝到另外一块存储。
主要就是利用各种零拷贝技术，避免让CPU做大量的数据拷贝任务，减少不必要的拷贝，或者让别的组件来做这一类简单的数据传输任务，让CPU解脱出来专注于别的任务。
这样就可以让系统资源的利用更加有效。

实现原理

应用程序调用mmap()，磁盘上的数据会通过DMA被拷贝的内核缓冲区，接着操作系统会把这段内核缓冲区与应用程序共享，这样就不需要把内核缓冲区的内容往用户空间拷贝。
应用程序再调用write(),操作系统直接将内核缓冲区的内容拷贝到socket缓冲区中，这一切都发生在内核态，最后，socket缓冲区再把数据发到网卡去。

消息查询

RocketMQ支持按照下面两种维度（“按照Message Id查询消息”、“按照Message Key查询消息”）进行消息查询。

1. 按照MessageId查询消息

RocketMQ中的MessageId的长度总共有16字节，其中包含了消息存储主机地址（IP地址和端口），消息Commit Log offset。“按照MessageId查询消息”在RocketMQ中具体做法是：Client端从MessageId中解析出Broker的地址（IP地址和端口）和Commit Log的偏移地址后封装成一个RPC请求后通过Remoting通信层发送（业务请求码：VIEW_MESSAGE_BY_ID）。Broker端走的是QueryMessageProcessor，读取消息的过程用其中的 commitLog offset 和 size 去 commitLog 中找到真正的记录并解析成一个完整的消息返回。

6.2 按照Message Key查询消息

“按照Message Key查询消息”，主要是基于RocketMQ的IndexFile索引文件来实现的。RocketMQ的索引文件逻辑结构，类似JDK中HashMap的实现。索引文件的具体结构如下：

IndexFile索引文件为用户提供通过“按照Message Key查询消息”的消息索引查询服务，IndexFile文件的存储位置是：$HOME\store\index${fileName}，文件名fileName是以创建时的时间戳命名的，文件大小是固定的，等于40+500W*4+2000W*20= 420000040个字节大小。如果消息的properties中设置了UNIQ_KEY这个属性，就用 topic + “#” + UNIQ_KEY的value作为 key 来做写入操作。如果消息设置了KEYS属性（多个KEY以空格分隔），也会用 topic + “#” + KEY 来做索引。

其中的索引数据包含了Key Hash/CommitLog Offset/Timestamp/NextIndex offset 这四个字段，一共20 Byte。NextIndex offset 即前面读出来的 slotValue，如果有 hash冲突，就可以用这个字段将所有冲突的索引用链表的方式串起来了。Timestamp记录的是消息storeTimestamp之间的差，并不是一个绝对的时间。整个Index File的结构如图，40 Byte 的Header用于保存一些总的统计信息，4*500W的 Slot Table并不保存真正的索引数据，而是保存每个槽位对应的单向链表的头。20*2000W 是真正的索引数据，即一个 Index File 可以保存 2000W个索引。

“按照Message Key查询消息”的方式，RocketMQ的具体做法是，主要通过Broker端的QueryMessageProcessor业务处理器来查询，读取消息的过程就是用topic和key找到IndexFile索引文件中的一条记录，根据其中的commitLog offset从CommitLog文件中读取消息的实体内容。

五、高可用探究

1.为什么RocketMQ不使用Zookeeper作为注册中心呢？

我认为有以下几个点是不使用zookeeper的原因：

1.保证可用性牺牲数据一致性

2.zk写的性能太差

3.RocketMQ弱依赖于注册中心

以下为详细解释

• 根据CAP理论，同时最多只能满足两个点，而zookeeper满足的是CP，也就是说zookeeper并不能保证服务的可用性，zookeeper在进行选举的时候，整个选举的时间太长，期间整个集群都处于不可用的状态，而这对于一个注册中心来说肯定是不能接受的，作为服务发现来说就应该是为可用性而设计。
• 基于性能的考虑，NameServer本身的实现非常轻量，而且可以通过增加机器的方式水平扩展，增加集群的抗压能力，而zookeeper的写是不可扩展的，而zookeeper要解决这个问题只能通过划分领域，划分多个zookeeper集群来解决，首先操作起来太复杂，其次这样还是又违反了CAP中的A的设计，导致服务之间是不连通的。
• 持久化的机制来带的问题，ZooKeeper 的 ZAB 协议对每一个写请求，会在每个 ZooKeeper 节点上保持写一个事务日志，同时再加上定期的将内存数据镜像（Snapshot）到磁盘来保证数据的一致性和持久性，而对于一个简单的服务发现的场景来说，这其实没有太大的必要，这个实现方案太重了。而且本身存储的数据应该是高度定制化的。
• 消息发送应该弱依赖注册中心，而RocketMQ的设计理念也正是基于此，生产者在第一次发送消息的时候从NameServer获取到Broker地址后缓存到本地，如果NameServer整个集群不可用，短时间内对于生产者和消费者并不会产生太大影响。

2.rocketmq主从同步原理

消息在master和slave之间的同步是根据raft协议来进行的：

1. 在broker收到消息后，会被标记为uncommitted状态
2. 然后会把消息发送给所有的slave
3. slave在收到消息之后返回ack响应给master
4. master在收到超过半数的ack之后，把消息标记为committed
5. 发送committed消息给所有slave，slave也修改状态为committed

3.RocketMQ为什么速度这么快？

主要使用了顺序存储、Page Cache和异步刷盘等机制

1. 我们在写入commitlog的时候是顺序写入的，这样比随机写入的性能就会提高很多

2. 写入commitlog的时候并不是直接写入磁盘，而是先写入操作系统的PageCache

3. 最后由操作系统异步将缓存中的数据刷到磁盘

4.RocketMQ消费者负载均衡

集群模式下，同一个消费组内的消费者会分担收到的全量消息，这里的分配策略是怎样的？如果扩容消费者是否一定能提升消费能力？

Apache RocketMQ 提供了多种集群模式下的分配策略，包括平均分配策略、机房优先分配策略、一致性hash分配策略等，可以通过如下代码进行设置相应负载均衡策略

默认的分配策略是平均分配，这也是最常见的策略。平均分配策略下消费组内的消费者会按照类似分页的策略均摊消费。

在平均分配的算法下，可以通过增加消费者的数量来提高消费的并行度。比如下图中，通过增加消费者来提高消费能力。

参考文献

1.RocketMQ中文官方文档 rocketmq/docs/cn at master · apache/rocketmq · GitHub

2.https://blog.csdn.net/yucaifu1989/article/details/81364758

3.RocketMQ中文官方文档