RocketMQ分布式集群是通过Master和Slave的配合达到高可用性的。
Master和Slave的区别：

1. 在Broker的配置文件中，参数brokerId的值为0表明这个Broker是Master，
2. 大于0表明这个Broker是Slave，
3. brokerRole参数也说明这个Broker是Master还是Slave。
   (SYNC_MASTER/ASYNC_MASTER/SALVE)
4. Master角色的Broker支持读和写，Slave角色的Broker仅支持读。

5. Consumer可以连接Master角色的Broker，也可以连接Slave角色的Broker来读取消息。

   
   
    

消息消费高可用

在Consumer的配置文件中，并不需要设置是从Master读还是从Slave 读，当Master不可用或者繁忙的时候，Consumer会被自动切换到从Slave 读。
有了自动切换Consumer这种机制，当一个Master角色的机器出现故障后，Consumer仍然可以从Slave读取消息，不影响Consumer程序。
这就达到了消费端的高可用性。

消息发送高可用

如何达到发送端的高可用性呢？
在创建Topic的时候，把Topic的多个Message Queue创建在多个Broker组上（相同Broker名称，不同brokerId的机器组成一个Broker组），这样既可以在性能方面具有扩展性，也可以降低主节点故障对整体上带来的影响，而且当一个Broker组的Master不可用后，其他组的Master仍然可用，Producer仍然可以发送消息的。
RocketMQ目前还不支持把Slave自动转成Master，如果机器资源不足，需要把Slave转成Master。

1. 手动停止Slave角色的Broker。
2. 更改配置文件。
3. 用新的配置文件启动Broker。

这种早期方式在大多数场景下都可以很好的工作，但也面临一些问题。
比如，在需要保证消息严格顺序的场景下，由于在主题层面无法保证严格顺序，所以必须指定队列来发送消息，对于任何一个队列，它一定是落在一组特定的主从节点上，如果这个主节点宕机，其他的主节点是无法替代这个主节点的，否则就无法保证严格顺序。
在这种复制模式下，严格顺序和高可用只能选择一个。
RocketMQ 在 2018 年底迎来了一次重大的更新，引入 Dledger，增加了一种全新的复制方式。
RocketMQ 引入 Dledger，使用新的复制方式，可以很好地解决这个问题。
Dledger 在写入消息的时候，要求至少消息复制到半数以上的节点之后，才给客户端返回写入成功，并且它是支持通过选举来动态切换主节点的。
举例:
假如有3个节点，当主节点宕机的时候，2 个从节点会通过投票选出一个新的主节点来继续提供服务，相比主从的复制模式，解决了可用性的问题。
由于消息要至少复制到 2 个节点上才会返回写入成功，即使主节点宕机了，也至少有一个节点上的消息是和主节点一样的。
Dledger在选举时，总会把数据和主节点一样的从节点选为新的主节点，这样就保证了数据的一致性，既不会丢消息，还可以保证严格顺序。
存在问题:
当然，Dledger的复制方式也不是完美的，依然存在一些不足：

1. 比如，选举过程中不能提供服务。
2. 最少需要 3 个节点才能保证数据一致性，3 节点时，只能保证 1 个节点宕机时可用，如果 2个节点同时宕机，即使还有 1 个节点存活也无法提供服务，资源的利用率比较低。
3. 另外，由于至少要复制到半数以上的节点才返回写入成功，性能上也不如主从异步复制的方式快。

RocketMQ底层原理之高可用机制

https://www.jianshu.com/p/89fe3bb6d07f

作者：一个没有感情的程序员
链接：https://www.jianshu.com/p/da4e1f7879c5
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。