
RocketMQ深入浅出-03-集群搭建
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
