本节我们来看看一个双主双从的RocketMQ是如何搭建的。

集群配置参数说明：

在讨论集群前，我们需要了解两个关键的集群配置参数：brokerRole，flushDiskType。brokerRole在前一节已经介绍了，而flushDiskType则是刷盘方式的配置，主要有：

ASYNC_FLUSH: 异步刷盘

SYNC_FLUSH: 同步刷盘

1 如何保证消息存储的可靠性？

brokerRole确定了主从同步是异步的还是同步的，flushDiskType确定了数据刷盘的方式是同步的还是异步的。

如果业务场景对消息丢失容忍度很低，可以采用SYNC_MASTER + ASYNC_FLUSH的方式，这样只有master和slave在刷盘前同时挂掉，消息才会丢失，也就是说即使有一台机器出故障，仍然能保证数据不丢；

如果业务场景对消息丢失容忍度比较高，则可以采用ASYNC_MASTER + ASYNC_FLUSH的方式，这样可以尽可能的提高消息的吞吐量。

2 如何保证消息队列服务的高可用?

消费端的高可用

Master Broker支持读和写，Slave Broker只支持读。

当Master不可用的时候，Consumer会自动切换到Slave进行读，也就是说，当Master节点的机器出现故障后，Consumer仍然可以从Slave节点读取消息，不影响消费端的消费程序。

生产端的高可用

集群配置参数说明：

brokerName: broker的名称，需要把Master和Slave节点配置成相同的名称，表示他们的主从关系，相同的brokerName的一组broker，组成一个broker组；

brokerId: broker的id，0表示Master节点的id，大于0表示Slave节点的id。

在RocketMQ中，机器的主从节点关系是提前配置好的，没有类似Kafka的Master动态选主功能。

如果一个Master宕机了，要让生产端程序继续可以生产消息，您需要部署多个Master节点，组成多个broker组。这样在创建Topic的时候，就可以把Topic的不同消息队列分布在多个broker组中，即使某一个broker组的Master节点不可用了，其他组的Master节点仍然可用，保证了Producer可以继续发送消息。

3 如何构建一个高可用的RocketMQ双主双从最小集群？

为了尽可能的保证消息不丢失，并且保证生产者和消费者的可用性，我们可以构建一个双主双从的集群，搭建的架构图如下所示：

部署架构说明：

两个Broker组，保证了其中一个Broker组的Master节点挂掉之后，另一个Master节点仍然可以接受某一个Topic的消息投递；
主从同步采用SYNC_MASTER，保证了生产者写入消息到Master之后，需要等到Slave也复制成功，才返回消息投递成功。这样即使主节点或者从节点挂掉了，也不会导致丢数据；
由于主节点有了从节点做备份，所以，落盘策略可以使用ASYNC_FLUSH，从而尽可能的提高消息的吞吐量；
如果只提供两台服务器，要部署这个集群的情况下，可以把Broker Master1和Broker Slave2部署在一台机器，Broker Master2和Broker Slave1部署在一台机器。

关键配置参数

以下是关键的配置参数：

Broker Master1

# NameServer地址
namesrvAddr=192.168.1.100:9876;192.168.1.101:9876
# 集群名称
brokerClusterName=itzhai-com-cluster
# brokerIP地址
brokerIP1=192.168.1.100
# broker通信端口
listenPort=10911
# broker名称
brokerName=broker‐1
# 0表示主节点
brokerId=0
# 2点进行消息删除
deleteWhen=02
# 消息在磁盘上保留48小时
fileReservedTime=48
# 主从同步复制
brokerRole=SYNC_MASTER
# 异步刷盘
flushDiskType=ASYNC_FLUSH
# 自动创建Topic
autoCreateTopicEnable=true
# 消息存储根目录
storePathRootDir=/data/rocketmq/store‐m

Broker Slave1

# NameServer地址
namesrvAddr=192.168.1.100:9876;192.168.1.101:9876
# 集群名称
brokerClusterName=itzhai-com-cluster
# brokerIP地址
brokerIP1=192.168.1.101
# broker通信端口
listenPort=10911
# broker名称
brokerName=broker‐1 
# 非0表示从节点
brokerId=1
# 2点进行消息删除
deleteWhen=02
# 消息在磁盘上保留48小时
fileReservedTime=48
# 从节点
brokerRole=SLAVE
# 异步刷盘
flushDiskType=ASYNC_FLUSH
# 自动创建Topic
autoCreateTopicEnable=true 
# 消息存储根目录
storePathRootDir=/data/rocketmq/store‐s

Broker Master2

# NameServer地址
namesrvAddr=192.168.1.100:9876;192.168.1.101:9876
# 集群名称
brokerClusterName=itzhai-com-cluster
# brokerIP地址
brokerIP1=192.168.1.102
# broker通信端口
listenPort=10911
# broker名称
brokerName=broker‐2
# 0表示主节点
brokerId=0
# 2点进行消息删除
deleteWhen=02
# 消息在磁盘上保留48小时
fileReservedTime=48
# 主从同步复制
brokerRole=SYNC_MASTER
# 异步刷盘
flushDiskType=ASYNC_FLUSH
# 自动创建Topic
autoCreateTopicEnable=true
# 消息存储根目录
storePathRootDir=/data/rocketmq/store‐m

Broker Slave2

# NameServer地址
namesrvAddr=192.168.1.100:9876;192.168.1.101:9876
# 集群名称
brokerClusterName=itzhai-com-cluster
# brokerIP地址
brokerIP1=192.168.1.103
# broker通信端口
listenPort=10911
# broker名称
brokerName=broker‐2
# 非0表示从节点
brokerId=1
# 2点进行消息删除
deleteWhen=02
# 消息在磁盘上保留48小时
fileReservedTime=48
# 从节点
brokerRole=SLAVE
# 异步刷盘
flushDiskType=ASYNC_FLUSH
# 自动创建Topic
autoCreateTopicEnable=true
# 消息存储根目录
storePathRootDir=/data/rocketmq/store‐s

写了那么多顶层架构图，不写写底层内幕，就不是IT宅(itzhai.com)的文章风格，接下来，我们就来看看底层存储架构。

消息队列

RocketMQ集群搭建与实践指南