【RocketMQ的高可用原理机制、RocketMQ的集群部署方式、数据刷盘机制中的同步刷盘和异步刷盘、主从同步机制和主从异步机制、broker文件中的相关配置信息以及代表的含义】

一.知识回顾

【0.RocketMQ专栏的内容在这里哟，帮你整理好了，更多内容持续更新中】
【1.Docker安装部署RocketMQ消息中间件详细教程】
【2.RocketMQ生产者发送消息的三种方式:发送同步消息、异步消息、单向消息&案例实战&详细学习流程】
【3.RocketMQ消费者进行消费消息的二种方式:集群消费、广播消费&案例实战&详细学习流程&集群消费模、广播模式的适用场景&注意事项】
【4.RocketMQ中的顺序消息、生产者顺序生产消息、消费者顺序消费消息、顺序包括全局有序和分块有序、代码样例实战】
【5.RocketMQ中延时消息的生产与消费、批量消息的生产与消费、消息的过滤、消息的Tag过滤和SQL过滤、SQL过滤解决SQL92问题，代码样例实战】
【6.RocketMQ分布式事务消息、RocketMQ分布式事务的发展流程、RocketMQ分布式事务二阶段提交解决方案、分布式案例实操学习、RocketMQ分布式事务使用场景以及注意事项】
【7.一文带你详细学习RocketMQ存储设计方案、RocketMQ中消息文件存储结构、过期文件删除机制、零拷贝与MMAP内存映射】

二.RocketMQ的高可用

2.1 RocketMQ的高可用原理机制

1. RocketMQ分布式集群是通过Master和Slave的配合达到高可用性的。

2. Master和Slave的区别：在Broker的配置文件中，参数 brokerId的值为0表明这个Broker是Master，大于0表明这个Broker是 Slave，同时brokerRole参数也会说明这个Broker是Master还是Slave。

   brokerId=0代表主
   brokerId=1代表从（大于0都代表从）
   brokerRole=SYNC_MASTER 同步复制（主从）
   brokerRole=ASYNC_MASTER异步复制（主从）
   flushDiskType=SYNC_FLUSH 同步刷盘
   flushDiskType=ASYNC_FLUSH 异步刷盘

3. Master角色的Broker支持读和写，Slave角色的Broker仅支持读，也就是 Producer只能和Master角色的Broker连接写入消息；Consumer可以连接 Master角色的Broker，也可以连接Slave角色的Broker来读取消息。

2.2 RocketMQ集群部署方式

2.2.1 单 master 模式

概念:只有一个 master 节点，称不上是集群，一旦这个 master 节点宕机，那么整个服务就不可用。
不是集群部署，那么它的优点和缺点也就无从谈起。

2.2.2 多 master 模式

概念:多个 master 节点组成集群，单个 master 节点宕机或者重启对应用没有影响。
优点：所有模式中性能最高，一个Topic可以分布在不同的master，进行横向拓展。
在多主架构体系下，无论使用客户端还是管理端创建主题，一个主题都会创建多份队列在多主中，默认是4个的话，双主就会有8个队列，每台主4个队列，所以双主可以提高性能，一个Topic的分布在不同的master，方便进行横向拓展。
缺点：单个 master 节点宕机期间，未被消费的消息在节点恢复之前不可用，消息的实时性就受到影响。

2.2.3 多master 多 slave 异步复制模式

概念:从节点Slave就是复制主节点的数据，对于生产者完全感知不到，对于消费者正常情况下也感知不到。只有当Master不可用或者繁忙的时候，Consumer会被自动切换到从Slave 读。
在多 master 模式的基础上，每个 master 节点都有至少一个对应的 slave。master节点可读可写，但是 slave只能读不能写，类似于 mysql 的主备模式。
优点： 一般情况下都是master消费，在 master 宕机或超过负载时，消费者可以从 slave 读取消息，消息的实时性不会受影响，性能几乎和多 master 一样。
缺点：使用异步复制的同步方式有可能会有消息丢失的问题。（Master宕机后，生产者发送的消息没有消费完，同时到Slave节点的数据也没有同步完）

2.2.4 多master多 slave主从同步复制+异步刷盘（最优推荐）

