RocketMQ 高可用架构原理

RocketMQ 高可用架构

高可用架构中主要两块：主从同步和故障转移

一、主从同步的意义

• 1、数据备份，保证多台机器上的数据冗余，特别是在主从同步复制的情况下，一定程度上保证了master出现不可恢复的故障后，数据不丢失。
• 2、高可用性，即master挂掉之后，consumer会自动重连对应的salve机器，不会出现消费停滞的情况。
• 3、提高性能，可以分担master的读压力，当从master拉取消息的最大物理偏移与本地存储的最大物理偏移的差值超过一个值，会转向slave（默认brokerId=1）进行读取，减轻master的压力
• 4、消费实时，master节点挂了之后，依然可以从slave节点读取消息，而且会选择一个副本作为新的master，保证消息正常消费。

二、数据同步

主从怎么关联到一起？

• 1、集群的名字相同，brokerClusterName=hello-cluster。
• 2、连接到相同的NameServer。
• 3、在配置文件中：brokerId = 0代表是master，brokerId = 1代表是slave。

2.1、主从同步

• ASYNC_MASTER主从异步复制，master写成功，返回客户端成功。拥有较低的延迟和较高的吞吐量，但是master故障之后，有可能数据丢失
• SYNC_MASTER 主从同步双写（推荐），master和slave都写成功，才会返回客户端成功，master故障之后不会数据丢失，但是会增加数据的写入延迟，降低吞吐量。

2.2、flushDiskType （刷盘类型）

• ASYNC_FLUSH 异步刷盘（默认），生产者发送消息并不是立即保存到磁盘，而是暂时缓存起来然后就返回生产者成功。随后再异步的将缓存数据保存到磁盘，1、定期将缓存中更新的数据进行刷盘，2、缓存中更新的数据条数达到设定值后进行刷盘。这种方式会存在消息的丢失，但是性能很好，默认这种模式。
• SYNC_FLUSH 同步刷盘，生产者发送的每一条消息都保存到磁盘成功后才返回生产者成功，这种方式不会存在消息的丢失问题，但是有很大的磁盘IO开销，性能有一定影响。
  

通常会把master和slave 配置成异步刷盘，主从之间同步复制，即同步复制+异步刷盘

2.3、主从同步流程

• 1、slave连接到master，然后每隔 5s 向主服务器发送 commitLog 文件最大偏移量，拉取还未同步的消息；
• 2、master收到slave服务器发过来的偏移量进行解析，并返回查找出未同步的消息发送给slave；
• 3、slave收到master的消息后，将这批消息写入 commitLog 文件中，然后更新 commitLog 拉取偏移量，接着继续向master拉取未同步的消息。

三、故障转移

之前的RocketMQ版本，只要master/slave 一种部署方式，一组的broker中有一个master多个slave，slave通过同步复制/异步复制方式去同步master的数据，master/slave 提供了一定的高可用。

但是这样的模式有一定的缺点，比如故障转移，如果master挂了，还需要人为手动进行切换，无法自动slave转换为master。

如果要实现自动故障转移，根本上要解决的问题就是自动选主的问题。

RocketMQ目前是利用Dledger技术解决自动选主的问题，Dledger就是基于raft协议，它的优点是不需要引入外部组件，自动选主逻辑集成到各个节点进程中，节点之间通信就可以完成选主。

这种情况下，commit log 是 Dledger管理的，具有选主功能。

Dledger配置

开启Dledger功能，默认是false，如果需要开始主从切换，则需要配置相关参数：

# 是否启用DLedger enableDLegerCommitLog=true

# DLedger Raft Group的名字 
dLegerGroup=broker-a

# DLedger Group内各节点的地址和端口，至少需要3个节点 
dLegerPeers=n0-192.168.44.163:10911;n1-192.168.44.164:10911;n2- 192.168.44.165:10911

# 本节点ID 
dLegerSelfId=n0

四：RocketMQ特性

1、单机可以支撑上万个队列的管理
2、上亿级的消息堆积能力，在海量的消息情况下，不影响收发性能
3、具有多副本容错机制，消息可靠性高，数据安全
4、快速横向扩容
5、保证消息的有序性
6、支持push和pull 两种模式
7、支持广播和集群消费
8、低延迟：客户端消息低延迟控制在10ms以内