如果要让Broker实现高可用，那么必须有一个Broker组，里面有一个是Leader Broker可以写入数据，然后让Leader Broker接收到数据之后，直接把数据同步给其他的Follower Broker。这样的话，一条数据就会在多个Broker上有多份副本，此时如果Leader Broker宕机，那么就直接让其他的Follower Broker自动切换为新的Leader Broker，继续接受客户端的数据写入就可以了。

    1. 基于DLedger技术替换Broker的CommitLog
      Broker高可用架构就是基于DLedger技术来实现的。
      DLedger技术实际上首先他自己就有一个CommitLog机制，你把数据交给他，他会写入CommitLog磁盘文件里去。
      我们需要使用DLedger来管理CommitLog，然后Broker还是可以基于DLedger管理的CommitLog去构建出来机器上的各个ConsumeQueue磁盘文件。

    2. DLedger是如何基于Raft协议选举Leader Broker的？
      DLedger是基于Raft协议来进行Leader Broker选举的。
      这需要发起一轮一轮的投票，通过多台机器互相投票选出来一个人作为Leader。
      此时在第一轮选举中，Broker会收到别人的投票，他发现自己是投票给自己，但是其他Broker投票给Broker自己，似乎每个人都很自私，都在投票给自己，所以第一轮选举是失败的。
      接着每个人会进入一个随机时间的休眠，比如说Broker01休眠3秒，Broker02休眠5秒，Broker03休眠4秒。
      此时Broker01必然是先苏醒过来的，他苏醒过来之后，直接会继续尝试投票给自己，并且发送自己的选票给别人。接着Broker03休眠4秒后苏醒过来，他发现Broker01已经发送来了一个选票是投给Broker01自己的，此时他自己因为没投票，所以会尊重别人的选择，就直接把票投给Broker01了，同时把自己的投票发送给别人。接着Broker02苏醒了，他收到了Broker01投票给Broker01自己，收到了Broker03也投票给了Broker01，那么他此时自己是没投票的，直接就会尊重别人的选择，直接就投票给Broker01，并且把自己的投票发送给别人。此时所有人都会收到三张投票，都是投给Broker01的，那么Broker01就会当选为Leader。
      简单来说，他确保有人可以成为Leader的核心机制就是一轮选举不出来Leader的话，就让大家随机休眠一下，先苏醒过来的人会投票给自己，其他人苏醒过后发现自己收到选票了，就会直接投票给那个人。
      依靠这个随机休眠的机制，基本上几轮投票过后，一般都是可以快速选举出来一个Leader。

    3. DLedger是如何基于Raft协议进行多副本同步的？
      DLedger在进行同步的时候是采用Raft协议进行多副本同步的。简单来说，数据同步会分为两个阶段，一个是uncommitted阶段，一个是commited阶段。
      首先Leader Broker上的DLedger收到一条数据之后，会标记为uncommitted状态，然后他会通过自己的DLedgerServer组件把这个uncommitted数据发送给Follower Broker的DLedgerServer。
      接着Follower Broker的DLedgerServer收到uncommitted消息之后，必须返回一个ack给Leader Broker的DLedgerServer，然后如果Leader Broker收到超过半数的Follower Broker返回ack之后，就会将消息标记为committed状态。
      然后Leader Broker上的DLedgerServer就会发送commited消息给Follower Broker机器的DLedgerServer，让他们也把消息标记为comitted状态。
      这个就是基于Raft协议实现的两阶段完成的数据同步机制。

    4. 如果Leader Broker崩溃了怎么办？
      对于高可用Broker架构而言，无论是CommitLog写入，还是多副本同步，都是基于DLedger来实现的。
      如果Leader Broker挂了，此时剩下的Follower Broker就会重新发起选举，他们会基于DLedger还是采用Raft协议的算法，去选举出来一个新的Leader Broker继续对外提供服务，而且会对没有完成的数据同步进行一些恢复性的操作，保证数据不会丢失。