分布式消息队列 RocketMQ

第1章 RocketMQ 概述

一、MQ概述

1. MQ简介

MQ，Message Queue，是一种提供消息队列服务的中间件，是一套提供了消息生产、存储、消费全过程API的软件系统。消息即数据。一般消息的体量都不会很大。

2. MQ用途

从网上可以查到很多MQ用途的信息，总结起来主要为以下三点

限流消峰

MQ可以讲系统的超量请求暂存其中，以便后期可以慢慢进行处理，从而避免了请求的丢失或系统被压垮。

异步解耦

上游系统对下游系统的调用若为同步调用，则会大大降低系统的吞吐量与并发度，且系统耦合太高。而异步调用则会解决这一问题，所以两层之间若要由同步到异步的转化，一般性做法就是在这两层间添加一个MQ层。

数据收集

分布式系统会产生海量数据，如：业务日志、监控数据、用户行为等。针对这些数据流进行实时或批量采集汇总，然后对这些数据流进行大数据分析，这是当前互联网平台的必备技术。通过mq完成此类数据收集是较好的选择。

3. 常见MQ产品

ActiveMQ

ActiveMQ是使用Java开发的MQ产品。早起很多公司与项目中都在使用。但现在社区活跃度已经很低。

RabbitMQ

RabbitMQ是使用ErLang语言开发的MQ产品。其吞吐量较Kafka、RocketMQ要低，但由于其不是Java语言开发，所以在Java项目中对其定制化开发的难度较大。

Kafka

Kafka是使用Scalc/Java语言开发的MQ产品。其最大的特点就是高吞吐量，常用语大数据领域的实时计算、日志采集等场景。它没有遵循任何常见的MQ协议，而是使用自研协议。对于SpringCloud Netflix，它仅支持 RabbitMQ与Kafka。

RocketMQ

RocketMQ是使用Java开发的MQ产品。经过数年阿里双11的考验，性能与稳定性都非常高。它没有准讯任何常见的MQ协议，而是使用自研协议。对于SpringCloud Alibaba，它仅支持 RabbitMQ与Kafka，但是建议使用RocketMQ。

对比

关键词	ActiveMQ	RabbitMQ	Kafka	RocketMQ
开发语言	Java	ErLang	Java	Java
单机吞吐量	万级	万级	十万级	十万级
Topic	-	-	百级Topic时会影响系统吞吐量	千级Topic时会影响系统吞吐量
社区活跃度	低	高	高	高

4. 常见MQ协议

一般情况下MQ的实现是要遵循一些常规性协议的，常见协议如下：

JMS

JMS，Java Messaging Service，是Java平台上有关MOM的技术规范，它便于消息系统中的Java应用程序进行信息交换，并且通过提供标准的生产、发送、接受消息的接口，简化企业应用的开发。ActiveMQ是它的典型实现。

STOMP

STOMP，Streaming Text Orientated Message Protocol面向流文本的消息协议，是一种MOM设计的简单文本协议。STOME提供一个可互操作的连接格式，允许客户端与任意STOMP消息代理Broker进行交互。ActiveMQ是它的典型实现，RabbitMQ通过插件可以支持该协议。

AMQP

AMQP，Advanced Message Queuing Protocol 高级消息队列协议，一个提供消息服务的应用层标准，是应用层协议的一个开放标准，是一种MOM设计。基于它的客户端与消息中间件可传递消息，并不受客户端/中间件不同产品，不同开发语言等条件限制。RabbitMQ是它的典型实现。

MQTT

MQTT，Message Queuing Telemetry Transport消息队列遥测传输，是IBM开发的一个即时通讯协议，是一种二进制协议，主要用于服务器和低功耗IoT设备间的通信。他支持所有平台，几乎可以把所有联网物品和外部连接起来，被用来当作传感器和致动器的通信协议。RabbitMQ通过插件可以支持该协议。

二、RocketMQ概述

1. RocketMQ简介

RocketMQ是一个统一的消息引擎、轻量级数据处理平台。

RocketMQ是阿里开源的消息中间件。2016年11月，阿里向Apache软件基金会捐赠RocketMQ，成为Apache孵化项目。2017年9月，Apache宣布RocketMQ孵化成为Apache顶级项目，成为国内首个互联网中间件在Apache上的顶级项目。

2. RocketMQ发展历程

2007年，阿里开始五彩石项目，Notify作为项目中交易核心消息流转系统，应运而生。Notify系统是RocketMQ的雏形。

2010年，B2B大规模使用ActiveMQ作为阿里的消息内核。阿里继续一个具有海量堆积能力的消息系统。

2011年初，Kafka开源。淘宝中间件技术团队在对Kafka进行了深入研究后，开发了一款新的MQ，MetaQ。

2012年，MetaQ发展到v3.0版本，在其基础上进行了进一步的抽象（具有一般化），形成了RocketMQ，随后就将其开源。

2015年，阿里在RocketMQ的基础上，又退出了一款专门针对阿里云上用户的消息系统Aliware MQ。

