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

介绍

Meta相比于kafka的一个重要特性就是消息高可用方案的实现，咱们称之为HA方案。消息在发送到broker以后当即写入磁盘才返回客户端告诉消息生产者消息发送成功，经过unflushThreshold和unflushInterval两个参数的控制，能够保证单机消息数据的安全性，只要机器的磁盘没有永久损坏，消息总能够在重启后恢复并正常投递给消费者们。可是，若是遇到了磁盘永久损坏或者数据文件永久损坏的状况，那么该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启动。

同步复制配置

TODO