14.RocketMQ之高可用性机制

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