2016年11月28日（双十一后），RocketMQ承载了亿万级消息流转，跨越了一个新的里程碑。阿里向Apache软件基金会捐赠了RocketMQ，成为Apache孵化项目。

2017年9月25日，Apache宣布RocketMQ孵化成为Apache顶级项目，成为国内首个互联网中间件在Apache上的顶级项目。

第2章 RocketMQ 的安装与启动

一、基本概念

1. 消息（Message）

消息是指，消息系统所传输信息的物理载体，生产和消费数据的最小单位，每条消息必须属于一个主题。

2. 主题（Topioc）

Topic表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。Topic:message=1:n ,message:topic=1:1

一个生产者可以同时发送多种Topic消息；而一个消费者只能对某种特定的Topic感兴趣，即只可以订阅和消费一种Topic消息。producer:topic=1:1, consumer:topic=1:1

3. 标签（Tag）

不管是RocketMQ 的 Tag过滤还是延迟消息等都会利用 Prooerties 消息属性机制，这些特殊信息使用了系统保留的属性Key，设置自定义属性时需要避免和系统属性Key冲突。

4.队列（Queue）

存储消息的物理实体。一个Topic中可以包含多个Queue，每个Queue中存放的就是该Topic的消息。一个Topic的Queue也被称为一个Topic中消息的分区（Partition）。

一个Topic的Queue中的消息只能被一个消费者消费。一个Queue中的消息不允许同一个消费者组中的多个消费者同时消费。

在学习参考相关资料时，还会看到一个概念：分片（Sharding），分片不同于分区。在RocketMQ中，分片指的是存放相应Topic的Broker的数量。每个分片中会创建出相应数量的分区，即Queue，每个Queue的大小都是相同的。

5. 消息标识（MessageId/Key）

RocketMQ中每个消息拥有唯一的MessageId，且可以携带具有业务的Key，以方便消息的查询。不过需要注意的是，MessageId有两个：在生产者send()消息时会自动生成一个MessageId（msgId），当消息到达Broker后，Broker也会自动生成一个MessageId（offsetMsgId）。msgId、offsetMsgId与key都称为消息标识。

msgId：由product端生成，其生成规则为：

producerIp+ 进程pid + MessageClientIDSetter类的ClassLoader的hashCode + 当前时间 + AutomicInteger自增计数器
offsetMsgId：由Broker端生成，其生成规则为：

brokerIp + 物理分区的offset（Queue中的偏移量）
key：由用户指定的业务相关的唯一标识

二、系统架构

RocketMQ架构上主要分为四部分构成：

1. Producer

消息生产者，负责生产消息。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。

例如，业务系统生产的日志写入到MQ的过程，就是消息生产的过程

再如，电商平台中用户提交的秒杀请求写入到MQ的过程，就是消息生产的过程

RockerMQ中的消息生产者都是以生产组（Producer Group）的形式出现的。生产者组是同一类生产者的集合，这类Producer发送相同的Topic类型的消息。一个生产者组可以同时发送多个主题的消息

2. Consumer

消息消费者，负责消息消费。一个消费者会从Broker服务器中获取到消息，并对消息进行相关业务处理。

Qos系统从MQ中读取日志，并对日志进行解析处理的过程就是消息消费的过程。

再如，电商平台的业务系统从MQ中读取到秒杀请求，并对请求进行处理的过程就是消费的过程

RockerMQ中的消费者都是以消费组（Comsumer Group）的形式出现的。消费者组是同一类消费者的集合，这类Consumer消费的是同一个Topic类型的消息。消费者组使得在消息消费方面，实现负载均衡（将一个Topic中的不同的Queue平均分配给不同的Consumer）和容错（一个Consumer挂了，改Consumer Group中的其他Consumer可以接着消费原Consumer消费的Queue）的目标变得非常容易。

消费者组中Consumer的数量应该小于等于订阅Topic的Queue数量。如果超出Queue数量，则多处的Consumer将不能消费信息。

不过，一个Topic类型的消息可以被多个消费者组同时消费。

[!CAUTION]

一个消费者组中的消费者必须订阅完全相同的Topic

消费者只能消费一个Topic的消息，不能同时消费多个Topic消息

3 Name Server

功能介绍

NameServer时一个Broker与Topic路由的注册中心，支持Broker的动态注册与发现。

[!IMPORTANT]

在MetaQ v1.0与v2.0版本中，依赖的仍是Zookeeper。从MetaQ v3.0，即RocketMQ开始去掉了Zookeeper依赖，使用了自己的NameServer

RocketMQ的思想来自于Kafka，而Kafka是依赖于Zookeeper的，所以在RocketMQ的早期版本（MetaQ）中，也是依赖于Zookeeper的

主要包括两个功能：

Broker管理：
- 接受Broker集群的注册信息并且保存下来作为路由信息的基本数据
- 提供心跳检测机制，检查Broker是否还存活
路由信息管理：
- 每个NamerServer中都保存着Broker集群的整个路由信息和用于客户端查询的队列信息
- Producer和Consumer通过NameServer可以获取整个Broker集群的路由信息，从而进行消息的投递和消费

