rocketmq clusterName nameserver配置 rocketmq_client log

文章目录

• RocketMQ 概述

• 1、RocketMQ 简介
• 2、RocketMQ 发展历史

• RocketMQ 安装与启动

• 1、基本概念
• 2、系统架构

• 单机安装与启动

• 1、准备工作
• 2、修改初始内存
• 3、启动
• 4、发送/接收消息测试
• 5、关闭 Server

• 控制台安装与启动
• 集群搭建理论

• 1、数据复制与刷盘策略
• 2、Broker 集群模式

• 集群搭建

• 1.集群架构
• 2.修改 rocketmq-1 配置文件
• 3.修改 rocketmq-2 配置文件
• 4.启动服务器
• 5.启动控制面板

RocketMQ 概述

1、RocketMQ 简介

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

RocketMQ 是一款阿里巴巴开源的消息中间件。2016年11⽉28⽇，阿⾥巴巴向 Apache 软件基⾦会捐赠RocketMQ，成为 Apache 孵化项⽬。2017 年 9 ⽉ 25 ⽇，Apache 宣布 RocketMQ孵化成为 Apache 顶级项⽬（TLP ），成为国内⾸个互联⽹中间件在 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年双十一，RocketMQ承载了万亿级消息的流转，跨越了一个新的里程碑。11⽉28⽇，阿⾥巴巴向 Apache 软件基⾦会捐赠 RocketMQ，成为 Apache 孵化项⽬。

2017 年 9 ⽉ 25 ⽇，Apache 宣布 RocketMQ孵化成为 Apache 顶级项⽬（TLP ），成为国内⾸个互联⽹中间件在 Apache 上的顶级项⽬。

RocketMQ 安装与启动

1、基本概念

消息（message）

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

主题（topic）

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

标签（tag）

为消息设置的标签，用于同一主题下区分不同类型的消息。来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同的标签。标签能够有效的保持代码的清晰度和连贯性，并优化RocketMQ提供的查询系统。消费者可以根据 tag 实现对不同子主题的不同消费逻辑，实现更好的扩展性。

Topic 是消息的一级分类，Tag 是消息的二级分类。
Topic ：货物
tag = 上海
tag = 江苏

—消费者—
topic = 货物 tag = 上海
topic = 货物 tag = 上海 江苏
topic = 货物 tag = *

队列（queue）

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

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

在其他资料中，还会有一个概念：分片（Sharding）。分片不同于分区。在RocketMQ 中，分片指的是存放相应 topic 的 Broker 。每个分片中会创建出相应数量的分区，即 Queue ，每个 Queue 的大小都是相同的。

消息标识（MessageId / Key）

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

• msgId：由 producer 端生成，器生成规则为：
  producerIp + 进程 pid + MessageClientIDSetter 类的ClassLoader的hashCode + 当前时间 + AutomicInteger 自增计数器
• offsetMsgId：由 Broker 端生成，其生成规则为：
  brokerIp + 物理分区的 offset（Queue中的偏移量）
• key：由用户指定业务相关的唯一标识

2、系统架构

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

1. Producer
   消息生产者，负责生产消息。Producer 通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败并且低延迟。
   RocketMQ 中的消息生产者都是以生产者组（Producer Group）的形式出现 。生产者组是同一类生产者的集合，这类 Producer 发送相同的 Topic 类型的消息。一个生产者组可以同时发送多个主题的消息。
2. Consumer
   消息消费者，负责消费消息。一个消息消费者会从 Broker 服务器中获取到消息，并对消息进行相关业务的处理。
   RocketMQ 中的消息消费者都是以消费者组（Consumer group）的形式出现。消费者组是同一类消费者的集合，这类 Consumer 消费的是同一个 Topic 类型的消息。消费者组使得在消息消费方面实现负载均衡（将一个Topic 种不同的的 Queue 平均分配给同一个Consumer Group的不同 Consumer，注意并不是将消息负载均衡）和容错 （一个Consumer 挂了，该Consumer Group 中的其他Consumer 可以接着消费原 Consumer 消费的 Queue）的目标变得非常容易。

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

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

• 注意：
  消费组只能消费一个 Topic 的消息，不能同时消费多个 Topic 消息
  一个消费者组中的消息这必须订阅完全相同的 Topic

3. NameServer
   NameServer 是一个 Broker 与 Topic 路由的注册中心，支持 Broker 的动态注册与发现。
   RocketMQ 的思想来自于 Kafka ，而 Kafka 是依赖 Zookeeper 的。所以RocketMQ 早期版本，也是依赖于 Zookeeper 的，从 MetaQ 3.0 ，即 RocketMQ 开始去掉了 Zookeeper 依赖，使用自己的 NameServer 。
   主要包含两个功能：

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

路由注册

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

