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

引言

大家都知道对于一款消息中间件来说，它是否能够灵活的实现高可用是评价其稳定性能力的一个重要指标。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 提供了一些可以直接读取Com