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可以保证吞吐量。文章来源：https://www.toymoban.com/news/detail-513651.html
最后如果对性能要求较高,对消息丢失存在一定的容忍度可以配置为ASYNCMASTER + ASYNCFLUSH文章来源地址https://www.toymoban.com/news/detail-513651.html
到了这里，关于14.RocketMQ之高可用性机制的文章就介绍完了。如果您还想了解更多内容，请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章，希望大家以后多多支持TOY模板网！
