【RocketMQ入门到精通】— RocketMQ学习入门指南 | RocketMQ服务发现（Name Server）精...

任何先进的技术均与魔法无异

​ ​经历了6个月的失踪，我将带着干货终究归来！【RocketMQ入门到精通】​​

NameServer前提概要

RocketMQ 中，Name Servers被设计用来做简单的路由管理。其职责包括。

• Brokers定期向每个NameServer注册路由数据（topic以及生产者信息\消费者
  \等其他信息）。
• NameServer为客户端，包括生产者，消费者和命令行客户端提供最新的路由信息。

再详细交接NameServer之前，看看RocketMQ发展的几个阶段，看看为啥要有NameServer的存在

RocketMQ的消息模型（第一阶段）

RocketMQ的基础消息模型，一个简单的Pub/Sub模型

基本消息系统模型

      上图就是一个基本的消息系统模型，包括生产者 (Producer)，消费者 (Consumer)，中间进行基于消息主题（Topic）的消息传送。

      基于主题的系统中，消息被发布到Topic或MessageQueue上。消费者将收到其订阅主题上的所有消息，生产者负责定义订阅者所订阅的消息类别。这是一个基础的概念模型，而在实际的应用中，结构会更复杂。例如为了支持高并发和水平扩展，中间的消息主题需要进行分区，同一个Topic会有多个生产者，同一个信息会有多个消费者，消费者之间要进行负载均衡等。

回顾知识点

负责生产消息，一般由业务系统负责生产消息。一个消息生产者会把业务应用系统里产生的消息发送到broker服务器。RocketMQ提供多种发送方式，同步发送、异步发送、顺序发送、单向发送。

负责消费消息，一般是后台系统负责异步消费。一个消息消费者会从Broker服务器拉取消息、并将其提供给应用程序。从用户应用的角度而言提供了两种消费形式：拉取式消费、推动式消费。

表示一类消息的集合，每个主题包含若干条消息，每条消息只能属于一个主题，是RocketMQ进行消息订阅的基本单位。​

RocketMQ的消息模型（第二阶段）

扩展的消息系统模型

      一个扩展后的消息模型，包括两个生产者，两个消息Topic，以及两组消费者 Comsumer。存储消息Topic的 代理服务器( Broker )，是实际部署过程对应的代理服务器。

• 为了消息写入能力的水平扩展，RocketMQ对Topic进行了分区，被称为队列（MessageQueue）。
• 为了消费能力的水平扩展，ConsumerGroup的概念应运而生。
• 相同的ConsumerGroup下的消费者主要有两种负载均衡模式，即广播模式，和集群模式（图中是最常用的集群模式）。
• 在集群模式下，同一个 ConsumerGroup 中的 Consumer 实例是负载均衡消费，如图中 ConsumerGroupA 订阅 TopicA，TopicA 对应 3个队列，则 GroupA 中的 Consumer1 消费的是 MessageQueue 0和 MessageQueue 1的消息，Consumer2是消费的是MessageQueue2的消息。
• 在广播模式下，同一个 ConsumerGroup 中的每个 Consumer 实例都处理全部的队列。需要注意的是，广播模式下因为每个 Consumer 实例都需要处理全部的消息，因此这种模式仅推荐在通知推送、配置同步类小流量场景使用。

RocketMQ的消息模型（第三阶段）

        Producer、Consumer又是如何找到Topic和Broker的地址呢？消息的具体发送和接收又是怎么进行的呢？

生产级别的消息系统模型

生产者Producer

      发布消息的角色。Producer通过 MQ 的负载均衡模块选择相应的 Broker 集群队列进行消息投递，投递的过程支持快速失败和重试。

消费者Consumer

      消息消费的角色。

• 支持以推（push），拉（pull）两种模式对消息进行消费。
• 同时也支持集群方式和广播方式的消费。
• 提供实时消息订阅机制，可以满足大多数用户的需求。

名字服务器 NameServer

NameServer是一个简单的 Topic 路由注册中心，支持 Topic、Broker 的动态注册与发现。

主要包括两个功能：

• Broker管理，NameServer接受Broker集群的注册信息并且保存下来作为路由信息的基本数据。然后提供心跳检测机制，检查Broker是否还存活；
• 路由信息管理，每个NameServer将保存关于 Broker 集群的整个路由信息和用于客户端查询的队列信息。Producer和Consumer通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。

NameServer的多实例部署

  NameServer通常会有多个实例部署，各实例间相互不进行信息通讯。Broker是向每一台NameServer注册自己的路由信息，所以每一个NameServer实例上面都保存一份完整的路由信息。当某个NameServer因某种原因下线了，客户端仍然可以向其它NameServer获取路由信息。

代理服务器 Broker

1. Broker主要负责消息的存储、投递和查询以及服务高可用保证。
2. NameServer几乎无状态节点，因此可集群部署，节点之间无任何信息同步。
3. Broker部署相对复杂。

1. 在 Master-Slave 架构中，Broker 分为 Master 与 Slave。一个Master可以对应多个Slave，但是一个Slave只能对应一个Master。Master 与 Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。

NameServer的通信关系

• 每个Broker 与 NameServer 集群中的所有节点建立长连接，定时注册 Topic 信息到所有 NameServer。
• Producer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取Topic路由信息，并向提供 Topic 服务的 Master 建立长连接，且定时向 Master 发送心跳。Producer 完全无状态。
• Consumer 与 NameServer 集群中的其中一个节点建立长连接，定期从 NameServer 获取 Topic 路由信息，并向提供 Topic 服务的 Master、Slave 建立长连接，且定时向 Master、Slave发送心跳。Consumer 既可以从 Master 订阅消息，也可以从Slave订阅消息。