-
Notifications
You must be signed in to change notification settings - Fork 691
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