路由注册

NameServer通常也是以集群方式部署，不过，NameServer是无状态的，即NameServer集群中的各个节点是无差异的，各节点间相互不进行信息通讯。各个节点中的数据是如何进行同步的呢？在Broker节点启动时，轮训NameServer列表，与每个NameServer节点建立长连接，发起注册请求。在NameServer内部维护着一个Broker列表，用来动态存储Broker信息。

[!CAUTION]

这是与其他像Zookeeper、Eureka、Nacos等注册中心不同的地方

这种NameServer的无状态方式的优缺点：

优点

NameServer集群搭建简单

缺点

对于Broker，必须明确指出所有NameServer地址，否则未指出的将不会注册

NameServer并不能随便扩容，因为若Broker不重新配置，新增的NameServer对于Broker来说是不可见的，它不会向这个NameServer进行注册

Broker节点为了证明自己是活的，为了维护与NameServer间的长连接，会将最新的信息以心跳包的方式上报给NameServer，每30秒发送一次心跳。心跳包中包含BrokerId、Broker地址、Broker名称、Broker所属集群名称等。NameServer在接受到心跳包后，会更新心跳时间戳，记录这个Broker的最新存活时间。

路由剔除

由于Broker关机、宕机或网络抖动等原因，NameServer没有收到Broker的心跳，NameServer可能会将其从Broker列表中剔除

NameServer中有一个定时任务，每隔10秒就会扫描一次Broker表，查看每一个Broker的最新心跳时间戳距离当前时间是否超过120秒，如果超过，则会判定Broker失效，然后将其从Broker列表中剔除

[!IMPORTANT]

对于RocketMQ日常运维工作，例如Broker升级，需要停掉Broker的工作

升级时，需要将Broker的读写权限禁掉，一旦client（Consumer或Producer）向Broker发送请求，都会收到Broker的NO_PERMISSION响应，然后client会进行对其他Broker的重试

当观察到需升级的Broker没有流量后，再关闭它，再实现Broker从NameServer的移除

路由发现

RocketMQ的路由发现采用的是Pull模型。当Topic路由信息出现变化时，NameServer不会主动推送给客户端，而是客户端定时拉取主题最新的路由。默认客户端每30秒会拉取一次最新的路由

[!IMPORTANT]

Push模型：推送模型

实时性较好，是一个发布-订阅模型,需要维护一个长连接，而长连接的维护时需要额外的服务器资源的。该模型适合于：

实时性要求较高的场景

Client数量不多，Server数据变化频繁

Pull模型：拉取模型

存在的问题是实时性较差

Long Polling模型：长轮训模型。是对Push和Pull模型的整合，充分利用了这两种模型的优势，屏蔽了它们的劣势

客户端NameServer选择策略

这里的客户端指的是Producer和Consumer

客户端在配置时必须要写上NameServer集群的地址，客户端首先会选一个随机数，然后再与NameServer节点数量取模，此时得到的就是所要连接的节点索引，然后就回进行连接。如果连接失败，则会采取round-robin策略，逐个尝试着去连接其他节点

首先采用的是随机策略进行的选择，是包后采用的是轮询策略。

[!IMPORTANT]

Zookeeper Client选择Zookeeper的策略：

简单来说：经过两次Shuffle，然后选择第一台Zookeeper Server

详细过程：将配置文件中的 zk server地址进行一次shuffle，然后随机选择一个，这个选择出的一般是一个hostname，然后获取到该hostname对应的所有ip，再对这些ip进行二次shuffle，从shuffle过的结果中取敌一个server地址进行连接

shuffle：洗牌，在zookeeper中意为打乱，重新排序。常用于负载均衡中。

4 Broker

功能介绍

Broker充当着消息中转角色，负责存储消息、转发消息。Broker在RocketMQ系统中负责接收并存储从生产者发送来的消息，同时为消费者的拉取请求做准备。Broker同时也存储着消息相关的元数据，包括消费者组消费进度偏移offset、主题、队列等。

[!IMPORTANT]

Kafka 0.8版本之后，offset是存放在Broker中的，之前版本是存放在Zookeeper中的

模块构成

下图为Broker Server的功能示意图

Remoting Module：整个Broker的实体，负责处理来自Clients端的请求。而这个Broker实体则由以下模块构成

Client Manager：客户端管理器。负责接收、解析客户端（Producer/Consumer）请求，管理客户端，eg：维护Consumer的Topic订阅信息

Store Service：存储服务。提供方便简单的API接口，处理消息存储到物理硬盘和消息查询功能

HA Service：高可用服务，提供Master Broker和Slave Broker之间的数据同步功能

Index Service：索引服务。根据特定的Message Key，对投递到Broker的消息进行索引服务，同时也提供根据Message Key对消息进行快速查询的功能

集群部署

