Ha

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

#同步复制和异步复制

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

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

#异步复制配置

假设你已经根据如何开始这份文档配置了一台broker服务器，并且配置了一个topic为test，现在你希望test能复制到另一台slave broker上来保证消息数据的高可用。你可以这样做：

1.首先，你需要部署一个新的broker，具体仍然参照如何开始这份文档，配置server.ini从master broker拷贝一份，特别注意，一定要保证brokerId的一致，其次是对topic列表根据你的要求做删减，去除不准备参与复制的topic。

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可以复制到多个slave。

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

sh meta-server-start.sh -f ../conf/server.properties -Fmetaslave=../conf/async_slave.properties

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

##异步复制的局限

• 异步复制只能复制在slave的server.ini中配置并且在master中存在的topic，没有配置则无法复制。因此，在master新增topic的情况下，slave是无法自动感知到新的topic，需要修改slave配置并重新热加载或者重启slave来处理。
• 异步复制有延迟，虽然可以通过设定slaveMaxDelayInMills来控制延迟。

##异步复制的故障处理

• Master永久故障： 将slave作为master启动，只要去除驱动参数中的-Fmetaslave=../conf/async_slave.properties即可。
• Slave永久故障： 启动新的broker并配置作为master新的slave启动。