RocketMQ集群部署方式总结
1 RocketMQ网络部署图
RocketMQ网络部署图如下图所示:
1.1 RocketMQ网络部署特点:
- NameServer是一个几乎无状态节点,可集群部署,节点之间无任何信息同步。
- Broker部署相对复杂,Broker分为Master与Slave,一个Master可以对应多个Slave,但是一个Slave只能对应一个Master,Master与Slave的对应关系通过指定相同的BrokerName,不同的BrokerId来定义,BrokerId为0表示Master,非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接,定时注册Topic信息到所有 NameServer。
- Producer与NameServer集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master建立长连接,且定时向Master发送心跳。Producer完全无状态,可集群部署。
- Consumer与NameServer集群中的其中一个节点(随机选择)建立长连接,定期从Name Server取Topic路由信息,并向提供Topic服务的Master、Slave建立长连接,且定时向Master、Slave发送心跳。Consumer既可以从Master订阅消息,也可以从Slave订阅消息,订阅规则由Broker配置决定。
2 NameServer集群
NameServer集群如下:
NameServer集群 | IP地址 |
---|---|
NameServer-1 | 192.168.1.101 |
NameServer-2 | 192.168.1.102 |
分别启动
1 | nohup sh mqnamesrv & |
3 RocketMQ配置文件
众所周知,RocketMQ有多种集群部署方式,它们的配置文件也是分开的,如下:
1 | [root@rocketmq01 conf]# ls -rlt /usr/local/rocketmq/conf |
说明:
- 2m-noslave: 多Master模式
- 2m-2s-sync: 多Master多Slave模式,同步双写
- 2m-2s-async:多Master多Slave模式,异步复制
RocketMQ默认提供的配置文件都是最基本的,很多配置都是默认值,在生产环境中我们需要根据实际情况进行修改。样例配置如下:
1 | #所属集群名字 |
4 Broker集群部署
Broker集群部署有几种不同的方式。这里的Slave不可写,但可读,类似于MySQL的主备方式。
4.1 单个Master
这种方式风险较大,一旦Broker重启或者宕机时,会导致整个服务不可用,不建议线上环境使用
4.2 多Master模式
一个集群无Slave,全是Master,例如2个Master或者3个Master。
brokerName | brokerId | brokerRole | IP地址 |
---|---|---|---|
broker-a | 0 | ASYNC_MASTER | 192.168.1.101 |
broker-b | 0 | ASYNC_MASTER | 192.168.1.102 |
优点:
配置简单,单个Master宕机或重启维护对应用无影响,在磁盘配置为RAID10时,即使机器宕机不可恢复情况下,由于RAID10磁盘非常可靠,消息也不会丢失(异步刷盘丢失少量消息,同步刷盘一条不丢)。性能最高。缺点:
单台机器宕机期间,这台机器上未被消费的消息在机器恢复之前不可订阅,消息实时性会受到影响。
启动步骤:
第一步:先启动NameServer集群
第二步:在192.168.1.101,启动第一个Master
1 | nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-noslave/broker-a.properties >/dev/null 2>&1 & |
第三步:在192.168.1.102,启动第二个Master
1 | nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-noslave/broker-b.properties >/dev/null 2>&1 & |
4.3 多Master多Slave模式,异步复制
每个Master配置一个Slave,有多对Master-Slave,HA采用异步复制方式,主备有短暂消息延迟,毫秒级。
brokerName | brokerId | brokerRole | IP地址 |
---|---|---|---|
broker-a | 0 | ASYNC_MASTER | 192.168.1.101 |
broker-a | 1 | SLAVE | 192.168.1.102 |
broker-b | 0 | ASYNC_MASTER | 192.168.1.103 |
broker-b | 1 | SLAVE | 192.168.1.104 |
优点:即使磁盘损坏,消息丢失的非常少,且消息实时性不会受影响,因为Master 宕机后,消费者仍然可以从Slave消费,此过程对应用透明。不需要人工干预。性能同多 Master 模式几乎一样。
缺点:Master宕机,磁盘损坏情况,会丢失少量消息。
启动步骤
第一步:先启动NameServer集群
第二步:在192.168.1.101,启动第一个Master
1 | nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 & |
第三步:在192.168.1.102,启动第一个Slave
1 | nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-a-s.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 & |
第四步:在192.168.1.103,启动第二个Master
1 | nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 & |
第五步:在机器 192.168.1.104,启动第二个Slave
1 | nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-async/broker-b-s.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 & |
4.4 多Master多Slave模式,同步双写
每个Master配置一个Slave,有多对Master-Slave,HA采用同步双写方式,主备都写成功,向应用才返回成功。
brokerName | brokerId | brokerRole | IP地址 |
---|---|---|---|
broker-a | 0 | SYNC_MASTER | 192.168.1.101 |
broker-a | 1 | SLAVE | 192.168.1.102 |
broker-b | 0 | SYNC_MASTER | 192.168.1.103 |
broker-b | 1 | SLAVE | 192.168.1.104 |
优点:数据与服务都无单点,Master宕机情况下,消息无延迟,服务可用性与数据可用性都非常高。
缺点:性能比异步复制模式略低,大约低10%左右,发送单个消息的RT会略高。目前主宕机后,备机不能自动切换为主机,后续会支持自动切换功能。
启动步骤:
第一步:先启动NameServer集群
第二步:在192.168.1.101,启动第一个Master
1 | nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 & |
第三步:在192.168.1.102,启动第一个Slave
1 | nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-a-s.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 & |
第四步:在192.168.1.103,启动第二个Master
1 | nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 & |
第五步:在192.168.1.104,启动第二个Slave
1 | nohup sh mqbroker -c $ROCKETMQ_HOME/conf/2m-2s-sync/broker-b-s.properties >$ROCKETMQ_HOME/log/mq.log >/dev/null 2>&1 & |
注意事项:以上Broker与Slave配对是通过指定相同的brokerName参数来配对,Master的 BrokerId必须是0,Slave的BrokerId必须是大于0的数。另外一个Master下面可以挂载多个Slave,同一Master下的多个Slave 通过指定不同的BrokerId来区分。
4.5 总结
1、异步复制和同步双写总结
2、集群方式对比
集群方式 | 运维特点 | 消息可靠性(master宕机情况) | 服务可用性(master宕机情况) | 其他特点 | 备注 |
---|---|---|---|---|---|
单Master | 结构简单,扩容方便,机器要求低 | 同步刷盘消息一条都不会丢 | 整体可用,未被消费的消息无法取得,影响实时性 | 性能最高 | |
多Master | 异步有毫秒级丢失,同步双写不丢失 | 差评,主备不能自动切换,且备机只能读不能写,会造成服务整体不可写 | 不考虑,除非自己提供主从切换的方案 | ||
Master-Slave(异步复制) | 结构复杂,扩容方便 | 故障时会丢失消息 | 整体可用,实时性影响毫秒级别 | ||
该组服务只能读不能写 | 性能很高 | 适合消息可靠性中等,实时性中等的要求 | |||
Master-Slave(同步双写) | 结构复杂,扩容方便 | 不丢消息 | 整体可用,不影响实时性,该组服务只能读不能写 | 性能比异步低10%,所以实时性也并不比异步方式太高 | 适合消息可靠性略高,实时性中等、性能要求不高的需求 |
5 高可用演练场景
RocketMQ高可用演练场景
项目 | 发送消息 | 发送消息过程中 | 接收消费消息 |
---|---|---|---|
停用一个namesrv | 不影响通信 | 不影响通信 | 不影响通信 |
停用全部namesrv | 影响通信 | 不影响通信 | 影响通信,启动任意的namesrv可恢复 |
停用单个master broker | 不影响通信 | 不影响通信 | 不影响通信 |
停用全部master broker | 影响通信 | 影响通信,无法恢复 | 影响通信 |
停用一个slave broker | 不影响通信 | 不影响通信 | 不影响通信 |
停用全部slave broker | 不影响通信 | 影响通信,数秒恢复 | 不影响通信,数秒恢复 |