RocketMQ是什么

RocketMQ 是 MetaQ 的 3.0 版本，而 MetaQ 最初的设计又参考了 Kafka 。MetaQ 1.x 和 MetaQ 2.x 是依赖 ZooKeeper 的，但 RocketMQ （即 MetaQ 3.x ）却去掉了 ZooKeeper 依赖，转而采用自己的 NameServer （专门为Rocket设计的轻量级名称服务）。接下来看一下NameSever在RocketMQ中的作用想必大家就清楚了。

多master多slave部署

下面解读一下它们之间的关系：

1、NameServer互相独立，彼此没有通信关系，单台NameServer挂掉，不影响其他NameServer。NameServer不去连接别的机器，不会主动推消息。

2、单个broker（Master、Slave）与所有NameServer进行定时注册，以便告知NameServer自己还活着。Broker每隔30秒向所有NameServer发送心跳，心跳包含了自身的topic配置信息。NameServer每隔10秒，扫描所有还存活的broker连接，如果某个连接的最后更新时间与当前时间差值超过2分钟，则断开此连接。此外，NameServer也会断开此broker下所有与slave的连接。同时更新topic与队列的对应关系，但不会通知生产者和消费者。

Broker slave 同步或者异步从Broker master 上拷贝数据。

3、consumer随机与一个NameServer建立长连接，如果该NameServer断开，则从NameServer列表中查找下一个进行连接。

consumer主要从NameServer中根据topic查询broker的地址，查到就会缓存到客户端，并向提供topic服务的master、slave建立长连接，且定时向master、slave发送心跳。如果broker宕机，则NameServer会将其剔除，而consumer端的定时任务MQClientInstance.this.updateTopicRouteInfoFromNameServer每30秒执行一次，会将topic对应的broker地址拉取下来，此地址已经为slave地址了，故此时consumer会从slave上消费。 消费者与master和slave都建有连接，在不同场景有不同的消费规则。

4、Producer随机与一个NameServer建立长连接，每隔30秒（此处时间可配置）从NameServer获取topic的最新队列情况，这就表示如果某个broker master宕机，producer最多30秒才能感知，在这个期间，发往该broker master的消息将会失败。Producer会向提供topic服务的master建立长连接，且定时向master发送心跳。生产者与所有的master连接，但不能向slave写入。

客户端是先从NameServer寻址的，得到可用Broker的IP和端口信息，然后自己去连接broker。

（ps：我们在设计系统的时候，有一些全局使用的公用信息，可以单独独立一个模块进行专门的管理；各个子模块只需要定时向该模块更新信息即可。）

综上所述，我们可以得出NameServer在RocketMQ中所扮演的角色：

1.NameServer 用来保存活跃的broker列表，包括Master和Slave 。

2.NameServer 用来保存所有topic和该topic所有队列的列表。

3.NameServer 用来保存所有 broker 的 Filter 列表。

对于RocketMQ 来说，topic 的数据在每个 Master 上是对等的，没有哪个 Master 上有 topic 上的全部数据，所以对于zookeeper的Master 选举功能在Rocket中使用不到。

Broker与slave配对是通过指定相同的brokerName参数来配对，master的brokerId必须为0，slave的brokerId必须大于0，此外一个master下可以挂多个slave，同一个master下的多个slave通过指定不同的brokerId来区分。

原文：https://blog.csdn.net/qq_36569036/article/details/53152759