【RocketMQ】原理分析：Broker集群模式、队列分区

1.Broker集群模式（宏观）

RocketMQ天生对集群的支持非常友好，天然支持高可用，它可以支持多主多从的部署架构，这也是和kafka大区别之一（PS：Kafka的分区副本可以看成一主多从）。

那为什么要将这么多broker组织成多主多从，而不是采用一主多从然后主节点down机后再选举啊？因为。。。RocketMQ中并没有master选举功能，在RocketMQ集群中，1台机器只能要么是Master，要么是Slave，这个在初始的机器配置里面，就定死了。不会像kafka那样存在master动态选举的功能，所以通过配置多个master节点来保证rocketMQ的高可用。

其中Master的broker id = 0，Slave 的broker id > 0。有点类似于mysql的主从概念，master挂了以后，slave仍然可以提供读服务，但是由于有多主的存在，当一个master挂了以后，可以写到其他的master上。

和所有的集群角色定位一样，master节点负责接受事务请求、slave节点只负责接收读请求，并且接收master同步过来的数据和slave保持一致。

既然说到集群模式了，那我们再来看看常见的四种集群模式：
单Master
- 优点：除了配置简单没什么优点
- 缺点：不可靠，该机器重启或宕机，将导致整个服务不可用
多Master
- 优点：配置简单，性能高
- 缺点：可能会有少量消息丢失（配置相关），单台机器重启或宕机期间，该机器下未被消费的消息在机器恢复前不可订阅，影响消息实时性
多Master多Slave，每个Master配一个Slave，有多对Master-Slave，集群采用异步复制方式，主备有短暂消息延迟，毫秒级
- 优点：性能同多Master几乎一样，实时性高，主备间切换对应用透明，不需人工干预
- 缺点：Master宕机或磁盘损坏时会有少量消息丢失
多Master多Slave，每个Master配一个Slave，有多对Master-Slave，集群采用同步双写方式，主备都写成功，向应用返回成功
- 优点：服务可用性与数据可用性非常高
- 缺点：性能比异步集群略低，当前版本主宕备不能自动切换为主

而RocketMQ采用的就是的第三种。在多主多从架构下，由于每个master可以配置多个slave，所以如果其中一个master挂了，那么只是当前Broker不能写消息了，但Consumer仍然可以从slave节点消费到。可以完美的实现rocketmq消息的高可用。

如果当前rocketmq是一主多从，就意味着无法接受发送端的消息，但是消费者仍然能够继续消费。
如果当前rocketmq是多主多从，另外一个master节点仍然能够对外提供消息发送服务。

这里特别注意一点，当存在多个主节点时，一条消息只会发送到其中一个主节点。rocketmq对于多个master节点的消息发送，会做负载均衡，使得消息可以平衡的发送到多个master节点上。一个消费者可以同时消费多个master节点上的消息，在上面这个架构图中，两个master节点恰好可以平均分发到两个消费者上，如果此时只有一个消费者，那么这个消费者会消费两个master节点的数据。

2.Broker队列分区（微观）

在RocketMQ中，是基于多个Message Queue来实现类似于kafka的分区效果。如果一个Topic 要发送和接收的数据量非常大，需要能支持增加并行处理的机器来提高处理速度，这时候一个Topic 可以根据需求设置一个或多个Message Queue。

Topic 有了多个Message Queue 后，消息可以并行地向各个 Message Queue 发送，消费者也可以并行地从多个Message Queue 读取消息并消费。从而提高消费者并发处理的能力与消费者拉取消息时的负载均衡

注：RocketMQ是通过多Master实现了对Producer发送消息的负载均衡，而不是kafka那样通过分区分片存储实现Producer发消息负载均衡

我们可以直接在控制台创建队列（分区）：

图中那两个参数是什么意思呢？
writeQueueNums：写队列数，表示producer发送到的MessageQueue的队列个数
readQueueNums：读队列数，表示Consumer读取消息的MessageQueue队列个数
注：这两个值需要相等，在集群模式下如果不相等，writeQueueNums=6,readQueueNums=3, 那么每个broker上会有3个queue的消息是无法消费的。

上面创建一个TestTopic的主题，这个主题下有两个队列，即两个分区。