为了增强Broker性能与吞吐量，Broker一般都是以集群形式出现的。各集群节点中可能存放着相同Topic的不同Queue。不过，这里有个问题，如果某Broker节点宕机，为了保证数据不丢失，会将每个Broker集群节点进行横向扩展，即将Broker节点再建为一个HA集群，解决单点问题

Broker节点集群是一个主从集群，集群中具有Master和Slave两种角色。Master负责处理读写操作请求，Slave负责对Master中的数据进行备份，当Master挂了，Slave会自动切换为Master去工作。所以Broker集群是主备集群，一个Master可以包含多个Slave，但一个Slave只隶属于一个Master。Master与Slave的对应关系是通过指定相同的BrokerName、不同的BrokerId来确定的。BrokerId为0标识Master，非0表示Slave。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer

5 工作流程

启动NameServer，NameServer启动后开始监听端口，等待Broker、Producer、Consumer连接
启动Broker时，Broker会与所有的NameServer建立并保持长连接，然后每30秒向NameServer定时发送心跳包
收发消息前，可以先创建Topic，创建Topic时需要制定该Topic要存储在哪些Broker上，当然，在创建Topic时也会将Topic与Broker的关系写入到NameServer中。不过这步是可选的，也可以在发送消息时自动创建Topic
[!IMPORTANT]

手动创建Topic的创建有两种模式：
1. 集群模式：该模式下创建的Topic在该集群中，所有Broker中的Queue数量是相同的
2. Broker模式：该模式下创建的Topic在该集群中，每个Broker中国呢的Queue数量可以不同
自动创建Topic时，则默认采用的是Broker模式，会为每一个Broker默认创建4个Queue
Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取路由信息，即当前发送的Topic的Queue与Broker地址（IP:port）的映射关系。然后根据算法策略从队列选择一个Queue，与队列所在的Broker建立长连接从而向Broker发消息。当然，在获取到路由信息后，Producer会首先将路由信息缓存到本地，再每30秒从NameServer更新一次路由信息
Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取其所订阅Topic的路由信息，然后根据算法策略从路由信息中获取到其所要消费的Queue，然后直接跟Broker建立长连接，开始消费其中的消息。Consumer在获取到路由信息后，同样也会每30秒从NameServer跟新一次路由信息。不过不同于Producer的是，Consumer还会向Broker发送心跳，以确保Broker的存活状态

[!IMPORTANT]

读/写队列

从物理上来讲，读/写队列是同一个队列。所以，不存在队列数据同步问题。读。写队列是逻辑上进行的区分概念。一般情况下，读/写队列数量是相同的

eg：创建Topic时设置的写队列数量为8，读队列数量为4，此时系统会创建8个Queue，分别是0 1 2 3 4 5 6 7。Producer会将消息写入到这8个队列中，但Consumer只会消费到0 1 2 3这4个队列中的消息，4 5 6 7中的消息时不会被消费到的。

当读/写队列数量设置不同时，会产生相应问题

但是这样设计的目的是为了方便Queue的缩容

三、单机安装与启动

1 准备工作

软硬件需求

操作系统选择为虚拟机中的CentOS （Mac M系列芯片架构为 ARM64）虚拟机配置：

Java1.8 及以上版本

JDK安装：
1. wget https://repo.huaweicloud.com/java/jdk/8u202-b08/jdk-8u202-linux-arm64-vfp-hflt.tar.gz
2. tar -zxvf jdk-8u202-linux-arm64-vfp-hflt.tar.gz
3. 配置环境变量到： /etc/profile
4. 使环境变量生效：source /etc/profile
5. 检查是否生效：java -version

2 RocketMQ安装

下载安装包 wget https://dist.apache.org/repos/dist/release/rocketmq/5.3.1/rocketmq-all-5.3.1-bin-release.zip
解压 unzip rocketmq-all-5.3.1-bin-release.zip
修改启动脚本参数（其默认配置最大jvm为4g，使用的虚拟机配置）：
- runserver.sh jvm参数修改 512m
- runbroker.sh jvm参数修改 512m

3 启动

启动NameServer

bash

### 启动namesrv
$ nohup sh bin/mqnamesrv &
 
### 验证namesrv是否启动成功
$ tail -f ~/logs/rocketmqlogs/namesrv.log
The Name Server boot success...

成功标识：

启动Broker

bash

### 先启动broker
$ nohup sh bin/mqbroker -n localhost:9876 &

### 验证broker是否启动成功, 比如, broker的ip是192.168.1.2 然后名字是broker-a
$ tail -f ~/logs/rocketmqlogs/broker.log
The broker[broker-a,192.169.1.2:10911] boot success...

成功标识：

4 测试

前置准备

需要环境变量用做测试

export NAMESRV_ADDR=localhost:9876

发送消息测试

bash

sh bin/tools.sh org.apache.rocketmq.example.quickstart.Producer

效果图

接收消息测试

bash

sh bin/tools.sh org.apache.rocketmq.example.quickstart.Consumer

效果图

5 关闭

bash：

$ sh bin/mqshutdown broker
The mqbroker(36695) is running...
Send shutdown request to mqbroker(36695) OK