概念: 多个master，多个slave节点
优点：主从同步复制模式能保证数据不丢失。
缺点：发送单个消息响应时间会略长，性能相比异步复制低10%左右。
对数据要求较高的场景，主从同步复制方式，保存数据热备份，通过异步刷盘方式，保证rocketMQ高吞吐量。

2.3 数据刷盘机制

2.3.1 刷盘机制

1. 生产时首先将消息写入到 MappedFile,内存映射文件，然后根据刷盘策略刷写到磁盘。可以理解成使用MMAP中的MappedByteBuffer中实际用flip()最后的刷新机制.

2. RocketMQ的刷盘是把消息存储到磁盘上的，这样既能保证断电后恢复， 又可以让存储的消息量超出内存的限制。RocketMQ为了提高性能，会尽可能地保证磁盘的顺序写。消息在通过Producer写入RocketMQ的时候，有两种写磁盘方式，同步刷盘和异步刷盘。

3. 配置文件设置刷盘的参数

   通过配置文件色设置数据的刷盘机制
   brokerId=0代表主
   brokerId=1代表从（大于0都代表从）
   brokerRole=SYNC_MASTER 同步复制（主从）
   brokerRole=ASYNC_MASTER异步复制（主从）
   flushDiskType=SYNC_FLUSH 同步刷盘
   flushDiskType=ASYNC_FLUSH 异步刷盘

2.3.2 同步刷盘

flushDiskType=SYNC_FLUSH 同步刷盘：生产者发送的每一条消息都在保存到磁盘成功后才返回告诉生产者成功。这种方式不会存在消息丢失的问题，但是有很大的磁盘IO开销，性能有一定影响。

2.3.3 异步刷盘

1. flushDiskType=ASYNC_FLUSH 异步刷盘 ：生产者发送的每一条消息并不是立即保存到磁盘，而是暂时缓存起来，然后就返回生产者成功。
2. 接下来异步的将缓存数据保存到磁盘，有两种情况：

• 一种情况是:定期将缓存中更新的数据进行刷盘
• 另外一种情况是:当缓存中更新的数据条数达到某一设定值后进行刷盘。这种异步的方式会存在消息丢失（在还未来得及同步到磁盘的时候宕机），但是性能很好。默认是这种模式。注意:4.8.0版本中默认值下是异步刷盘。

2.4 主从同步机制

2.4.1 同步异步机制

1. 集群环境下需要部署多个Broker，Broker分为两种角色：一种是master，即可以写也可以读，其brokerId=0，只能有一个；另外一种是slave，只允许读，其brokerId为非0,也就是大于0的值。
2. 一个master与多个slave通过指定相同的brokerClusterName被归为一个broker set（broker集）。
3. 通常生产环境中，我们至少需要2个broker set。Slave是复制master的数据。一个Broker组有Master和Slave，消息需要从Master复制到Slave 上，有同步和异步两种复制方式。

2.4.2 主从同步复制

1. 主从同步复制方式（Sync Broker）：生产者发送的每一条消息都至少同步复制到一个slave后才返回告诉生产者成功，即“同步双写”
2. 在同步复制方式下，如果Master出故障， Slave上有全部的备份数据，容易恢复，但是同步复制会增大数据写入延迟，降低系统吞吐量。

2.4.3 主从异步复制

1. 主从异步复制方式（Async Broker）：生产者发送的每一条消息只要写入master就返回告诉生产者成功。然后再“异步复制”到slave。
2. 在异步复制方式下，系统拥有较低的延迟和较高的吞吐量，但是如果Master出了故障，有些数据因为没有被写入Slave，有可能会丢失；

2.5 broker文件中的相关配置信息以及代表的含义

brokerId=0代表主
brokerId=1代表从（大于0都代表从）
brokerRole=SYNC_MASTER  同步复制（主从）
brokerRole=ASYNC_MASTER 异步复制（主从）
flushDiskType=SYNC_FLUSH   同步刷盘
flushDiskType=ASYNC_FLUSH  异步刷盘

好了，到这里【RocketMQ的高可用原理机制、RocketMQ的集群部署方式、数据刷盘机制中的同步刷盘和异步刷盘、主从同步机制和主从异步机制、broker文件中的相关配置信息以及代表的含义】就先学习到这里，写一篇文章我们将要学习生产者和消费者的高可用机制。敬请期待。