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