高可用配置(异步复制和同步复制)-metaq

介绍

Meta相比于kafka的一个重要特性就是消息高可用方案的实现,我们称之为HA方案。消息在发送到broker之后立即写入磁盘才返回客户端告诉消息生产者消息发送成功,通过unflushThresholdunflushInterval两个参数的控制,可以保证单机消息数据的安全性,只要机器的磁盘没有永久损坏,消息总可以在重启后恢复并正常投递给消费者们。但是,如果遇到了磁盘永久损坏或者数据文件永久损坏的情况,那么该broker上的消息数据将可能永久丢失。为了防止这种情况的发生,一个可行的方案就是将消息数据复制到多台机器,类似mysql的主从复制功能。

同步复制和异步复制

meta提供类似mysql主从复制的异步复制和同步功能,分别对应不同的可靠级别。理论上说同步复制能带来更高的可靠级别,异步复制因为延迟的存在,可能会丢失极少量的消息数据,相应地,同步复制会带来性能的损失,因为要同步写入两台甚至更多的broker机器上才算写入成功。

在实际实践中,我更推荐采用异步复制的架构,因为异步复制的架构相对简单,并且易于维护和恢复,对性能也没有影响。而同步复制对运维要求相对很高,机制复杂容易出错,故障恢复也比较麻烦。异步复制加上磁盘做磁盘阵列,足以应对非常苛刻的数据可靠性要求。

异步复制配置

假设你已经配置了一台broker服务器,并且配置了一个topic为test,现在你希望test能复制到另一台slave broker上来保证消息数据的高可用。你可以这样做:

1.首先,你需要部署一个新的broker,配置server.ini从master broker拷贝一份。

2.其次,配置slave文件。编辑conf/async_slave.properties:

#slave编号,大于等于0表示作为slave启动,同一个master下的slave编号应该设不同值. slaveId=0 #作为slave启动时向master订阅消息的group,如果没配置则默认为meta-slave-group #不同的slaveId请使用不同的group slaveGroup=meta-slave-group #slave数据同步的最大延时,单位毫秒 slaveMaxDelayInMills=500 #是否自动从master同步server.ini, 1.4.2新增选项 #第一次仍然需要自己拷贝server.ini,后续可以通过设置此选项为true来自动同步 autoSyncMasterConfig=true 

配置参数的含义请自己看注释。可见,一个master可以复制到多个slave。

3.执行下列命令启动slave:

bin/metaServer.sh start slave 

4.第一次复制因为需要跟master完全同步需要耗费一定时间,你可以在数据文件的目录观察复制情况。

5.请注意,异步复制的slave将参与消费者的消费活动,消息消费者可以从slave中获取消息并消费,消费者会随机从master和slaves中挑选一台作为消费broker。

6.请注意,从1.4.2开始,可以通过autoSyncMasterConfig选项配置是否自动同步master的server.ini到异步复制的slave上,当master的server.ini文件变更并通过bin/metaServer.sh reload之后,slave将监控到这一变更并自动同步。

异步复制的局限

  • 异步复制有延迟,虽然可以通过设定slaveMaxDelayInMills来控制延迟。

异步复制的故障处理

  • Master永久故障: 将slave作为master启动,去除启动参数中的slave即可,也就是metaServer.sh restart
  • Slave永久故障: 启动新的broker并配置作为master新的slave启动。
  • 来自淘宝

你可能感兴趣的:(metaq)