技术

[ RocketMQ源码阅读 5 ] 集群部署与架构

RocketMQ官方文档介绍了多种部署方式。我们抛开Local和Cluster集群的差异（Broker和Proxy是否部署在同一个进程），再去分析几种部署方式。

部署方式

  1. 单组节点单副本
    只部署一个Broker，无灾备能力。所以不推荐生产使用。
    图1

  2. 多组节点单副本
    只部署2-3个Master，不部署Slave
    图2

问题来了，多个Master之间数据如何同步的？个人猜测是通过双写来实现，后面再去分析吧。

  1. 多组节点多副本-异步复制
    图3

  2. 多组节点多副本-同步双写
    图4

  3. 主备自动切换模式
    图5

单组节点单副本不推荐在生产环境使用。多组节点多副本模式，节点间数据同步存在两种方案，主要是在写入性能和数据同步时效性做取舍。

几种模式优缺点，官方文档已经给出部署方式。除了单组节点单副本模式，我们先一起来看一下这5种部署方式的具体配置参数。

非主备自动切换模式

本地启动双节点NameServer

1
listenPort=10001 #修改默认端口号，避免在本地启动多个NameServer进程发生端口冲突
1
listenPort=10002 #修改默认端口号，避免在本地启动多个NameServer进程发生端口冲突

在idea启动NameServer需要添加如下配置，上述修改端口的配置内容，放入-c指定的配置文件内
NameServer进程启动配置项

多组节点单副本

Broker-1的配置，作为Master节点

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
brokerClusterName = local  #所属集群名称
brokerName = broker-a #Broker名称
brokerId = 0 #0表示Master节点
listenPort=11001 #本地监听端口

deleteWhen = 04 #指定删除过期消息文件的时间点为凌晨4点
fileReservedTime = 48 #指定未发生更新的消息存储文件的保留时长为48小时，48小时后过期，将会被删除 
brokerRole = ASYNC_MASTER #Broker角色，异步复制Master：ASYNC_MASTER，同步双写Master：SYNC_MASTER，slave节点：SLAVE
flushDiskType = ASYNC_FLUSH #消息刷新到磁盘的方式： ASYNC_FLUSH: 异步刷盘，SYNC_FLUSH：同步刷盘

autoCreateTopicEnable = true #是否允许 Broker 自动创建Topic
autoCreateSubscriptionGroup = true #是否允许 Broker 自动创建订阅组

# 这是nameserver的启动地址,broker会基于该nameserver进行通信
namesrvAddr=127.0.0.1:10001;127.0.0.1:10002

# 这是存储路径，你设置为你的rocketmq运行目录的store子目录
storePathRootDir=D:/rocketmqHome/broker-1/store

# 这是commitLog的存储路径
storePathCommitLog=D:/rocketmqHome/broker-1/store/commitlog

# consume queue文件的存储路径
storePathConsumeQueue=D:/rocketmqHome/broker-1/store/consumequeue

# 消息索引文件的存储路径
storePathIndex=D:/rocketmqHome/broker-1/index

# checkpoint文件的存储路径
storeCheckpoint=D:/rocketmqHome/broker-1/checkpoint

# abort文件的存储路径
abortFile=D:/rocketmqHome/broker-1/store/abort

Broker-2和Broker-3的配置，也是作为Master节点进行部署，只需要修改brokerName和listenPort

多组节点多副本

通过组合使用如下brokerName和brokerId参数，就可以配置出想要的多组节点多副本的集群。角色为Master的Broker brokerId=0 slave则为>0，同一个副本的BrokerName必须相同。给出一个副本配置示例如下：

1
2
3
brokerName = broker-a
brokerId = 0
brokerRole = ASYNC_MASTER
1
2
3
brokerName = broker-a
brokerId = 1
brokerRole = SLAVE

主备自动切换模式

NameServer需要增加如下配置，进而打开Controller主备自动切换模式。如下举个栗子
新增：

1
2
3
4
5
6
enableControllerInNamesrv = true
#下面三个配置Dleger组件
controllerDLegerGroup = group 
#Raft的peers地址，前缀和第三个配置对应
controllerDLegerPeers = n0-127.0.0.1:12001;n1-127.0.0.1:12002;n2-127.0.0.1:12003 
controllerDLegerSelfId = n0

Broker的配置需要进行修改
新增：

1
2
enableControllerMode = true #打开controller模式
controllerAddr = 127.0.0.1:12001;127.0.0.1:12002;127.0.0.1:12003 #配置controller集群的地址

删除：

1
2
brokerId =
brokerRole =

是经过测试，发现这两个参数在此部署模式下是不需要的。brokerId自动下发，brokerRole 默认为SYNC_MASTER且不可以覆盖。
测试了关闭其中一个Master，SLAVE能自动被选举为Master，做到灾备自动切换。

总结

比较一下这几种部署模式，引用官网的描述：

  1. 单组节点单副本
    不建议生产使用

  2. 多组节点单副本

  • 单个Master宕机或重启维护对应用读写无影响
  • Master宕机期间，Broker上未被消费的消息不可被订阅，影响时效性
  • Master宕机，磁盘损坏的情况下，异步刷盘丢失少量消息，同步刷盘一条不丢
  • 性能最高
  1. 多组节点多副本-异步复制
  • 单个Master宕机或重启维护对应用读写无影响
  • Master宕机，可以继续从Slave消费，不需要人工干预，不影响时效性
  • Master宕机，磁盘损坏情况下会丢失少量消息
  • 性能和第2中模式几乎一样

4.多组节点多副本-同步双写

  • 单个Master宕机或重启维护对应用读写无影响
  • Master宕机，可以继续从Slave消费，不需要人工干预，不影响时效性
  • Master宕机，磁盘损坏情况下不会丢失消息
  • 性能比异步复制模式略低（大约低10%左右），发送单个消息的RT会略高
  • 目前版本在主节点宕机后，备机不能自动切换为主机

5.主备自动切换模式
相比第4中模式，能够完成主备自动切换。

总结一下，个人认为模式3，5比较适合生产部署。3 侧重性能，5 侧重可靠性。4模式由于不具备灾备切换的能力所以不建议部署。除非在5的模式中如果Controller组件经常发生故障，那么考虑用4替换5的模式。