$ sh bin/mqshutdown namesrv
The mqnamesrv(36664) is running...
Send shutdown request to mqnamesrv(36664) OK

四、控制台的安装与启动

1 准备

控制台项目git（一个SpringBoot项目）：https://github.com/apache/rocketmq-externals/rocketmq-console

拉取工程到本地修改配置文件中的rocketmq.config.namesrvAddr为自己安装的rocketmq中NameServer的IP端口

2 编译并启动项目

通过idea编译并启动（需要修改当前机器的java版本，默认版本为1.7）

3 效果展示

五、集群搭建理论

1 数据复制与刷盘策略

复制策略

复制策略是Broker的Master与Slave间的数据同步方式，分为同步复制与异步复制：

同步复制：消息写入master后，master会等待slave同步数据成功后才向producer返回成功ACK
异步复制：消息写入master后，master立即向producer返回成功ACK，无需等待slave同步数据成功

[!IMPORTANT]

异步复制策略降低系统的写入延迟，RT变小，提高了系统的吞吐量

刷盘策略

刷盘策略指的是broker消息中的落盘方式，即消息发送到broker内存后消息持久化到磁盘的方式。分为同步刷盘与异步刷盘

同步刷盘：当消息持久化到broker的磁盘后才算是消息写入成功
异步刷盘：当消息写入到broker的内存后即表示消息写入成功，无需等待消息持久化道磁盘

[!IMPORTANT]

异步刷盘策略会降低系统的写入延迟，RT变小，提高了系统的吞吐量

消息写入到Broker的内存，一般是写入到PageCache

对于异步刷盘策略，消息会写入到PageCache后立即返回成功ACK，但并不会立即做落盘操作，而是当PageCache达到一定量时会自动进行落盘

2 Broker集群模式

根据Broker集群中各个节点间关系的不同，Broker集群可以分为以下几类：

单Master

只有一个Master（其本质上就是一个单节点）。

多Master

Broker集群仅由多个Master构成，不存在Slave。同一Topic的各个Queue会平均分布在各个Master节点上

优点：配置简单，单个Master宕机或重启维护对应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10(详细解释见下方引用)磁盘非常可靠，消息也不会丢失（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高
缺点：单机宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅（不可消费），消息实时性受影响

[!IMPORTANT]

RAID10（Redundant Array of Independent Disks 10）也被称为RAID 1+0，是一种存储技术，它结合了RAID 1（镜像）和RAID 0（条带化）的特点，以提供高性能和数据冗余。

一、RAID 1的特点（镜像部分）

数据冗余原理

RAID 1通过将数据同时写入两个或多个磁盘来实现数据冗余。例如，有磁盘A和磁盘B，当数据写入磁盘A时，完全相同的数据副本会同时写入磁盘B。这样，如果磁盘A出现故障，数据可以从磁盘B中完整地恢复。

假设存储的是一份重要的企业财务数据文件，在RAID 1模式下，这份文件同时存在于两个磁盘中，就像有一个“备份盘”随时准备接替故障盘的工作。

读写性能方面

读取性能：由于数据可以从多个磁盘同时读取，读取速度理论上可以提高。例如，在读取一个大型数据库查询结果文件时，如果该文件存在于两个磁盘（RAID 1）中，系统可以同时从两个磁盘读取部分数据，加快读取过程。不过，实际的性能提升程度还会受到存储系统的其他因素如磁盘转速、接口带宽等的限制。

写入性能：写入性能相对较弱，因为数据要同时写入多个磁盘。每次写入操作都要在所有镜像磁盘上完成，这就导致写入速度会比单个磁盘写入稍慢。比如写入一个高清视频文件，需要同时将数据写入两个磁盘，这个过程会比只写一个磁盘花费更多的时间。

二、RAID 0的特点（条带化部分）

数据存储原理

RAID 0将数据分成多个块（称为条带），并将这些条带交替地存储在多个磁盘上。例如，有三个磁盘C、D、E，数据块1存储在磁盘C，数据块2存储在磁盘D，数据块3存储在磁盘E，以此类推。这种方式可以充分利用多个磁盘的读写带宽，提高存储系统的性能。

以存储大型视频编辑项目为例，视频文件的数据被分成许多小块，分别存储在不同的磁盘上。当需要读取或写入这个视频文件时，多个磁盘可以同时工作，大大提高了效率。

读写性能方面

读取性能：读取数据时，由于数据分布在多个磁盘上，多个磁盘可以同时工作，读取速度可以得到显著提高。例如，在读取一个多声道的高保真音频文件时，不同声道的数据存储在不同磁盘上，这些磁盘可以同时传输数据，使得音频文件能够快速地被读取和播放。

写入性能：写入性能也有很大提升，因为数据是同时写入多个磁盘的不同位置，相当于多个磁盘的写入带宽可以同时被利用。比如写入一个大型3D游戏安装文件，文件数据被分成条带同时写入多个磁盘，速度比单磁盘写入要快得多。不过，RAID 0没有数据冗余，如果其中一个磁盘出现故障，所有数据都会丢失。

