RocketMQ要保证高可用的话，可以使用主从架构，也就是将Broker分为Master Broker和Slave Broker，下面文章中的Master和Slave分别指的是Master Broker和Slave Broker
与其他传统的主从架构一样，Master负责接收数据之后，再将数据同步给Slave，Master和Slave都会向NameServer注册路由信息，同时每隔30秒发送一次心跳。RocketMQ主从架构数据同步采用的是Pull模式，Slave不停的发送请求到Master上去拉取消息
与其他传统的主从架构不一样的是，RocketMQ的主从架构并不是纯粹的读写分离。写的话还是依靠Master，而读的话，既可能是从Master读，也可能是从Slave读，这取决于Master
读消息的时候，第一次是从Master上去读的，之后是去Master还是Slave上读消息，是由Master根据自身的负载情况和Slave的数据同步情况来向消费者建议。如果Master的写负载已经很高的话，那么就会建议消费者下次拉取消息的话就去Slave上拉取；如果Slave数据同步较慢，还没有完全同步Master的消息的话，那么下一次还是会来Master上拉取消息
当Master节点宕机之后，一般来说会对Slave节点进行选举然后选出新的Master继续提供服务。但是在RocketMQ 4.5版本之前，还不支持自动故障切换，需要手工调整才能完成
在RocketMQ 4.5版本之后，引入了Dledger技术，是基于Raft协议实现的（如果不清楚Raft协议可以参考一下这个链接）。DLedger引入之后，可以让一个Master对应多个Slave，也就是存在多个副本，一旦Master宕机了，多个Slave之间就会通过DLedger技术和Raft协议算法进行选举，选出来的Slave节点就作为新的Master继续提供服务。
那么DLedger技术的原理是什么呢？
其实DLedger只做一件事情，就是CommitLog，DLedger可以让我们忽略其他的东西，直接关注CommitLog即可。CommitLog在RocketMQ中就是持久化的消息，所以使用DLedger技术其实就是让DLedger来替代RocketMQ的Broker管理CommitLog，然后Broker还是可以基于DLedger管理的CommitLog去构建出来机器上的各个ConsumerQueue磁盘文件
绕来绕去可能有点晕，来理一下里面的因果关系。首先DLedger技术可以基于Raft协议来进行选主，其次将RocketMQ的CommitLog交给DLedger来管理，那么在Master宕机的时候，DLedger就可以自己进行选举，然后把选举的结果交给RocketMQ的Broker，下次通过NameServer获取路由信息的时候就可以直接找到新的Master，从而完成自动故障切换
讲完了DLedger的基本原理，接下来来看看选举的机制到底是什么样的
DLedger是基于Raft协议来进行选主的，大致流程为：
当Leader宕机，我们假设此时有3个Follower，分别为Broker1、Broker2、Broker3，此时他们都没有接收到其他人的投票，所以此时都会投给自己，这一轮无法选出新的Leader，接下来所有的Follower随机休眠一段时间，比如依次休眠1s、2s、3s，优先苏醒的Broker1还会投票给自己，然后将投票信息发送给其他的节点，此时Broker2苏醒，接收到了Broker1的投票信息，就会尊重他的决定，也给Broker1投票，接着Broker3苏醒之后，也是一样的给Broker1投票，此时Broker1就获得了大多数节点的支持，当有一个节点获得了（N / 2） + 1个，也就是大多数节点的支持之后，就能成功当选
上面的那个步骤，反复几次之后，一定是可以选出新的Leader的
最后来说说DLedger如何基于Raft协议进行多副本同步
DLedger多副本数据同步，Leader Broker收到一条消息，通过DledgerServer组件发送一个uncommited消息给Follow Broker的DledgerServer，Follower接收到消息之后发送一个ack确认消息给Leader，多数Follower都确认之后，Leader再发送一个commited消息到Follower上，Follower将接收到的消息置为commited，此时就完成了数据同步
一张图总结一下