RocketMQ存储篇——HA高可用

在集群模式的部署方式中,Master与Slave配对是通过指定相同的brokerName参数来配对,Master的BrokerId必须是0,Slave的BrokerId必须是大于0的数。一个Master下面可以挂载多个Slave,同一个Master下的多个Slave通过指定不同的BrokerId来区分。有4种部署方式:

部署方式 优点 缺点 备注
单个Master模式 一旦Broker重启或者宕机时,会导致整个服务不可用,不建议线上环境使用;
多个Master模式 配置简单,单个Master宕机或重启维护对应用无影响,在磁盘配置为RAID10时,即使机器宕机不可恢复情况下,由于RAID10磁盘非常可靠,消息也不会丢(异步刷盘丢失少量消息,同步刷盘一条不丢),性能最高。 单台机器宕机期间,这台机器上未被消费的消息在机器恢复之前不可订阅,消息实时性会收到影响。 当使用多master无slave的集群搭建方式时,master的brokerRole配置必须为ASYNC_MASTER。如果配置为SYNC_MASTER,则producer发送消息时,返回值的SendStatus会一直是SLAVE_NOT_AVAILABLE。
多Master多Slave模式——异步复制 即使磁盘损坏,消息丢失的非常少,但消息实时性不会受影响,因为Master宕机后,消费者仍然可以从Slave消费,此过程对应用透明,不需要人工干预,性能同多Master模式几乎一样。 Master宕机,磁盘损坏情况,会丢失少量信息。
多Master多Slave模式——同步双写 数据与服务都无单点,Master宕机情况下,消息无延迟,服务可用性与数据可用性都非常高; 性能比异步复制模式稍低,大约低10%左右,发送单个消息的RT会稍高,目前主宕机后,备机不能自动切换为主机,后续会支持自动切换功能。

在集群模式下,为了保证高可用,必须要保证备用Broker与主用Broker信息是一致的,在备用Broker初始化时设置的了定时任务,每个60秒调用SlaveSynchronize.syncAll()方法发起向主用Broker进行一次config类文件的同步,而消息数据的同步由主备Broker通过心跳检测的方式完成,每隔5秒进行一次心跳。 主用Broker提供读写服务,而备用Broker只提供读服务。

1 Topic配置同步

在syncAll方法中调用SlaveSynchronize.syncTopicConfig()方法向主用Broker发起topics.json文件的同步。大致步骤如下:

1)向主用Broker发起GET_ALL_TOPIC_CONFIG请求码,主用Broker将所有topic配置信息返回给备用Broker;

2)比较主备topic信息的DataVersion;若不同则用主用Broker返回的topic配置信息更新备用Broker的topic,并进行持久化,同时更新备用Broker中topic信息的DataVersion。

2 消费进度信息同步

在syncAll方法中调用SlaveSynchronize. syncConsumerOffset ()方法向主用Broker发起consumerOffset.json文件的同步。大致步骤如下:

1)向主用Broker发起GET_ALL_CONSUMER_OFFSET请求码,主用Broker将所有ConsumerOffset配置信息返回给备用Brok

  • 5
    点赞
  • 20
    收藏
    觉得还不错? 一键收藏
  • 1
    评论
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值