第三章:RocketMQ集群与搭建

数据复制与刷盘策略

复制策略

复制策略是Broker的Master与Slave间的数据同步方式。分为同步复制与异步复制

同步复制(SYNC_MASTER)：消息写入master后，master会等待slave同步数据成功后才向Producer返回成功ACK
异步复制(ASYNC_MASTER)：消息写入master后，master立即就向Producer返回成功ACK，无需等待slave同步数据成功

ACK:即一种消息确认字符，在数据通信中，消息接受站给消息发送站的一种传输类控制符，表示传输过来的数据已经接受无误。

刷盘策略

刷盘策略指的是Broker中的消息的落盘方式,既消息发送到Broker内存后消息持久化到磁盘的方式。也会分同步刷盘和异步刷盘：

同步刷盘：当消息持久化到Broker的磁盘后才算是消息写入成功
异步刷盘：当消息写入到Broker的内存后既表示消息写入成功，无需等待消息持久化到磁盘

当选择异步复制、刷盘毫无疑问这样提高了效率，无需等待。一条消息进来后会存到PageCache(内存缓存)中，它会等到达到一定的数据量时再进行批量刷盘操作。

这种思想在数据同步领域都可以进行效仿。

集群模式

单Master模式

只有一个master时，严格意义来说不算是集群。单master的风险很大，一旦Broker重启或者宕机时，会导致整个服务不可用。不建议线上环境使用，可以用于本地测试。

多Master模式

这种集群模式没有Slave，都是Master，同一个Topic的各个Queue会平均分布在各个master节点上。比如2个或多个Master，这种模式的优缺点如下：

优点：配置简单，单个master宕机或重启维护对应应用无影响，在磁盘配置为RAID10时，即使机器宕机不可恢复情况下，由于RAID10磁盘非常可靠，消息也不会丢（异步刷盘丢失少量消息，同步刷盘一条不丢），性能最高
缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到影响

RAID 0 条带技术 + RAID 1 镜像技术

RAID10磁盘阵列：RAID磁盘阵列

多Master多Slave模式-异步复制

每个Master配置一个Slave，有多对Master-Slave，Master与Slave的关系是主备关系（master负责处理消息的读写请求，而Slave仅负责消息的备份和当master宕机后的角色切换）。HA采用异步复制方式,主备有短暂消息延迟（毫秒级），这种模式的优缺点如下：

优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，同时Master宕机后，消费者仍然可以从Slave消费，而且此过程对应用透明（无感知的），不需要人工干预，性能同多Master模式几乎一样。
缺点：Master宕机，磁盘损坏情况下会丢失少量消息。

很显然Slave从Master同步的延迟越短，其可能丢失的消息就越少

对于多Master的RAID磁盘阵列，若使用的也是异步复制策略，同样也存在这种延迟问题而丢失消息。但RAID阵列的秘诀是微秒级的（因为是由硬件支持的），所以其丢失的数据量会更少

多Master多Slave模式-同步双写

每个Master配置一个Slave，有多对Master-Slave，HA采用同步双写方式，即只有主备都写成功，才向应用返回成功，这种模式的优缺点如下：

优点：数据与服务都无单点故障，Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高；
缺点：性能比异步复制模式略低（大约低10%左右），发送单个消息的RT(real-time)会略高，且目前版本在主节点宕机后，Slave不能自动切换为Master。

最佳实践

我们可以结合多Master多Slave模式和RAID磁盘阵列的优点将Master配置RAID10磁盘阵列，然后再为其配置一个Slave，这样既利用了RAID10磁盘阵列的高效、安全性又解决了可能会影响订阅的问题。

集群搭建实践

目标

搭建一个双主双从异步复制的Broker集群。使用两台主机来完成集群的搭建，功能与briker角色分配如下表：

主机名	IP	功能	BROKER角色
rockertmqOS1	192.168.146.101	NameServer+Broker	Master1+Slave2
rockertmqOS2	192.168.146.102	NameServer+Broker	Master2+Slave1

在Broker角色中，M1和S1是错开的，因为如果M1和S1在同一台服务器上，而这台服务器挂了，那么备份也挂了，这样的主备毫无意义！！

克隆系统

修改名称：vim /etc/hostname
查看显卡：ifconfig

修改配置文件：mv /etc/sysconfig/network-scripts/ifcfg-eno... /etc/sysconfig/network-scripts/ifcfg-ens33
修改静态IP：vim /etc/sysconfig/network-scripts/ifcfg-ens33

重启系统：reboot

修改配置文件

进入rocketmq的配置文件夹cd /opt/environment/rocketmq-4.9.2/conf/

可以看到它默认提供了三种模式

2master-2slave-异步
2master-2slave-同步
2master

选择目标：2M+2S+ASYNC cd 2m-2s-async/

修改broker-a.properties

# 指定整个broker集群的名称，或者说是RockerMQ集群的名称
brokerClusterName=DefaultCluster
# 指定master-slave集群的名称，一个RockerMQ集群可以包含多个m-s集群
brokerName=broker-a
# master的brokerId为0
brokerid=0
# 指定删除消息储存过期文件的时间为凌晨4点
deleteWhen=04
# 指定未发生更新的消息储存文件的保留时长为48小时，48小时后过期，将会被删除
fileReservedTime=48
# 指定当前broker为异步复制master
brokerRole=ASYNC_MASTER
# 指定刷盘策略为异步刷盘
flushDiskType=ASYNC_FLUSH
#指定name server的地址
namesrvAddr=192.168.146.101:9876;192.168.146.102:9876

修改broker-b-s.properties

## 要添加的内容
namesrvAddr=192.168.146.101:9876;192.168.146.102:9876
# 指定Broker对外提供服务的端口，即Broker与Producer、Consumer通信的端口，默认为10911，由于当前主机同时充当着master1与slave2，而前面的master1使用的默认端口，这里需要修改成另一个端口号
listenPort=11911
# 指定消息存储相关的路径，默认路径为~/store目录，这里也另改个名字加以区分
storePathRootDir=~/store-s
storePathCommitLog=~/store-s/commitlog
storePathConsumeQueue=~/store-s/consumerqueue
storePathIndex=~/store-s/index
storeCheckpoint=~/store-s/checkpoint
abortFile=~/store-s/abort

克隆一台rocketmqOS2主机（基于OS1）配置rocketmqOS2的配置文件（brocker-a-s.properties、broker-b.properties）

配置内容与上面一致，对于其他的配置文件不用管

启动

启动NameServer集群

分别启动roketmqOS1与rocketmqOS2两个主机中的NameServer

nohup sh bin/mqnamesrv &

启动两个Mster

分别启动roketmqOS1与rocketmqOS2两个主机中的broker master，注意需要指定所配置的配置文件

OS1:nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a.properties &
OS2:nohup sh bin/mqbroker -c conf/2m-2s-async/broker-b.properties &## 查看日志
tail -f ~/logs/rocketmqlogs/broker.log

启动两个Slave

OS1:nohup sh bin/mqbroker -c conf/2m-2s-async/broker-b-s.properties &
OS2:nohup sh bin/mqbroker -c conf/2m-2s-async/broker-a-s.properties &

如上图可以看到已经有1个Nameserve和2个Broker启动了