RocketMQ（三）—— 集群模式的说明

集群理论

复制与刷盘策略

复制：

复制策略是Broker的Master与Slave间的数据同步方式。分为同步复制与异步复制：

• 同步复制：消息写入master后，master会等待slave同步数据成功后才向producer返回成功ACK

• 异步复制：消息写入master后，master立即向producer返回成功ACK，无需等待slave同步数据成功

异步复制降低系统写入延迟，提高系统吞吐量

刷盘：

刷盘策略指的是broker中消息的落盘方式，即消息发送到broker内存后消息持久化到磁盘的方式。分为同步刷盘与异步刷盘：

• 同步刷盘：当消息持久化到broker的磁盘后才算是消息写入成功。

• 异步刷盘：当消息写入到broker的内存后即表示消息写入成功，无需等待消息持久化到磁盘。

消息写入到Broker的内存，一般是PageCache

异步刷盘策略写入成功后立即返回ACK，但不会立即做落盘操作，而是当PageCache到达一定数量时，会自动进行落盘

Broker 集群模式

根据Broker集群各个节点关系不同，Broker集群可以分为以下几类：

单Master

只有一个Broker。一般在测试环境下使用，生产环境会存在单点问题

多Master

broker集群仅由多个master组成，不存在Slave，同一个Topic的各个Queue会平均分布在各个Master节点上

优点：

• 配置简单，单个Master宕机或重启对服务无影响
• 若磁盘配置为RAID10，即使机器宕机不可恢复，消息也丢失也极少（异步刷盘丢失少量消息，同步刷盘不会丢失）
• 性能最高

若没有配置RAID磁盘阵列，则出现Master宕机依然会出现大量消息丢失的情况

缺点：

• 单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅（不可消费），消息实时性能会受到影响

多Master多Slave模式-异步复制

Broker集群由多个Master构成，每个Master又配置了一个或多个Slave。Master与Slave的关系是主备关系，即Master负责处理消息的读写请求，Slave仅负责消息的备份与Master宕机后的角色切换。

若配置了RAID磁盘阵列，一般一个Master配置一个Slave即可

该模式的最大特点之一是：当master宕机后slave能够自动切换为master。

• 由于slave从master的同步具有短暂的延迟（毫秒级），所以当master宕机后，这种异步复制方式可能会存在少量消息的丢失问题。

Slave从Master同步的延迟越短，其可能丢失的消息就越少

对于Master的RAID磁盘阵列，若使用的也是异步复制策略，同样也存在延迟问题，同样也可能会丢失消息。但RAID阵列的延迟是微秒级的（硬件支持），所以其丢失的数据量会更少。

多Master多Slave模式-同步双写

该模式是多Master多Slave模式的同步复制实现。所谓同步双写，指的是消息写入master成功后，master会等待slave同步数据成功后才向producer返回成功ACK，即master与slave都要写入成功后才会返回成功ACK，也即双写

优点：

该模式与异步复制模式相比，消息的安全性更高，不存在消息丢失的情况。

缺点：

• 单个消息的响应时间略高，从而导致性能要略低（大约低10%）。

• 对于目前版本，Master宕机后，Slave不能自动切换到Master

最佳模式：

给Master配置RAID10磁盘阵列，然后为其配置一个Slave。既利用了RAID10的高效、安全，又解决了可能影响订阅的问题

注意：

• RAID磁盘阵列效率高于Master-Slave集群，当然，搭建成本也较高
• 多Master+RAID与多Master多Slave模式的区别是：
  • 多master+raid可以保证数据不丢失，但可能会影响到消息订阅。执行效率高于多Master 多Slave集群
  • 多master多Slave集群，可以保证数据不丢失，并且不会影响消息写入。但是运行效率比多Master+RAID阵列低