1-RocketMQ架构

先来看看官方的一张非常模糊的图片：

一、NameServer

NameServer 是一个功能齐全的服务器，提供轻量级服务发现和路由。每个 Name Server 记录完整的路由信息​​，提供相应的读写服务，并支持快速存储扩展。主要包括两个功能：
1、Broker 管理，NameServer接受来自 Broker 集群的注册，并提供心跳机制来检查 Broker 是否处于活动状态。
2、路由管理，每个 NameServer 将保存有关代理集群的完整路由信息和客户端查询的队列信息。

RocketMQ 客户端（生产者/消费者）会从 NameServer 查询队列路由信息，但是客户端如何找到 NameServer 地址呢？有四种方法可以将 NameServer 地址列表提供给客户端：
1、程序化方式，如producer.setNamesrvAddr("ip:port").
2、Java 选项，使用rocketmq.namesrv.addr.
3、环境变量，使用NAMESRV_ADDR.
4、HTTP 端点。

二、Broker Server

Broker Server 负责消息存储和传递、消息查询、HA 保证等。
Brokers 通过提供轻量级的 TOPIC 和 QUEUE 机制来处理消息存储。它们支持Push和Pull模型，包含容错机制（2副本或3副本），并提供强大的峰值填充和按原始时间顺序累积数千亿条消息的能力。此外，Brokers 提供灾难恢复、丰富的指标统计和警报机制，这些都是传统消息传递系统所缺乏的。
如下图所示，Broker 服务器有几个重要的子模块：
1、远程模块，代理的入口，处理来自客户端的请求。
2、客户端管理器，管理客户端（生产者/消费者）并维护消费者的主题订阅。
3、存储服务，提供简单的 API 来存储或查询物理磁盘中的消息。
4、HA Service，提供主代理和从代理之间的数据同步功能。
5、索引服务，通过指定的key为消息建立索引，并提供快速的消息查询。 

三、Producer Cluster

生产者支持分布式部署。分布式生产者通过多种负载均衡方式向 Broker 集群发送消息。发送进程支持快速失败并具有低延迟。

四、Consumer Cluster

消费者也支持推拉模型中的分布式部署。它还支持集群消费和消息广播。提供实时消息订阅机制，可以满足大部分消费者的需求。RocketMQ 的网站为感兴趣的用户提供了一个简单的快速入门指南。

五、部署

1、Name Server部署
为确保在一个实例崩溃时集群仍能正常运行，建议使用两个或多个名称服务器实例。只要有一个名称服务器实例活着，整个集群就会保持服务。名称服务器遵循无共享设计范例。Broker将心跳数据发送到所有名称服务器。生产者和消费者可以在发送/消费消息时从任何可用的名称服务器查询元数据。
2、Broker 部署
Broker 可以根据其角色分为两类：master 和 slave。master 提供 RW 访问，而 slave 只接受读访问。要部署无单点故障的高可用 RocketMQ 集群，需要部署一系列Broker集群。Broker集群包含一个 brokerId 设置为 0 的 master 和几个具有非零 brokerID 的 slave。一组中的所有Broker都具有相同的 brokerName。在最差的情况下，我们应该在一个Broker集群中至少有两个Broker。每个主题驻留在两个或多个Broker中。
推荐Broker配置如下：

Property Name	Default value	Details
listenPort	10911	listen port for client
namesrvAddr	null	name server address
brokerIP1	InetAddress for network interface	Should be configured if having multiple addresses
brokerName	null	broker name
brokerClusterName	DefaultCluster	this broker belongs to which cluster
brokerId	0	broker id, 0 means master, positive integers mean slave
storePathCommitLog	$HOME/store/commitlog/	file path for commit log
storePathConsumerQueue	$HOME/store/consumequeue/	file path for consume queue
mapedFileSizeCommitLog	1024 * 1024 * 1024(1G)	mapped file size for commit log
deleteWhen	04	When to delete the commitlog which is out of the reserve time
fileReserverdTime	72	The number of hours to keep a commitlog before deleting it
brokerRole	ASYNC_MASTER	SYNC_MASTER/ASYNC_MASTER/SLAVE
flushDiskType	ASYNC_FLUSH	{SYNC_FLUSH/ASYNC_FLUSH}. Broker of SYNC_FLUSH mode flushes each message onto disk before acknowledging producer. Broker of ASYNC_FLUSH mode, on the other hand, takes advantage of group-committing, achieving better performance.

3、复制模式
为了确保成功发布的消息不会丢失，RocketMQ 提供了复制模式，以通过两种复制方式获得更强的持久性和更高的可用性：同步和异步。像许多复制系统一样，同步Brokers会等到提交日志被复制到从服务器才确认。相反，异步Brokers在主服务器上处理消息后立即返回。

六、实践

1、服务程序最简单的架构需要启动一个NameServer和一个Broker。
2、Broker中需要配置NameServer地址
3、先启动NameServer后Broker，关闭时先关闭Broker后NameServer。
4、如果需要保证服务HA，就要做NamerServer和Broker集群。
5、Producer Cluster和Consumer Cluster属于客户端了，所以整体结构应该是很清晰的了。
6、Producer和Consumer也需要知道NameServer地址。

Broker使用队列存储着各种Topic的消息，NameServer维护着所有Broker和Topic的关系，Broker配置文件中Broker和NameServer会一直保持连接，NameServer会通过心跳来实时清理故障的Broker，Producer需要配置NameServer的地址，定时从NameServer获取Topic和对应Broker信息，就能向Broker发送消息。Consumer需要配置NameServer的地址，定时从NameServer获取Topic和对应Broker信息，就可以从Broker拉取消息。

NameServer是无状态的服务，多个NameServer之间不进行通信，Broker，Consumer，Producer与NameServer之间的通信是单向的，也即Broker只向NameServer发送数据，Broker和Consumer只向NameServer请求数据，这种单向通信方式使架构的横向扩展很容易。因为NameServer可以直接添加主机进来，搭配好Broker就可以完成扩展了。下面说说具体的配置方式：

对于NameServer，因为是无状态服务，所以不需要任何配置，只需部署到不同物理主机即可。需要配置的是Broker，Broker中需要通过namesrvAddr配置所有NameServer的地址，属于一个集群的Broker通过相同的brokerName来划分，一个Broker集群中的Master通过brokerid=0来辨别，Slave的brokerid大于0，这三个配置基本就把Broker和NameServer的部署关系都描述的很清晰了，下面我们来看看启动服务的命令：

启动namesrv服务：nohup sh bin/mqnamesrv &
启动broker服务：nohup sh bin/mqbroker &
关闭namesrv服务：sh bin/mqshutdown namesrv
关闭broker服务 ：sh bin/mqshutdown broker
日志目录：{rocketMQ解压目录}/logs/rocketmqlogs/broker.log
日志目录：{rocketMQ解压目录}/logs/rocketmqlogs/namesrv.log