引言
我们都知道对于一款消息中间件来说，它是否能够方便的实现高可用是评价其稳定性能力的一个重要指标。RocketMQ作为阿里开源的消息中间件，在性能以及高可用等方面都有出色的表现，那么本文主要和大家探讨下RockeqMQ到底是如何实现高可用的。
问题提出
相信大家都知道，在一些常见的中间件设计中如果想要实现数据的高可用性，那么经常采用的办法就是进行数据冗余度存储。当然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 节点会对该日志的存储结果进行仲裁，如果超过集群数量的一半都成功存储了该数据，主节点则向客户端返回写入成功，否则向客户端写入写入失败。
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。
要想实现故障的自动转移，那么在Leader节点挂掉之后，必须可以自动选举新的Leader节点来继续对外提供服务。那么自动重新选择Leader节点是怎么选出来的，实际上是因为Follower节点会有一个定时器，如果定时器时间过了还没收到Leader发送过来的心跳，那么就认为Leader挂了，Follower节点就会转化为Candidate节点，重新开始进行Leader节点，直到新的节点选举出来。
思考题
1、如果在同步的过程中，节点挂掉，会不会出现数据丢失的问题？
2、如果只是网络抖动，实际Leader并没挂掉，但是Follower节点已将开始选举怎么办？
欢迎大家再评论区讨论问题。
