broker

RocketMQ（2）（BrokerNameServer）

1：RocketMQ的架构图

RocketMQ技术架构中有四⼤⾓⾊NameServer、Broker、Producer、Consumer

Broker：主要负责消息的存储、投递和查询以及服务⾼可⽤保证。

说⽩了就是消息队列服务器嘛，⽣产者⽣产消息到Broker，消费者从Broker拉取消息并消费。

⼀个Topic可以分布在多个Broker上，⼀个Broker可以配置多个Topic，它们是多对多的关系。

如果某个Topic消息量很⼤，应该给它多配置⼏个队列(提⾼并发能⼒)，

并且尽量多分布在不同Broker上，以减轻某个Broker的压⼒。

NameServer：

类似于ZooKeeper和SpringCloud中的Eureka，它其实也是⼀个注册中⼼，

主要提供两个功能：Broker管理和路由信息管理。

Broker：

将⾃⼰的信息注册到NameServer中，此时NameServer就存放了很多Broker的信息(Broker的路由表)，

消费者和⽣产者就从NameServer中获取路由表然后照着路由表的信息和对应的Broker进⾏通信

(⽣产者和消费者定期会向NameServer去查询相关的Broker的信息)。

Producer：

消息发布的⾓⾊，⽀持分布式集群⽅式部署。说⽩了就是⽣产者。

Consumer：

消息消费的⾓⾊，⽀持分布式集群⽅式部署。

⽀持以push推，pull拉两种模式对消息进⾏消费。

同时也⽀持集群⽅式和⼴播⽅式的消费，它提供实时消息订阅机制。

2：NameServer的负载均衡？

NameServer是否是多余的：

直接Producer、Consumer和Broker直接进⾏⽣产消息消费消息不也可以的吗？

Broker是需要保证⾼可⽤的，所以我们需要使⽤多个Broker来保证负载均衡。

我们的消费者和⽣产者直接和多个Broker相连，

那么当Broker修改的时候必定会牵连着每个⽣产者和消费者，这样就会产⽣耦合问题，

因此NameServer也就变为了必须：

第⼀：Broker做了集群并且还进⾏了主从部署

由于消息分布在各个Broker上，⼀旦某个Broker宕机，则该Broker上的消息读写都会受到影响。

所以Rocketmq提供了master/slave的结构，salve定时从master同步数据(同步刷盘或者异步刷盘)，

如果master宕机，则slave提供消费服务，但是不能写⼊消息(后⾯还会提到哦)。

第⼆：NameServer做了集群并且去中⼼化

为了保证HA，NameServer做了集群并且去中⼼化，也就意味着它没有主节点；

你可以很明显地看出NameServer的所有节点是没有进⾏InfoReplicate的，

在RocketMQ中是通过单个Broker和所有NameServer保持长连接，并且在每隔30秒Broker会向所

有Namerver发送⼼跳，⼼跳包含了⾃⾝的Topic配置信息，这个步骤就对应这上⾯的RoutingInfo。

第三：⽣产者需要向Broker发送消息

先从NameServer获取关于Broker的路由信息，然后通过轮询的⽅法去向每个队列中⽣产数据以达到负载均衡的效果。

第四：消费者需要从Broker消费消息

消费者通过NameServer获取所有Broker的路由信息后，向Broker发送Pull请求来获取消息数据。

Consumer可以以两种模式启动——⼴播（Broadcast）和集群（Cluster）。

⼴播模式下，⼀条消息会发送给同⼀个消费组中的所有消费者，集群模式下消息只会发送给⼀个消费者。