RocketMQ如何最大限度的保证消息不丢失的呢？

• 分布式系统中一个重要的前提假设是所有的网络传输都是不可靠的，在网络传输不可靠的情况下，保证消息的可靠传输，除了进行重试投递别无他法。
• 常用的绝大多数消息队列RocketMQ、RabbitMQ等在消息传输上都只能保证至少传输成功一次，也即（At least once），而不能保证只传输成功一次（Exactly once）。
• 由于分布式系统网络的不可靠，可能就会出现消息丢失的现象，那么RocketMQ是如何最大限度的保证消息不丢失的呢？

1高可用
2高可靠
3.那就需要从消息的产生到最终消费的整个过程来分析，消息完整链路可以划分为以下三个阶段：

1. 生产阶段：消息在 Producer 发送端创建出来，经过网络传输发送到 Broker 存储端。
2. 存储阶段：消息在 Broker 端存储，如果是主备或者多副本，消息会在这个阶段被复制到其他的节点或者副本上。
3. 消费阶段：Consumer 消费端从 Broker存储端拉取消息，经过网络传输发送到 Consumer 消费端上，并通过重试来最大限度的保证消息的消费。

1.高可用

1.1 多master

和kafka不一样，RocketMQ中并没有 master 选举功能，在RocketMQ集群中，1台机器只能要么是Master，要么是Slave，这个在初始的机器配置里面，就定死了的。
不会像kafka那样存在master动态选举，所以通过配置多个master节点来保证rocketMQ的高可 用。

多个 master 节点组成集群，单个 master 节点宕机或者重启对应用没有影响

• 优点：高可用，所有模式中性能最高
• 缺点：可能会有少量消息丢失（配置相关），单台机器重启或宕机期间，该机器下未被消费的消息在机器恢复前不可订阅，影响消息实时性
• 注意：使用同步刷盘可以保证消息不丢失，同时 Topic 相对应的 queue 应该分布在集群中各个 master节点，而不是只在某各 master 节点上，否则，该节点宕机会对订阅该 topic 的应用造成影响。

1.2 创建topic指定该topic存储在哪个broker上，指定多个（两个以上），不指定只会在一个broker上创建

1.3nameserver高可用

总体来说，RocketMQ 集群部署模式为四种：

1.单 master 模式

• 也就是只有一个 master 节点，如果master节点挂掉了，会导致整个服务不可用，线上不宜使用，适合个人学习使用。

2.多 master 模式

• 多个 master 节点组成集群，单个 master 节点宕机或者重启对应用没有影响。
• 优点：所有模式中性能最高
• 缺点：单个 master 节点宕机期间，未被消费的消息在节点恢复之前不可用，消息的实时性就受到影响。
• 注意：使用同步刷盘可以保证消息不丢失，同时 Topic 相对应的 queue 应该分布在集群中各个master 节点，而不是只在某各 master 节点上，否则，该节点宕机会对订阅该 topic 的应用造成影响。

3. 多 master 多 slave 异步复制模式

• 在多 master 模式的基础上，每个 master 节点都有至少一个对应的 slave。 master 节点可读可写，但是 slave只能读不能写，类似于 mysql 的主备模式。
• 优点： 在 master 宕机时，消费者可以从 slave 读取消息，消息的实时性不会受影响，性能几乎和多 master 一样。
• 缺点：使用异步复制的同步方式有可能会有消息丢失的问题。

4. 多 master 多 slave 同步双写模式

• 同多 master 多 slave 异步复制模式类似，区别在于 master 和 slave 之间的数据同步方式。
• 优点：同步双写的同步模式能保证数据不丢失。
• 缺点：发送单个消息 RT 会略长，性能相比异步复制低10%左右。刷盘策略：同步刷盘和异步刷盘（指的是节点自身数据是同步还是异步存储）
• 注意：要保证数据可靠，需采用同步刷盘和同步双写的方式，但性能会较其他方式低。

rocketmq master宕机salve不会变成master
采用同步复制，异步刷盘，性能比同步刷盘好点

master配置
brokerRole=SYNC_MASTER

brokerId=0就是master
brokerId>0就是slave