二、RocketMQ的安装与启动

二、系统架构

1、Producer

2、consumer

消费者组之间是相互独立的

3、Name Server

kafka依赖zookeeper做集群管理

在RocketMQ的早期版本，即在MetaQ v1.0与v2.0版本中，也是依赖于Zookeeper的。
从MetaQ v3.0，即RocketMQ开始去掉了Zookeeper依赖，使用了自己的NameServer。

Name Server的作用：
1）Broker管理：接受Broker集群的注册信息并且保存下来作为路由信息的基本数据；提供心跳检测机制，检查Broker是否还存活。

2）路由信息管理：

• 路由注册：
  Broker节点为了证明自己是活着的，为了维护与NameServer间的长连接，会将最新的信息以心跳包方式上报给NameServer，每30秒发送一次心跳。心跳包中包含 BrokerId、Broker地址(IP+Port)、Broker名称、Broker所属集群名称等等。NameServer在接收到心跳包后，会更新心跳时间戳，记录这个Broker的最新存活时间

• 路由剔除：
  由于Broker关机、宕机或网络抖动等原因，NameServer没有收到Broker的心跳，NameServer可能会将其从Broker列表中剔除。

  NameServer中有⼀个定时任务，每隔10秒就会扫描⼀次Broker表，查看每一个Broker的最新心跳时间戳距离当前时间是否超过120秒，如果超过，则会判定Broker失效，然后将其从Broker列表中剔除。

  扩展：对于RocketMQ日常运维工作，例如Broker升级，需要停掉Broker的工作。OP需要怎么做？

• 路由发现：
  RocketMQ的路由发现采用的是Pull模型。当Topic路由信息出现变化时，NameServer不会主动推送给客户端，而是客户端定时拉取主题最新的路由。默认客户端每30秒会拉取一次最新的路由。

• 客户端NameServer选择策略
  客户端在配置时必须要写上NameServer集群的地址，那么客户端到底连接的是哪个NameServer节点呢？

  客户端首先会生产一个随机数，然后再与NameServer节点数量取模，此时得到的就是所要连接的节点索引，然后就会进行连接。如果连接失败，则会采用round-robin策略，逐个尝试着去连接其它节点。

4、Broker

功能：
Broker充当着消息中转角色，负责存储消息、转发消息。

模块构成：

集群部署：

5、工作流程

启动流程

3）发送消息前，先创建Topic

4）producer发送消息

5）消费者消费消息

Topic的创建模式
手动创建Topic时，有两种模式：
集群模式：该模式下创建的Topic在该集群中，所有Broker中的Queue数量是相同的。
Broker模式：该模式下创建的Topic在该集群中，每个Broker中的Queue数量可以不同。

读/写队列

三、单机安装启动

四、rocketmq_dashboard的安装

五、集群搭建理论