RocketMQ笔记-高可用

RocketMQ 主从同步(HA)机制

高可用(HA 机制)特性是目前分布式系统中必备的特性之一，对一个中间件来说没有HA机制必然是一个重大的缺陷。RocketMQ的Broker 分为 Master (主)和 Slave(从) 两个角色，为了保证高可用性，Master 角色的机器接收到消息后 ，要把内容同步到 Slave 机器上，这样一旦 Master 宕机，Slave 机器依然可以提供服务。这个就是 RocketMQ 实现高可用(HA 机制)的原理。

为了提高消息消费的高可用性，避免 Broker 发生单点故障引起存储在 Broker 上的消息无法及时消费， RocketMQ 引入了 Broker 主从机制:即消息消费到达主服务器(Master)后需要消息同步到消息从服务器(Slave)，如果主服务器 Broker 宕机后，消息消费者可以从从服务器拉取消息。

同时 RocketMQ 依赖 NameServer, 所以为了确保高可用，同时要确保 NameServer 的高可用，一般通过部署多台NamesServer 服务器来实现，但彼此之间互不通信，也就是 NameServer 务器之间在某一时刻的数据并不会完全相同，但这对消息发送不会造成任何影响，这也是 RocketMQ NameServer 设 计的一个亮点。

RocketMQ 集群部署模式

集群部署模式

单master模式

也就是只有一个 master 节点，称不上是集群，一旦这个 master 节点宕机，那么整个服务就不可用。

多 master 模式

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

多 master 多 slave 异步复制模式

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

多 master 多 slave 同步双写模式

同多 master 多 slave 异步复制模式类似，区别在于 master 和 slave 之间的数据同步方式。
优点:同步双写的同步模式能保证数据不丢失。
缺点:发送单个消息响应时间会略长，性能相比异步复制低 10%左右。
同步方式:同步双写和异步复制(指的一组 master 和 slave 之间数据的同步)
刷盘策略:同步刷盘和异步刷盘(指的是节点自身数据是同步还是异步存储进入磁盘)
注意:对数据要求较高的场景，建议的持久化策略是主 broker 和从 broker 采用同步复制方式，主从 broker 都采用异步刷盘方式。通过同步复制方式， 保存数据热备份，通过异步刷盘方式，保证 rocketMQ 高吞吐量。

主从复制原理

RocketMQ 主从同步(HA)实现过程如下:

1. 主服务器启动，并在特定端口上监听从服务器的连接。
2. 从服务器主动连接主服务器，主服务器接受客户端的连接，并建立相关 TCP 连接。
3. 从服务器主动向服务器发送待拉取消息偏移 ，主服务器解析请求并返回消息给从服务器。
4. 从服务器保存消息并继续发送新的消息同步请求。

从服务器在启动的时候主动向主服务器建立 TCP 长连接，然后获取服务器的 commitlog 最大偏移，以此偏移向主服务器主动拉取消息，主服务器根据偏移量，与自身 commitlog 文件的最大偏移进行比较，如果大于从服务器 commitlog 偏移 ，主服务器将向从服务器返回一定数量的消息， 该过程循环进行 ，达到主从服务器数据同步。

读写分离机制

RocketMQ 读写分离与他中间件的实现方式完全不同， RocketMQ 是消费者首先服务器发起拉取消息请求，然后主服务器返回一批消息，然后会根据主服务器负载压力与主从同步情况，向从服务器建议下次消息拉取是从主服务器还是从从服务器拉取。

那消息服务端是根据何种规则来建议哪个消息消费队列该从哪台 Broker 服务器上拉取消息呢?
一般都是从主服务器拉取，如果主阶段拉取的消息已经超出了常驻内存的大小，表示主服务器繁忙，此时从从服务器拉取。
如果主服务器繁忙则建议下次从从服务器拉取消息，设置 suggestWhichBrokerld 配置文件中 whichBrokerWhenConsumeSlowly 属性，默认为 1。如果一个 Master 拥有多台 Slave 服务器，参与消息拉取负载的从服务器只会是其中一个。