注意：
	这是与其他像 zk、Eureka、Nacos 等注册中心不同的地方。
	这种 NameServer 的无状态方式，有什么优缺点：
	优点：NameServer 集群搭建简单，扩容简单
	缺点：对于 Broker ，必须明确指出 NameServer 地址。否则未指出的将不会注册。也正因为如此，NameServer 并不能随便扩容。因为，若Broker 不重新配置，新增的NameServer 对于 Broker 来说是不可见的，其不会向这个 NameServer 进行注册。

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

路由剔除

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

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

路由发现

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

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



6. Remoting Moudle：整个 Broker 的实体，负责处理来自 clients端的请求。而这个 Broker 实体则由以下模块构成。
   Client Manager：客户端管理器。负责接收、解析客户端请求（Producer/Consumer）请求，管理客户端。例如，维护 Consumer 的 Topic 订阅信息。
   Store Service：存储服务。提供方便简单的接口，处理消息存储到物理硬盘和消息查询功能。
   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. 工作流程
   1）启动NameServer，NameServer启动后开始监听端口，等待Broker、Producer、Consumer连接。
   2）启动Broker时，Broker会与所有的NameServer建立并保持长连接，然后每30秒向NameServer定时发送心跳包。
   3）发送消息前，可以先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，当然，在创建Topic时也会将Topic与Broker的关系写入到NameServer中。不过，这步是可选的，也可以在发送消息时自动创建Topic。
   4）Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取路由信息，即当前发送的Topic消息的Queue与Broker的地址（IP+Port）的映射关系。然后根据算法策略从队选择一个Queue，与队列所在的Broker建立长连接从而向Broker发消息。当然，在获取到路由信息后，Producer会首先将路由信息缓存到本地，再每30秒从NameServer更新一次路由信息。
   5）Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取其所订阅Topic的路由信息，然后根据算法策略从路由信息中获取到其所要消费的Queue，然后直接跟Broker建立长连接，开始消费其中的消息。Consumer在获取到路由信息后，同样也会每30秒从NameServer更新一次路由信息。不过不同于Producer的是，Consumer还会向Broker发送心跳，以确保Broker的存活状态。

Topic 创建方式

手动创建 Topic 时，有两种模式：

• 集群模式：该模式下创建的Topic 在该集群中，所有 Broker 中的 Queue 数量是相同的。
• Broker 模式：该模式下创建的 Broker 模式，会为每个 Broker 默认创建 4 个 Queue。

读写队列

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

例如，创建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中的消息是不会被消费到的。

再如，创建Topic时设置的写队列数量为4，读队列数量为8，此时系统会创建8个Queue，分别是0 1 2 3 4 5 6 7。Producer会将消息写入到0 1 2 3 这4个队列，但Consumer只会消费0 1 2 3 4 5 6 7这8个队列中的消息，但是4 5 6 7中是没有消息的。此时假设Consumer Group中包含两个Consumer，Consumer1消费0 1 2 3，而Consumer2消费4 5 6 7。但实际情况是，Consumer1是没有消息可消费的。

也就是说，当读/写队列数量设置不同时，总是有问题的。那么，为什么要这样设计呢？

其这样设计的目的是为了，方便Topic的Queue的缩容。

例如，原来创建的Topic中包含16个Queue，如何能够使其Queue缩容为8个，还不会丢失消息？可以动态修改写队列数量为8，读队列数量不变。此时新的消息只能写入到前8个队列，而消费都消费的却是16个队列中的数据。当发现后8个Queue中的消息消费完毕后，就可以再将读队列数量动态设置为8。整个缩容过程，没有丢失任何消息。

perm用于设置对当前创建Topic的操作权限：2表示只写，4表示只读，6表示读写。

单机安装与启动

1、准备工作

下载 RocketMQ 安装包

上传到 Linux ，进行解压。

2、修改初始内存

修改 runserver.sh
使用vim命令打开 bin/runserver.sh

修改 runbroker.sh
使用vim命令打开 bin/runbroker.sh

3、启动

• 启动NameServe

nohup sh bin/mqnamesrv &

tail -f ~/logs/rocketmqlogs/namesrv.log

• 启动broker

nohup sh bin/mqbroker -n localhost:9876 &

tail -f ~/logs/rocketmqlogs/broker.log

4、发送/接收消息测试

• 发送消息

export NAMESRV_ADDR=localhost:9876

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

• 接收消息

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

5、关闭 Server

无论是关闭name server还是broker，都是使用bin/mqshutdown命令。

sh bin/mqshutdown broker

sh bin/mqshutdown namesrv

控制台安装与启动

RocketMQ有一个可视化的dashboard，通过该控制台可以直观的查看到很多数据。

下载：

下载地址：https://github.com/apache/rocketmq-externals/releases

修改配置：

修改其src/main/resources中的application.properties配置文件。

• 原来的端口号为8080，修改为一个不常用的
• 指定RocketMQ的name server地址

添加依赖：

在解压目录rocketmq-console的pom.xml中添加如下JAXB依赖。

