RocketMQ集群流程以及核心概念

一、为什么要集群

• 单点存在单点故障问题
• 集群可以分担压力，提高QPS
• 主从可以保证消息可靠性，比如只有M没S。M磁盘坏了，那未被消费的消息都丢了。而S可以作为备份。

二、单M模式

1、特点

• 只有一个Master节点，所以单点故障是致命缺点。
• 优点：配置简单，方便部署。
• 缺点：单点故障，一旦Broker重启或者直接宕机了，那会导致整个服务不可用。

2、图解

三、多M模式

1、特点

• 一个集群无Slave节点，全是Master节点。
• 优点：配置相对不复杂，单个M宕机或者重启对业务系统无感知，照常提供服务。只是这个broker上如果有消息未被消费的话可能无法继续消费，但是消息不会丢失，持久化到磁盘的。异步刷盘的话会存在少量丢失。
• 缺点：单台机器宕机期间，这台机器上未被消费的消息在机器恢复之前不可订阅，消息实时性会受到受到影响。

2、图解

四、多M多S模式

一个集群既有Master节点又有Slave节点。

1、异步复制

• 每个 Master 配置一个 Slave，有多对Master-Slave， HA，采用异步/同步复制方式，主备有短暂消息延迟，毫秒级。
• 优点：即使磁盘损坏，消息丢失的非常少，且消息实时性不会受影响，因为Master 宕机后，消费者仍然可以从 Slave消费，此过程对应用透明。不需要人工干预。性能同多 Master 模式几乎一样。
• 缺点： Master 宕机，磁盘损坏情况，会丢失少量消息。

2、同步双写

• 每个 Master 配置一个 Slave，有多对Master-Slave， HA采用同步双写方式，主备都写成功，向应用返回成功。

• 优点：数据与服务都无单点， Master宕机情况下，消息无延迟，服务可用性与数据可用性都非常高。

• 缺点：性能比异步复制模式略低，大约低 10%左右，发送单个消息的 RT会略高。目前主宕机后，备机不能自动切换为主机，后续会支持自动切换功能。

• 要想真正意义的保证消息不丢失，这个同步双写是必须的 。

3、图解

五、queue的分布

一个topic的queue可以分布到多个Broker上。比如一个topic有4个queue，他可能分配到broker-a上三个queue，broker-b上1个queue，这个queue的分配是由broker端决定的。但是为了验证猜想我们可以手动从管控台去创建这个topic，成功的话可以验证我们的猜想。

首先我有2M2S的一个集群

创建topic

创建topic

查看status，可以发现为我们在每个broker上都创建了4个queue，也就是一共8个queue了。

点击【TOPIC CONFIG】更改配置

再次查看就会发现已经生效了，验证了我们的猜想

每个queue的消息都是不一样的，也就是比如你发N条消息，他可能一部分在broker-a上一部分在broker-b上，不管他在哪，消息都是不一样的，不要理解成M-S那种复制。他只是负载均衡将queue分配到了不同的broker上。