前言：
在rockemq4.5之前，rocketmq集群架构都是master-slave主从架构部署，如下图，master节点负责写入消息，slave节点负责同步master节点消息。假设master-1节点有个topic-A，此时如果master节点宕机无法恢复，此时我们是无法写入topic-A消息的，这个时候rocketmq对于我们producer服务来说来说是不可用的，只有手动让slave-1节点升级生master节点，服务才可用。
试想一下，正好我们这个时候在做限时促销活动，很多用户参与，rocketmq服务突然不可用，手动恢复集群花费的时间有很长，那损失得多大。
那么有没有一种办法可以让slave-1自动升级为master对外提供服务呢？当然有，那就是rocketmq4.5版本提供的dledger集群模式，接下来我们就会介绍一下rocketmq dledger 集群模式。
Rocketmq dledger 集群
dledger 使用的是raft协议，如果你之前了解过raft协议，那就很容易理解dledger的集群架构原理。我们都知道raft协议有leader选举， leader-follower 节点数据同步两个功能，他能保证数据在多个节点的最终一致性。我们还是先直接介绍一下rocketmq dledger集群架构吧，如下图：
1. 一个broker集群至少三个节点，一个leader节点，2个follower节点。
2.leader节点负责负责写入消息，当消息写入leader节点之后，leader会将消息同步到follower节点，当集群过半数节点都写入了消息，则提交这个消息。这种类似2pc的方式保证了主从最终一致性。
3.如果leader节点挂了，follower会在倒计时结束，触发leader选举，重新选举一个新的leader节点负责写入数据。
4.broker集群的每个节点也都会向namesrv所有的节点进行注册，这点和master-slave架构没有任何区别。
在这里大家会有一个疑问，dledger是如何进行leader选举的，leader节点数据又如何同步到follower节点的呢？其实dledger是使用分布式一致性协议raft实现了leader选举和保证主从数据一致性，因此要介绍dledger原理，还是要从raft协议说起。
leader broker节点的选举
dledger使用的是raft协议，它把mq集群中的broker节点分为三个角色：
leader节点 ：负责写入数据，将数据同步到follower节点，保证主从数据一致性，同时使用心跳机制维护自己领导者地位；
follower节点：负责接受leader节点数据并保存到本地；响应leader节点心跳；
candidate节点：负责leader选举。
当broker三个节点都启动的时候，这个时候 他们全都是candidate 状态，此时会触发leader选举，一般第一个先发起leader选举的会当选成leader选举，选举步骤入下：
1.selfid-0，1，2三个节点刚启动都是candidate状态；
2.假设selfid-0 节点首先发起选举，它会向selfid-1，2节点发起选举请求，选举自己当leader；发起选举请求之前selftid-0会先投自己一票；
3.由于selfid-1，2节点还没有发起选举请求，他会同意selfid-0选举请求，并给selfid-0节点一个确认回复；
4.selfid-0节点收到过半数节点的同意答复，则当选为leader。
leader节点如何使用心跳维护领导者地位
selfid-0节点当选为leader之后，首选要维护自己的leader者地位。他要告诉集群其他节点，我是集群中的leader，你们要成为我的follower，负责同步我发给你们的数据；并且保证只要我还活着，你们就不要妄想重新进行选举。具体步骤如下：
1.每个几秒钟leader节点会向所有follower节点发送心跳请求；
2.follower收到心跳请求之后，更新本地倒计时时间，同时给leader节点一个确认回复；
3.leader节点收到过半数follower节点的回复，则说明自己还是leader。
如果没收到过半数follower节点回复，则会变更为candidate状态，重新触发选举；同样的，如果follower节点没收到
leader节点的心跳请求，follower节点也会变更为candidate状态，触发leader选举。
故障恢复
了解了dledger的心跳原理之后，就很容易明白故障恢复机制。看上面这张图，假设此时leader节点故障挂掉，
follower节点收不到leader节点的心跳请求，那么follower节点就会触发leader选举，选举自己为leader节点，这样Rokcetmq 集群又可以正常提供服务了。