RocketMq-高可用机制
高可用机制
RocketMQ分布式集群是通过Master和Slave的配合达到高可用性的。
Master和Slave的区别：
- 在Broker的配置文件中，参数brokerId的值为0表明这个Broker是Master，
- 大于0表明这个Broker是Slave，
- brokerRole参数也说明这个Broker是Master还是Slave。
(SYNC_MASTER/ASYNC_MASTER/SALVE) - Master角色的Broker支持读和写，Slave角色的Broker仅支持读。
- 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。
- 手动停止Slave角色的Broker。
- 更改配置文件。
- 用新的配置文件启动Broker
这种早期方式在大多数场景下都可以很好的工作，但也面临一些问题。
比如，在需要保证消息严格顺序的场景下，由于在主题层面无法保证严格顺序，所以必须指定队列来发送消息，对于任何一个队列，它一定是落在一组特定的主从节点上，如果这个主节点宕机，其他的主节点是无法替代这个主节点的，否则就无法保证严格顺序。
在这种复制模式下，严格顺序和高可用只能选择一个
RocketMQ 在 2018 年底迎来了一次重大的更新，引入 Dledger，增加了一种全新的复制方式。RocketMQ 引入 Dledger，使用新的复制方式，可以很好地解决这个问题。Dledger 在写入消息的时候，要求至少消息复制到半数以上的节点之后，才给客户端返回写入成功，并且它是支持通过选举来动态切换主节点的
举例:
假如有3个节点，当主节点宕机的时候，2 个从节点会通过投票选出一个新的主节点来继续提供服务，相比主从的复制模式，解决了可用性的问题。
由于消息要至少复制到 2 个节点上才会返回写入成功，即使主节点宕机了，也至少有一个节点上的消息是和主节点一样的。
Dledger在选举时，总会把数据和主节点一样的从节点选为新的主节点，这样就保证了数据的一致性，既不会丢消息，还可以保证严格顺序
存在问题:
当然，Dledger的复制方式也不是完美的，依然存在一些不足：
- 比如，选举过程中不能提供服务。
- 最少需要 3 个节点才能保证数据一致性，3 节点时，只能保证 1 个节点宕机时可用，如果 2
个节点同时宕机，即使还有 1 个节点存活也无法提供服务，资源的利用率比较低。 - 另外，由于至少要复制到半数以上的节点才返回写入成功，性能上也不如主从异步复制的方式快。