数据复制与刷盘策略
复制策略
? 复制策略是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启动了