在集群模式的部署方式中,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