<dependency>
	<groupId>javax.xml.bind</groupId>
	<artifactId>jaxb-api</artifactId>
	<version>2.3.0</version>
</dependency>
<dependency>
	<groupId>com.sun.xml.bind</groupId>
	<artifactId>jaxb-impl</artifactId>
	<version>2.3.0</version>
</dependency>
<dependency>
	<groupId>com.sun.xml.bind</groupId>
	<artifactId>jaxb-core</artifactId>
	<version>2.3.0</version>
</dependency>
<dependency>
	<groupId>javax.activation</groupId>
	<artifactId>activation</artifactId>
	<version>1.1.1</version>
</dependency>

打包：

在rocketmq-console目录下运行maven的打包命令。

启动：

访问：

错误解决

如果出现 org.apache.rocketmq.remoting.exception.RemotingConnectException: connect to <10.0.2.15:10909> failed

在 RocketMQ配置文件 broker.conf 中，添加 brokerIP1

然后重启 nameserver： 一定要杀死进程

nohup sh bin/mqnamesrv &

tail -f ~/logs/rocketmqlogs/namesrv.log

然后重启 broker： 一定要杀死进程

注意:重点是： -c config/broker.conf

nohup sh bin/mqbroker -n localhost:9876 -c config/broker.conf &

tail -f ~/logs/rocketmqlogs/broker.log

集群搭建理论

1、数据复制与刷盘策略

复制策略

复制策略是 Broker 与 Slave 之间的数据同步方式。分为同步复制与异步复制。

• 同步复制：消息写入 Master 后，master 会等待 Slave 同步数据成功后才向 Producer 返回成功的 ACK.
• 异步复制：消息写入 Master 后，master 立即向 Producer 返回成功的 ACK，无须等待 slave 同步数据成功

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

刷盘策略

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

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

1.异步刷盘会降低系统的写入延迟，RT变小、提高了系统的吞吐量
2.消息写入到 Broker 的内存，一般是写入到了 PageCache
3.对于异步刷盘策略，消息会写入到PageCache后立即返回成功的ACK。但并不会立即做落盘操作，而是当 PageCache 到达一定量时会自动进行落盘。

2、Broker 集群模式

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

单Master

只有一个 Broker （其本质上不能称为集群）。这种方式也只能在测试时使用，生产环境下不能使用，应为存在单点问题。

多Master

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

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

以上优点的前提时，这些 Master 都配置了 RAID磁盘阵列。如果没有配置，一旦出现某个 Master 宕机，会出现消息的大量丢失。

多Master多Slave模式-异步复制

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

异步复制即前面所说的复制策略中的异步复制策略，即消息写入master成功后，master立即向producer 发送成功 ACK，无需等待slave 同步数据成功。

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

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

多Master多Slave模式-同步双写

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

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

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

RAID磁盘阵列的效率要高于Master-Slave集群。RAID是硬件支持的。也正因为如此，所以RAID的搭建成本比较高

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

1.多Master+RAID 磁盘阵列，其仅仅乐可以保证数据不丢失，即不影响消息写入，但其可能会影响到消息的订阅。但其执行效率要高于多Master多Slaver集群

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

集群搭建

1.集群架构

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

序号	主机名称/IP	IP	功能	Broker 角色
1	rocketmq-1	192.168.56.107	NameServer + Broker	Master1 + Slave2
2	rocketmq-2	192.168.56.108	NameServer + Broker	Master2 + Slave3

2.修改 rocketmq-1 配置文件

配置文件位置

要修改的配置文件在rocketMQ解压目录的conf/2m-2s-async目录中。

修改broker-a.properties

修改broker-b-s.properties

3.修改 rocketmq-2 配置文件

配置文件位置

要修改的配置文件在rocketMQ解压目录的conf/2m-2s-async目录中。

修改broker-a-s.properties

修改broker-b.properties

4.启动服务器

启动 NameServer 集群

分别启动rocketmq-1与rocketmq-2两个主机中的NameServer。启动命令完全相同。

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

启动两个Master

分别启动rocketmq-1与rocketmq-2两个主机中的broker master。注意，它们指定所要加载的配置文件是不同的。

nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a.properties &

tail -f ~/logs/rocketmqlogs/broker.log

nohup sh bin/mqbroker -c conf/2m-2s-async/broker-b.properties &

tail -f ~/logs/rocketmqlogs/broker.log

启动两个Slave

分别启动rocketmq-1与rocketmq-2两个主机中的broker slave。注意，它们指定所要加载的配置文件是不同的。

nohup sh bin/mqbroker -c conf/2m-2s-async/broker-b-s.properties &

tail -f ~/logs/rocketmqlogs/broker.log

nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a-s.properties &

tail -f ~/logs/rocketmqlogs/broker.log

5.启动控制面板

修改配置文件

重新打包

java -jar 运行

访问localhost:7000