三、RAID10的综合特点

性能表现

读取性能：RAID10继承了RAID 0的读取性能优势，数据可以从多个磁盘同时读取，提供了很高的读取速度。这对于需要频繁读取大量数据的应用场景，如数据仓库、多媒体服务器等非常有利。例如，在数据仓库中，大量的报表查询数据可以快速地从RAID10存储系统中被读取出来，提高数据分析的效率。

写入性能：写入性能比RAID 1要好，因为它在写入时既有镜像操作保证数据冗余，又有条带化操作可以利用多个磁盘的写入带宽。不过，写入性能还是会比RAID 0稍差一些，因为镜像操作会带来一定的开销。

数据冗余和可靠性

RAID10提供了数据冗余，它通过RAID 1的镜像机制来保证数据的安全性。即使一组条带化磁盘（RAID 0部分）中的一个磁盘出现故障，由于有镜像磁盘存在，数据仍然可以恢复。例如，在一个由4个磁盘组成的RAID10系统中，假设磁盘1和磁盘2是一组镜像，磁盘3和磁盘4是另一组镜像，并且它们之间进行条带化存储。如果磁盘1出现故障，磁盘2上的数据可以保证数据的完整性，系统仍然可以正常工作，同时可以在适当的时候更换故障磁盘。

应用场景

RAID10适用于对数据读写性能和数据安全性要求都很高的场合。比如企业的核心数据库服务器，既需要快速地处理大量的用户查询请求（读取操作），又需要保证数据的完整性和安全性，防止数据丢失造成严重后果。还有金融交易系统，需要高速的读写性能来处理大量的交易数据，同时要确保数据不会因为磁盘故障而丢失。

成本考虑

RAID10的成本相对较高，因为它需要至少4个磁盘来构建。这是因为它是RAID 1和RAID 0的组合，需要足够的磁盘来实现镜像和条带化。而且，随着存储容量需求的增加，所需的磁盘数量也会相应增加，进一步提高了成本。例如，要构建一个10TB的RAID10存储系统，可能需要购买比构建简单RAID类型更多的磁盘来满足容量和性能、冗余的要求。

多Master多Slave模式-异步复制

Broker集群由多个Master构成，每个Master又配置了多个Slave（在配置了RAID磁盘阵列的情况下，一个Master一般配置一个Slave即可）。Master与Slave的关系是主备关系，即Master负责处理消息的读写请求，而Slave仅负责消息的备份与Master宕机后的角色切换

该模式最大特点之一是，当Master宕机后Slave能够自动切换为Master。不过由于Slave从Master的同步具有短暂的延迟（毫秒级），所以当Master宕机后，这种异步复制方式可能会存在少量消息的丢失问题。

[!IMPORTANT]

Slave从Master同步的延迟越短，其可能丢失的消息就越少

对于Master的RAID磁盘阵列，若使用的也是异步复制策略，同样也存在延迟问题，同样也可能会丢失消息。但RAID阵列的延迟是微秒级的（由硬件支持），所以丢失的数据量会更少

多Master多Slave模式-同步双写

该模式是多Master多Slave模式的同步复制实现，所谓同步双写指的是消息写入Master成功后，Master会等待Slave同步数据成功后才向Producer返回成功ACK，即Master与Slave都要写入成功后才会返回成功ACK，也称为双写

该模式与异步复制模式相比，优点是消息的安全性更高，不存在消息丢失的情况。但单个消息的RT略高，从而导致性能要略低（大约10%）

该模式存在一个大的问题：对于目前的版本，Master宕机后，Slave不能自动切换到Master

最佳实践

一般会为Master配置RAID10磁盘阵列，然后配置一个Slave，利用了RAID10磁盘阵列的高效、安全性，又解决了可能会影响订阅的问题。

[!IMPORTANT]

RAID磁盘阵列的效率要高于Master-Slave集群。因为RAID是硬件支持的，也正因如此，其硬件成本也偏高

多Master + RAID磁盘阵列，与多Master多Slave集群的区别

多Master + RAID磁盘阵列仅仅可以保证数据不丢失，不影响消息写入，但可能会影响到消息的订阅

多Master多Slave集群不仅可以保证数据不丢失，也不会影响消息的写入。但是运行效率要低于多Master + RAID磁盘阵列

六、磁盘阵列RAID

1 RAID历史

1988 年，美国加州大学伯克利分校的 David A. Patterson 教授、Garth Gibson 以及 Randy H. Katz 等人在论文 “A Case of Redundant Array of Inexpensive Disks” 中首次提出了 RAID 概念，即廉价冗余磁盘阵列 ，旨在通过组合多个小容量、低成本的磁盘，以较低成本获得与昂贵大容量磁盘相当的容量、性能和可靠性

随着磁盘成本和价格的不断降低，廉价已经毫无意义。因此，RAID咨询委员会决定用“独立”替代“廉价”，对于RAID变成了独立磁盘冗余阵列（Redundant Array of Independent Disks）。但着仅仅是名称的变化，实质内容没有改变。

