回复
RocketMQ深入浅出-03-集群搭建
baojunzh
发布于 2022-10-31 16:18
浏览
0收藏
3. RocketMQ集群搭建
3.1 各角色介绍
- Producer：负责发送消息到消息队列；
- Consumer：从消息队列获取消息进行消费；
- Broker：暂时存储和传输消息的平台；
- NameServer：管理Broker；
- Topic：区分消息的种类；一个发送者可以发送消息给一个或者多个Topic；一个消息的接收者可以订阅一个或者多个Topic消息
- Message Queue：相当于是Topic的分区；用于并行发送和接收消息
3.2 集群搭建方式
3.2.1 集群特点
- NameServer是一个几乎无状态节点，可以进行集群部署，节点之间不进行信息同步。
- Broker部署较为复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，一个Slave只能对应一个Master，Master与Slave的对应关系通过指定相同的BrokerName来确定。Master和Slave的角色通过不同的BrokerId来定义，BrokerId为0表示Master，非0表示Slave。Master也可以集群部署，每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。
- Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Maser建立长连接，且定时向Master发送心跳。Producer完全无状态，通常集群部署。
- Consumer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer取Topic路由信息，并向提供Topic服务的Maser、Slave建立长连接，且定时向Master、Slave发送心跳。Conumer既可以从Master订阅消息，也可以从Slave订阅消息，订阅规则由Broker配置决定。
3.2.3 集群模式
集群部署模式指的是Broker的部署模式，大致可以分为以下四种
1）单Master模式
这种部署方式风险较大，一旦Broker重启或者宕机时，会导致整个服务不可用，影响Producer和Consumer的使用。一般用于本地测试，线上环境不推荐使用。
2）多Master模式
这种模式指的是在集群中的所有Broker节点，都是Master的角色，没用Slave的角色。例如集群中有2个Master或者3个Master，这种模式的优缺也非常的明显：
优点：配置简单，单个Master宕机或重启，对client端无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢失（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高；
缺点：其中一台或几台机器宕机期间，这些机器上未被消费的消息在机器恢复之前不可被消费，消息实时性会受到影响。并且如果多数机器宕机，剩下正常运行的机器压力将会骤增。
3）多Master多Slave模式（异步）
这种模式指的是，多个Master，每个Master配置一个Slave，有多对Master-Slave，HA采用异步复制方式，即消息写入Master即返回Producer成功地ACK，然后主备之间采用异步地方式将消息同步到Slave，这种异步复制的方式会导致主备之间有短暂消息延迟（毫秒级），这种模式的优缺点总结如下：
优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响。同时Master宕机后，消费者仍然可以从Slave消费，而且此过程对应用透明，不需要人工干预，性能同多Master模式几乎一样，但是不会进行自动Master转移，需要人工干预，即写消息会受影响；
缺点：Master宕机，磁盘损坏情况下会丢失少量消息。
4）多Master多Slave模式（同步）
这模式和第种方式很类似，也是多个Master，每个Master配置一个Slave，有多对Master-Slave，不同的是它的HA采用的是同步双写方式，即只有主备都写成功（主从同步复制），才向Producer返回成功ACK，这种模式的优缺点如下：
优点：数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高，即保证了非常高的可靠性；
缺点：因为是同步双写，所以不可避免的会导致性能比第三种模式略低（大约低10%左右），发送单个消息的RT会略高，且目前版本在主节点宕机后，备用节点不能自动切换为主节点，需要人为干预。
3.3 双主双从集群搭建
3.3.1 总体架构
消息高可用采用2m-2s（同步双写）方式
3.3.2 集群工作流程
1.首先启动NameServer，NameServer起来后监听端口，等待Broker、Proucer、Consumer连上来，Broker连上后将自己的IP端口、Topic信息等注册进来，Producer和Consumer连上后取这些信息。NameServer相当于一个路由控制中心。
2.然后将Broker启动，它跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer集群中就保存了Topic跟Broker的映射关系。
3.NameServer和Broker都启动后，就是收发消息了。收发消息前，需先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic（自动创建Topic在线上环境不建议开启）。
4.Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息。
5.Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息。
3.3.3 服务器环境
3.3.4 Host添加信息
配置如下:
配置完成后, 重启网卡
3.3.5 防火墙配置
宿主机需要远程访问虚拟机的rocketmq服务和web服务，需要开放相关的端口号，简单粗暴的方式是直接关闭防火墙
或者为了安全，只开放特定的端口号，RocketMQ默认使用3个端口：9876 、10911 、11011 。如果防火墙没有关闭的话，那么防火墙就必须开放这些端口：
执行以下命令：
3.3.6 环境变量配置
在profile文件的末尾加入如下命令
输入:wq! 保存并退出， 并使得配置立刻生效：
3.3.7 创建消息存储路径
3.3.8 broker配置文件
1）master1
服务器：192.168.25.135
修改配置如下：
2）slave2
服务器：192.168.25.135
修改配置如下：
3）master2
服务器：192.168.25.138
修改配置如下：
4）slave1
服务器：192.168.25.138
修改配置如下：
3.3.9 修改启动脚本文件
1）runbroker.sh
需要根据内存大小进行适当的对JVM参数进行调整：
2）runserver.sh
3.3.10 服务启动
1）启动NameServe集群
分别在192.168.25.135和192.168.25.138启动NameServer
2）启动Broker集群
在192.168.25.135上启动master1和slave2
master1：
slave2：
l在192.168.25.138上启动master2和slave2
master2
slave1
3.3.11 查看进程状态
启动后通过JPS查看启动进程
3.3.12 查看日志
3.4 mqadmin管理工具
3.4.1 使用方式
进入RocketMQ安装位置，在bin目录下执行./mqadmin {command} {args}
3.4.2 命令介绍
3.4.3 注意事项
几乎所有命令都需要配置-n表示NameServer地址，格式为ip:port
几乎所有命令都可以通过-h获取帮助
如果既有Broker地址（-b）配置项又有clusterName（-c）配置项，则优先以Broker地址执行命令；如果不配置Broker地址，则对集群中所有主机执行命令
3.5 集群监控平台搭建
3.5.1 概述
RocketMQ有一个对其扩展的开源项目incubator-rocketmq-externals，这个项目中有一个子模块叫rocketmq-console，这个便是管理控制台项目了，先将incubator-rocketmq-externals拉到本地，因为我们需要自己对rocketmq-console进行编译打包运行。
3.5.2 下载并编译打包
注意：打包前在rocketmq-console中配置namesrv集群地址：
启动rocketmq-console：
启动成功后，我们就可以通过浏览器访问http://localhost:8080进入控制台界面了，如下图：
集群状态：
本文转载自公众号biggerboy
分类
标签
已于2022-10-31 16:18:54修改
赞
收藏
回复
相关推荐
