RocketMQ（二）RocketMQ技术架构设计分析及部署架构讲解

上节文《RocketMQ（一）基础概念理解及消息消费模式解析》讲解了RocketMQ基础的一些概念和消息消费模式，这篇文章主要介绍RocketMQ的技术架构设计以及部署架构概念的讲解

架构设计

RocketMQ的主要架构图示：

技术架构

RocketMQ架构上主要分为四部分，如上图所示:

Producer：

发布（生产）消息的角色，支持分布式集群方式部署。Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。
Consumer：

消费消息的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制，可以满足大多数用户的需求。
NameServer：

NameServer是一个非常简单的Topic路由注册中心，其角色作用类似Dubbo中的Zookeeper，支持Broker的动态注册与发现。主要负责两个功能：
- Broker管理：NameServer接受Broker集群的注册信息并且保存下来作为消息路由信息的基本数据。然后提供心跳检测机制，检查Broker的健康/存活状态。
- 消息路由管理：每个NameServer将保存关于Broker集群的整个路由信息以及用于客户端查询的队列信息。然后Producer和Consumer通过NameServer就可以知道整个Broker的集群的路由信息，从而进行消息的投递和消费。NameServer通常也使用集群的方式部署，各个NameServer实例之间不进行信息的通讯和交换。Broker会向NameServer集群内的每个实例注册自己的路由信息，所以每个NameServer实例上面都保存有一份完整的路由信息。当某一台NameServer实例因为某种原因下线了，Broker仍然可以向其他NameServer实例同步其路由信息，Producer,Consumer仍然可以动态感知Broker的路由的信息。
BrokerServer：

Broker主要负责消息的存储、投递和查询以及保证服务的高可用，为了实现这些功能，Broker还包括了一下几个重要子模块：
1. Remoting Module
  
  Broker的请求统一入口，作为整个Broker的实体，负责处理来自Clients端的各种请求。
2. Client Manager
  
  客户端管理器，负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息。
3. Store Service
  
  数据存储服务，提供方便简单的API接口处理消息存储到物理硬盘以及消息查询功能
4. HA Service
  
  高可用支撑服务，提供Broker集群内Master Broker 和 Slave Broker之间的数据同步功能
5. Index Service
  
  索引支撑服务，根据特定的Message key对投递到Broker的消息进行索引相关服务，以提供消息的快速查询

部署架构

RocketMQ（二）RocketMQ技术架构设计分析及部署架构讲解

在部署Rocket我们主要要注意以下几点：

NameServer ：NameServer是一个几乎无状态节点，可集群部署，节点之间无任何信息同步。我们最后在项目中（Producer或Consumer）使用的一般也都是连接NameServer服务进行消息的生产和消费。
Broker：Broker的部署相对复杂，Broker分为Master与Slave，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。

注意：当前RocketMQ版本在部署架构上支持一Master多Slave，但只有BrokerId=1的从服务器才会参与消息的读负载。
Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer获取Topic路由信息，并向提供Topic 服务的Master建立长连接，且定时向Master发送心跳。Producer对于RocketMQ来说完全无状态，可集群部署。
Consumer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer获取Topic路由信息，并向提供Topic服务的Master Broker和Slave Broker建立长连接，且定时向Master Broker、Slave Broker发送心跳。

Consumer既可以从Master Broker订阅消息，也可以从Slave Broker订阅消息，消费者在向Master Broker拉取消息时，Master Broker服务器会根据拉取偏移量与最大偏移量的距离（判断是否读老消息，产生读I/O），以及从服务器是否可读等因素建议下一次是从Master还是Slave拉取。

RocketMQ集群工作流程

启动NameServer，NameServer起来后监听端口，等待Broker、Producer、Consumer连上来，相当于一个路由控制中心。
Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系。
收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以配置Broker在收到发送的消息时自动创建Topic。
Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息。
Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息。

总结

上面讲了很多概念性的东西，什么NameServer、主从Broker、Producer、Consumer之类的。其实这些服务里面只有NameServer、主从Broker是RocketMQ核心的服务，提供了一个完整的高可用高性能的分布式消息队列需要的所有功能以及特性API。而Producer（生产者）和Consumer（生产者）其实就是我们自己开发编码的需要使用消息队列服务的应用服务，而这些应用怎么部署怎么开发对RocketMQ提供的服务以及API来说都是没有任何影响的。