2 RAID等级

最初的论文中定义了 RAID 0-RAID 6 等原始 RAID 等级，之后存储厂商又不断推出了 RAID 7、RAID 10、RAID 01、RAID 50、RAID 53、RAID 100 等更多等级，但业界公认的标准是 RAID 0-RAID 6，其中除 RAID 2 外的四个等级已被定为工业标准，而在实际应用中，RAID 0、RAID 1、RAID 3、RAID 5、RAID 6 和 RAID 10 是最为常见的选择

3 关键技术

镜像技术

镜像技术是一种冗余技术，为磁盘提供数据备份功能，繁殖磁盘发生故障而造成数据丢失。对于RAID而言，采用镜像技术最典型的用法就是同时在磁盘阵列中产生两个完全相同的数据副本，并且分布在两个不同的磁盘上。镜像提供了完全的数据冗余能力，当一个数据副本失效不可用时，外部系统仍可正常访问另一副本，不会对应用系统运行和性能产生影响。而且，镜像不需要额外的计算和校验，故障修复非常快，直接复制即可。镜像技术可以从多个副本进行并发读取数据，提供更高的读I/O性能，但不能并行写数据，写多个副本通常会导致一定的I/O性能下降

镜像技术提供了非常高的数据安全性，但是它带来的代价也更加的昂贵，需要至少双倍的存储空间。高成本限制了镜像的广泛应用，主要应用于非常重要的数据保护中，这种场合下的数据丢失可能会造成非常巨大的损失

数据条带技术

数据条带化技术是一种自动将I/O操作负载均衡道多个物理磁盘上的技术。更具体地说就是将一块连续的数据分成很多小部分并把它们分别存储到不同的磁盘上。折旧能使多个进程可以并发访问数据的多个不同部分，从而获得最大程度上的I/O并行能力，极大地提升性能

数据校验技术

数据校验技术是指，RAID要在写入数据的同时进行校验计算，并将得到的校验数据存储在RAID成员磁盘中。校验数据可以集中保存在某个磁盘或分散存储在多个不同磁盘中。当其中一部分数据出错时，就可以对剩余数据和校验数据进行反校验计算重建丢失数据

数据校验技术相对于镜像技术的优势在于节省大量开销，但由于每次数据读写都要进行大量的校验运算，对计算机的运算速度要求很高，且必须使用硬件RAID控制器。在数据重建恢复方面，检验技术比镜像技术复杂得多且慢得多。

4 RAID 分类

从实现角度看，RAID主要分为软RAID、硬RAID以及混合RAID三种

软RAID

所有功能均有操作系统和CPU完成，没有独立的RAID控制处理芯片和I/O处理芯片，效率自然最低

硬RAID

配备了专门的RAID控制处理芯片和I/O处理芯片以及阵列缓冲，不占用CPU资源。效率很高，但成本也很高

混合RAID

具备RAID控制处理芯片，但没有专门的I/O处理芯片，需要CPU和驱动程序来完成。性能和成本在软RAID和硬RAID之间

5 常见RAID等级详解

JBOD

JBOD，Just a Bunch of Disks，磁盘簇。表示一个没有控制软件提供协调控制的磁盘集合，这时RAID区别于JBOD的主要因素。JBOD将多个物理磁盘串联起来，提供一个巨大的逻辑磁盘

JBOD的数据存放机制是由第一块磁盘开始按顺序往后存储，当前磁盘存储空间用完后，再依次往后存储数据。JBOD存储性能完全等同于单块磁盘，而且也不提供数据安全保护

[!IMPORTANT]

只是简单提供一种扩展存储空间的机制，JBOD可用存储容量等于所有成员磁盘的存储空间之和

JBOD常指磁盘柜，而不论其是否提供RAID功能。不过，JBOD并非官方术语，官方称为Spanning

RAID0

RAID0 是一种简单的、无数据校验的数据条带化技术。实际上不是一种真正的RAID，因为它并不提供任何形式的冗余策略。RAID0将所在磁盘条带化后组成大容量的存储空间，将数据分散存储在所有磁盘中，以独立访问方式实现多块磁盘的并读

理论上讲，一个由n块磁盘组成的RAID0，它的读写性能是单磁盘性能的n倍，但由于总线带宽等多种因素的限制，实际的性能提升低于理论值。由于可以进行并发执行I/O操作，总线带宽得到充分利用。再加上不需要进行数据校验，RAID0的性能在所有RAID等级中是最高的

RAID0具有低成本、高读写性能、100%的高存储空间利用率的优点，但是它不提供数据冗余保护，一旦数据损坏、将无法恢复

应用场景：对读写性能要求较高的场景

[!IMPORTANT]

相对于JBOD：

磁盘利用率都为100%

读写效率优于JBOD

RAID1

RAID1就是一种镜像技术，它将数据完全一致地分别写到工作磁盘和镜像磁盘，它的磁盘空间利用率为50%。RAID1在数据写入时，响应时间会有所影响，但是读取数据的时候没影响。RAID1提供了最佳的数据保护与最优的数据恢复机制，一旦工作磁盘发生故障，系统将自动切换到镜像磁盘，不会影响使用

