RocketMQ保证高可用性

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高可用思路

在实际生产环境中，一般需要服务达到高可用、无单节点故障的要求。在 rocketMq 中
就需要分布式部署。
RocketMQ的核心就是Broker的消息存储，而高可用的关键也在于Broker。因此，高可用方案可以参考一下推荐
NameServer：因为NameServer是无状态的，所以只需要直接用集群 部署，只要由一台NameServer可用，那么集群就整体可用。
Broker：实际存储消息的服务，服务不可用可能导致消息丢失推荐使用两主两从以上的集群配置此外Broker的主从配置有同步双写和异步双写，同步双写保证消息不会丢失，异步复制性能高，但是如果发现断电等瞬时故障导致主从同时宕机可能会丢失几条消息。正常情况异步复制一台机器发生故障不会丢失数据。

集群模式推荐配置

nameServer

无状态节点，直接部署多个实例即可

Broker

推荐使用双主双从，异步复制。对应配置文件：conf/2m-2s-async/目录下。如果偏向性能，则使用异步刷盘（数据落盘模式），异步复制（主从同步模式）。如果偏向消息高可靠，不在乎性能，则使用同步刷盘，同步双写。如果需求居中，则推荐异步刷盘，同步双写。以下是配置文件相关配置：
同步刷盘/异步刷盘：flushDiskType=SYNC_FLUSH / ASYNC_FLUSH
同步双写/异步复制：brokerRole=SYNC_MASTER/ASYNC_MASTER(注：如果是从节点这个字段则统一都是写SLAVE，主从复制策略只在主节点配置就可以)
名词解释：同步刷盘/异步刷盘：指的是消息被写入内存的pagecache再存到磁盘的过程是同步还是异步
同步双写/异步复制：指的是消息在Broker主节点到从节点之间复制的过程是同步还是异步

主从模式下的故障情况与模拟结果

测试项目/消息场景	发送消息	发送消息过程中	接收消费消息
停用一个namesrv	不影响通信	不影响通信	不影响通信
停用全部namesrv	影响通信	不影响通信	影响通信，启动任意的namesrv可恢复
停用单个master broker	不影响通信	不影响通信	不影响通信
停用全部master broker	影响通信	影响通信，无法恢复	不影响通信
停用一个slave broker	不影响通信	不影响通信	不影响通信
停用全部slave broker	不影响通信	影响通信，数秒恢复	不影响通信，数秒恢复

RocketMQ底层原理之高可用机制

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

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

作者：david161
链接：https://www.jianshu.com/p/f2b72f1504d6
来源：简书
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。