1.2 高可用性机制
RocketMQ分布式集群是通过Master和Slave的配合达到高可用性的。
Master和Slave的区别:在Broker的配置文件中,参数 brokerId的值为0表明这个Broker是Master,大于0表明这个Broker是 Slave,同时brokerRole参数也会说明这个Broker是Master还是Slave。
Master角色的Broker支持读和写,Slave角色的Broker仅支持读,也就是 Producer只能和Master角色的Broker连接写入消息;Consumer可以连接 Master角色的Broker,也可以连接Slave角色的Broker来读取消息。
1.2.1 消息消费高可用
在Consumer的配置文件中,并不需要设置是从Master读还是从Slave 读,当Master不可用或者繁忙的时候,Consumer会被自动切换到从Slave 读。有了自动切换Consumer这种机制,当一个Master角色的机器出现故障后,Consumer仍然可以从Slave读取消息,不影响Consumer程序。这就达到了消费端的高可用性。
1.2.2 消息发送高可用
在创建Topic的时候,把Topic的多个Message Queue创建在多个 Broker上(相同Broker名称,不同 brokerId的机器组成一个Broker组)比如broker-A 和 broker-B,这样当一个Broker组的Master不可 用后,其他组的Master仍然可用,Producer仍然可以发送消息。
RocketMQ目前还不支持把Slave自动转成Master,如果机器资源不足, 需要把Slave转成Master,则要手动停止Slave角色的Broker,更改配置文件,用新的配置文件启动Broker。
发送消息失败的规避策略
1.2.3 消息主从复制
如果一个Broker组有Master和Slave,消息需要从Master复制到Slave 上,Master有同步复制和异步复制两种复制方式。
slave 代表是从节点不需要配置
SYNC_MASTER-同步复制
同步复制方式是等Master和Slave均写成功后才反馈给客户端写成功状态。
在同步复制方式下,如果Master出故障, Slave上有全部的备份数据,容易恢复,但是同步复制会增大数据写入延迟,降低系统吞吐量。
ASYNC_MASTER-异步复制
异步复制方式是只要Master写成功 即可反馈给客户端写成功状态。
在异步复制方式下,系统拥有较低的延迟和较高的吞吐量.
但是如果Master出了故障,有些数据因为没有被写 入Slave,有可能会丢失;
SLAVE-从节点
Slave 代表是从节点不需要配置
1.2.4 刷盘策略
同步刷盘-写入磁盘
在返回写成功状态时,消息已经被写入磁盘。具体流程是,消息写入内存的PAGECACHE后,立刻通知刷盘线程刷盘, 然后等待刷盘完成,刷盘线程执行完成后唤醒等待的线程,返回消息写 成功的状态。
异步刷盘-写入PAGECACHE
在返回写成功状态时,消息可能只是被写入了内存的PAGECACHE,写操作的返回快,吞吐量大;当内存里的消息量积累到一定程度时,统一触发写磁盘动作,快速写入。
1.2.5 配置
同步刷盘还是异步刷盘,都是通过Broker配置文件里的flushDiskType 参数设置的,这个参数被配置成SYNCFLUSH、ASYNCFLUSH中的 一个。
推荐配置:SYNCMASTER + ASYNCFLUSH
主从同步复制
同步复制是等Master和Slave均写成功后才反馈给客户端写成功状态。
异步复制方式是只要Master写成功即可反馈给客户端写成功状态
这两种复制方式各有优劣:
在异步复制方式下,系统拥有较低的延迟和较高的吞吐量,但是如果Master出了故障,有些数据因为没有被写入Slave,有可能会丢失。
在同步复制方式下,如果Master出故障,Slave上有全部的备份数据,容易恢复。但是同步复制会增大数据写入延迟,降低系统吞吐量。
如果对于消息有零丢失的要求,设置主从同步方式为主从同步复制即可。否则可以选择异步复制的方式。
主从异步刷盘
实际应用中要结合业务场景,合理设置刷盘方式和主从复制方式,尤其是SYNC_FLUSH方式,由于频繁的触发写磁盘动作,会明显降低性能。
通常情况下,应该把Master和Slave设置成ASYNC_FLUSH的刷盘方式。
总结
主从之间配置成SYNC_MASTER的复制方式,这样即使有一台机器出故障,仍然可以保证数据不丢。
**主从刷盘策略配置为ASYNC_FLUSH可以保证吞吐量。
由于配置的主从同步方式是SYNCMASTER,主从刷盘策略配置为ASYNCFLUSH。这样可以保证master和slave的消息都写入到了内存中,即使主从有1台机器发生故障,至少有1台机器存在全量的消息。2台机器同时发生故障的几率太小了,以至于可以忽略不计。
总结:SYNCMASTER可以保证消息不丢失,ASYNCFLUSH可以保证吞吐量。
最后如果对性能要求较高,对消息丢失存在一定的容忍度可以配置为ASYNCMASTER + ASYNCFLUSH