RAID1是为了增强数据安全性使两块磁盘数据呈现完全镜像，从而达到安全性好、技术简单、管理方便等优点。RAID1拥有完全融错的能力，单实现成本高

应用场景：对顺序读写性能要求较高，或对数据安全性要求较高的场景

RAID10

RAID10 是一个RAID1与RAID0的结合，它继承了RAID0的快速和RAID1的安全

简单来说：先做条带，再做镜像。即将进来的数据先分散到不同的磁盘，再将磁盘中的数据做镜像

RAID01

RAID01时一个RAID0与RAID1的结合，它也继承了RAID1与RAID0的安全和快速

简单来说：先做镜像，再做条带。即将进来的数据先做镜像，再将镜像数据分散到不同的磁盘

[!IMPORTANT]

RAID10要比RAID01的融错更高

生产环境下一般不使用RAID01

七、集群搭建实践

1 集群架构

这里要搭建一个双主双从异步复制的Broker集群。为了方便，这里使用了两台虚拟机来完成集群的搭建。这两台主机的功能与Broker角色分配如下：

序号	主机名	IP	功能	Broker角色
1	CentOS Linux 1	192.168.199.5	NameServer + Broker	Master1 + Slave2
2	CentOS Linux 2	192.168.199.6	NameServer + Broker	Master2 + Slave1

[!IMPORTANT]

此处采用2主2从异步架构部署

在配置文件中能看到对应文件夹：

其中

CentOS Linux 1 我们使用broker-a.properties和broker-b-s.properties

CentOS Linux 2 我们使用broker-a-s.properties和broker-b.properties

2 机器配置

broker-a.properties、broker-b.properties新增配置：

namesrvAddr=192.168.199.5:9876;192.168.199.6:9876

broker-a-s.properties、broker-b-s.properties新增配置：

namesrvAddr=192.168.199.5:9876;192.168.199.6:9876

# master占用默认端口，需要改变slave的端口
listenPort=11911

# 数据存储路径修改
storePathRootDir=~/store-s
storePathCommitLog=~/store-s/commitlog
storePathConsumeQueue=~/store-s/consumequeue
storePathIndex=~/store-s/index
storePathIndex=~/store-s/checkpoint
abortFile=~/store-s/abort

3 启动服务

启动NameServer集群

分别启动两台机器的NameServer：

nohup sh mqnamesrv &
tail -f ~/logs/rocketmqlogs/namesrv.log

启动成功：

启动两个Master

分别启动两台机器上的Master 两台机器指定的配置文件不同：

# CentOs Linux 1
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a.properties &
tail -f ~/logs/rocketmqlogs/broker.log

# CentOs Linux 2
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-b.properties &
tail -f ~/logs/rocketmqlogs/broker.log

启动成功：

启动两个Slave

分别启动两台机器上的Master 两台机器指定的配置文件不同：

# CentOs Linux 1
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-b-s.properties &
tail -f ~/store-s/logs/rocketmqlogs/broker.log

# CentOs Linux 2
nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a-s.properties &
tail -f ~/store-s/logs/rocketmqlogs/broker.log

启动成功：

整个集群启动成功后，我们可以在rocketmq-console项目中配置对应NameServer集群地址并启动。可看到：

分布式消息队列 RocketMQ

第1章 RocketMQ 概述

一、MQ概述

1. MQ简介

2. MQ用途

限流消峰

异步解耦

数据收集

3. 常见MQ产品

ActiveMQ

RabbitMQ

Kafka

RocketMQ

对比

4. 常见MQ协议

JMS

STOMP

AMQP

MQTT

二、RocketMQ概述

1. RocketMQ简介

2. RocketMQ发展历程

第2章 RocketMQ 的安装与启动

一、基本概念

1. 消息（Message）

2. 主题（Topioc）

3. 标签（Tag）

4.队列（Queue）

5. 消息标识（MessageId/Key）

二、 系统架构

1. Producer

2. Consumer

3 Name Server

功能介绍

路由注册

路由剔除

路由发现

客户端NameServer选择策略

4 Broker

功能介绍

模块构成

集群部署

5 工作流程

三、单机安装与启动

1 准备工作

软硬件需求

2 RocketMQ安装

3 启动

启动NameServer

启动Broker

4 测试

前置准备

发送消息测试

接收消息测试

5 关闭

bash：

四、控制台的安装与启动

1 准备

2 编译并启动项目

3 效果展示

五、集群搭建理论

1 数据复制与刷盘策略

复制策略

刷盘策略

2 Broker集群模式

单Master

多Master

多Master多Slave模式-异步复制

多Master多Slave模式-同步双写

最佳实践

六、磁盘阵列RAID

1 RAID历史

2 RAID等级

3 关键技术

镜像技术

数据条带技术

数据校验技术

4 RAID 分类

软RAID

硬RAID

二、系统架构