原来RocketMQ高可用设计是这么玩的

怼烎@ 2023-09-28 14:08 7阅读 0赞

## 引言 ##

大家都知道对于一款消息中间件来说，它是否能够灵活的实现高可用是评价其稳定性能力的一个重要指标。RocketMQ作为阿里巴巴开源的消息中间件，在性能以及高可用等方面都有非常出色的表现，那么本文主要和大家探讨下RockeqMQ到底是如何实现高可用的。

## 问题提出 ##

了解过一些中间件设计的同学应该会发现一个秘密，在一些常见的中间件设计中如果想要实现高可用性，无非是通过进行数据冗余存储以及故障自动转移来完成其高可用特性，当然RocketMQ其实不例外的。对于消息中间件来说，消息数据是其非常重要的业务数据，理论上要确保消息数据不能丢的。试想一下在电商微服务架构中，假如出现用户下单后发送订单生产通知到MQ中，但是MQ把这个消息搞丢了，物流服务没有收到这个订单消息无法进行后续的物流操作，那以后用户该敢在这个平台上面买东西吗？因此RocketMQ首先需要保证的就是其消息数据的高可用。

当生产者将数据写入Broker节点之后，还需要进行数据冗余同步操作，也就是将数据同步到其他Broker节点上。这样做的目的就是即便Broke集群存在主节点挂了的情况，但是其他的从Broker节点中还存有消息数据，那么就不至于Broker无法对外提供服务，从而实现Broker的高可用。那么这其中就涉及到几个问题：

1、Broker的集群节点都是对等的吗？还会是存在leader节点以及follower节点？

2、RocketMQ当Broker节点挂掉之后，节点之间到底是如何实现故障转移的？

## DLedger如何实现数据冗余存储？ ##

实际上RocketMQ使用了Dledger的技术来实现高可用的。那这个Dledger到底能干什么呢？首先它实现了conmmitlog的统一管理。由于DLedger 提供了一些可以直接读取CommitLog的API，于是就可以很方便地根据CommitLog去构建ConsumerQueue或者其他的模块，这就是DLedger 在RocketMQ上最直接的应用。

RocketMQ中的Broker节点采用的是leader节点加follow节点的形式， DLedger 集群发起一个写请求，集群中的 Leader 节点来处理写请求，首先数据先存入 Leader 节点，然后需要广播给它的所有从节点，从节点接收到 Leader 节点的数据推送对数据进行存储，然后向主节点汇报存储的结果也就是说从节点会给leader节点回复ack消确认消息，Leader 节点会对该日志的存储结果进行仲裁，如果超过集群数量的一半都成功存储了该数据，主节点则向客户端返回写入成功，否则向客户端写入写入失败。但是有一点需要注意，当消费者从Broker集群中消费消息数据的时候，有可能是从Leader节点获取数据，也有可能是从follow节点获取数据，具体还是要看Leader节点自身的负载情况。

![format_png][]

## Broker如何实现自动故障转移的？ ##

在引入Dledger技术之前，Broker的master节点挂掉之后，需要手工进行Broker节点的重启或者切换，非常的不方便，因此通过引入Dledger技术实现自动的故障转移。要想实现自动的故障转移，必定需要在主节点挂掉之后，可以自动进行主节点的选举以及切换。在RocketMQ中，DLedger 就是一个基于 raft 协议的 commitlog 存储库，实际上也是基于Raft协议实现Broker的Leader节点进行选举的，那么Raft具体的选举流程又是怎样的呢？

首先Dledger把RocketMQ集群中的broker节点分为三个角色，每个角色有着自己独特的职责：

**角色说明**

Leader角色 ：主要负责数据写入，将数据同步到follower节点，保证主从数据一致性，同时使用心跳机制告诉其他节点它是Leader角色；

Follower角色：负责将leader节点发送过来的数据保存到本地，同时需要响应leader节点心跳；

Candidate角色：该角色等待进行leader选举。

当RocketMQ 三个节点刚启动或者leader节点故障挂断的时候，这个时候集群全部节点都是candidate 状态，此时会触发leader选举，选举步骤大致：

1、三个RocketMQ Broker节点启动后，此时它们的角色状态都是Candidate状态，等待进行Leader的选举；

2、此时Broker0率先发起选举，由于Broker0比较自信，它先选举自己为Leader，给自己投了一票，然后通知其他节点；

3、当Broker1以及Broker2接收到选举信息后，由于它们还没开始进行选举，那么既然你Broker0这么自告奋勇，那我们就统一让你来当Leader吧，于是它们都同意让Boker0来当这个Leader节点；

4、当Broker0收到其他两个节点的确认后，计算自己的投票已经超过半数，于是宣布自己当选，将自己的状态修改为Leader，并通知其他节点，其他节点修改自己的状态为Follower节点。

![format_png 1][]

要想实现故障的自动转移，那么在Leader节点挂掉之后，必须可以自动选举新的Leader节点来继续对外提供服务。那么自动重新选择Leader节点是怎么选出来的，实际上是因为Follower节点会有一个定时器，如果定时器时间过了还没收到Leader发送过来的心跳，那么就认为Leader节点挂了，Follower节点就会转化为Candidate节点，重新开始进行Leader节点选举操作，直到新的节点选举出来。当新的Leader节点被选举出来之后，生产者从NameServer获取Broker的路由信息的时候就会拿到新的Leader节点的信息。

![format_png 2][]

![47083685db9b46409e51aed0aef7f3e6.jpeg][]

[format_png]: https://img-blog.csdnimg.cn/img_convert/80e2eb98b5ad578c91dd272b6173d100.webp?x-oss-process=image/format,png
[format_png 1]: https://img-blog.csdnimg.cn/img_convert/38728377c5802747fd877837a4ad9563.webp?x-oss-process=image/format,png
[format_png 2]: https://img-blog.csdnimg.cn/img_convert/b5e2d0b1534194627347b8f07cfbbe2f.webp?x-oss-process=image/format,png
[47083685db9b46409e51aed0aef7f3e6.jpeg]: https://img-blog.csdnimg.cn/47083685db9b46409e51aed0aef7f3e6.jpeg