1：技术/部署架构
1.1：基础架构
RocketMq是阿里巴巴开源的一款分布式消息中间件，具有低延迟、高并发、高可用、高可靠、灵活伸缩等特性！目前已经成为Apache的一个顶级的开源项目。
1：NameServer：NameServer是一个轻量级的Topic路由注册中心，角色类似于springcloud中的eureka，dubbo中的zk。支持broker的动态注册和发现。
主要有包含两个重要功能：
Broker管理 NameServer接受来自Broker集群的注册信息并保存下来，作为路由信息的基本数据，并提供心跳检测，检查Broker是否存活。
路由信息管理 每个NameServer将保存关于Broker集群的整个路由信息和用于客户端查询的队列信息，这样，Producer和Conumser通过NameServer就可以知道整个Broker集群的路由信息，从而进行消息的投递和消费。
NameServer是一个几乎无状态的节点,可集群部署,支持快速水平存储扩展。NameServer各实例间相互不进行信息通讯。Broker向每台NameServer注册自己的路由信息，所以每一个NameServer上都保存着一份完整的路由信息。此时就算某一个NameServer因为某种原因下线了，Broker仍然可以从其他的NameServer同步路由信息，producer和consumer仍然可以动态感知Broker的路由信息。
2：Producer:：发布消息的角色，可以理解为生产者，可以支持分布式集群部署，Producer通过MQ的负载均衡模块选择相应的Broker集群队列进行消息投递，投递的过程支持快速失败并且低延迟。
Producer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer获取Topic路由信息，并向提供Topic 服务的Master建立长连接，且定时向Master发送心跳。
3：Consumer：消息消费的角色，支持分布式集群方式部署。支持以push推，pull拉两种模式对消息进行消费。同时也支持集群方式和广播方式的消费，它提供实时消息订阅机制。
Consumer与NameServer集群中的其中一个节点（随机选择）建立长连接，定期从NameServer获取Topic路由信息，并向提供Topic服务的Master、Slave建立长连接，且定时向Master、Slave发送心跳。
Consumer既可以从Master订阅消息，也可以从Slave订阅消息，消费者在向Master拉取消息时，Master服务器会根据拉取偏移量与最大偏移量的距离（判断是否读老消息，产生读I/O），以及从服务器是否可读等因素建议下一次是从Master还是Slave拉取。
4：Broker：消息中转角色，Broker主要负责消息的存储、投递和查询以及服务高可用保证。分为 Master Broker 和 Slave Broker，一个Master可以对应多个Slave，但是一个Slave只能对应一个Master，Master与Slave 的对应关系通过指定相同的BrokerName，不同的BrokerId 来定义，BrokerId为0表示Master，非0表示Slave。Master也可以部署多个。每个Broker与NameServer集群中的所有节点建立长连接，定时注册Topic信息到所有NameServer。
注意：当前RocketMQ版本在部署架构上支持一Master多Slave，但只有BrokerId=1的从服务器才会参与消息的读负载。
Broker服务器有几个重要的子模块：
- Remoting Module：负责处理来自clients端的请求。
- Client Manager：负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息
- Store Service：提供方便简单的API接口处理消息存储到物理硬盘和查询功能。
- HA Service：高可用服务，提供Master Broker 和 Slave Broker之间的数据同步功能。
- Index Service：根据特定的Message key对投递到Broker的消息进行索引服务，以提供消息的快速查询。
1.2：集群工作流程
- 启动NameServer，NameServer起来后监听端口，等待Broker、Producer、Consumer连上来，相当于一个路由控制中心。
- Broker启动，跟所有的NameServer保持长连接，定时发送心跳包。心跳包中包含当前Broker信息(IP+端口等)以及存储所有Topic信息。注册成功后，NameServer集群中就有Topic跟Broker的映射关系。
- 收发消息前，先创建Topic，创建Topic时需要指定该Topic要存储在哪些Broker上，也可以在发送消息时自动创建Topic。
- Producer发送消息，启动时先跟NameServer集群中的其中一台建立长连接，并从NameServer中获取当前发送的Topic存在哪些Broker上，轮询从队列列表中选择一个队列，然后与队列所在的Broker建立长连接从而向Broker发消息。
- Consumer跟Producer类似，跟其中一台NameServer建立长连接，获取当前订阅Topic存在哪些Broker上，然后直接跟Broker建立连接通道，开始消费消息。
2：基础概念模型
- Topic：消息主题，一级消息类型，通过 Topic 对消息进行分类
- Message：消息，消息队列中信息传递的载体。
- Message ID：消息的全局唯一标识，由 MQ 系统自动生成，唯一标识某条消息。
- Message Key：消息的业务标识，由消息生产者（Producer）设置，唯一标识某个业务逻辑。
- Tag：消息标签，二级消息类型，用来进一步区分某个 Topic 下的消息分类,消费者可以通过该tag在消费者程序端进行消息过滤。
- Producer：消息生产者，也称为消息发布者，负责生产并发送消息。
- Producer 实例：Producer 的一个对象实例，不同的 Producer 实例可以运行在不同进程内或者不同机器上。Producer 实例线程安全，可在同一进程内多线程之间共享。
- Consumer：消息消费者，也称为消息订阅者，负责接收并消费消息。
- Consumer 实例：Consumer 的一个对象实例，不同的 Consumer 实例可以运行在不同进程内或者不同机器上。一个 Consumer 实例内配置线程池消费消息。
- Group：一类 Producer 或 Consumer，这类 Producer 或 Consumer 通常生产或消费同一类消息，且消息发布或订阅的逻辑一致
- Group ID：Group 的标识。
- 队列QUEUE：每个 Topic 下会由一到多个队列来存储消息
- Exactly-Once 投递语义：Exactly-Once 投递语义是指发送到消息系统的消息只能被 Consumer 处理且仅处理一次，即使 Consumer 重试消息发送导致某消息重复投递，该消息在 Consumer 也只被消费一次
- 集群消费：一个 Group ID 所标识的所有 Consumer 平均分摊消费消息。例如某个 Topic 有 9 条消息，一个 Group ID 有 3 个 Consumer 实例，那么在集群消费模式下每个实例平均分摊，只消费其中的 3 条消息。
- 广播消费：一个 Group ID 所标识的所有 Consumer 都会各自消费某条消息一次。例如某个 Topic 有 9 条消息，一个 Group ID 有 3 个 Consumer 实例，那么在广播消费模式下每个实例都会各自消费 9 条消息。
- 定时消息：Producer 将消息发送到消息队列 RocketMQ 版服务端，但并不期望这条消息立马投递，而是推迟到在当前时间点之后的某一个时间投递到 Consumer 进行消费，该消息即定时消息。（开源版本的RocketMq好像不支持定时消息投递）
- 延时消息：Producer 将消息发送到消息队列 RocketMQ 版服务端，但并不期望这条消息立马投递，而是延迟一定时间后才投递到 Consumer 进行消费，该消息即延时消息
- 事务消息：消息队列RocketMQ提供类似 X/Open XA 的分布事务功能，通过RocketMq事务消息能达到分布式事务的最终一致
- 顺序消息：消息队列 RocketMQ 提供的一种按照顺序进行发布和消费的消息类型，分为全局顺序消息和分区顺序消息
- 全局顺序消息：对于指定的一个 Topic，所有消息按照严格的先入先出（FIFO）的顺序进行发布和消费
- 分区顺序消息：对于指定的一个 Topic，所有消息根据 Sharding Key 进行区块分区。同一个分区内的消息按照严格的 FIFO 顺序进行发布和消费
- 消息堆积：Producer 已经将消息发送到消息队列 RocketMQ 的服务端，但由于 Consumer 消费能力有限，未能在短时间内将所有消息正确消费掉，此时在消息队列 RocketMQ 的服务端保存着未被消费的消息，该状态即消息堆积。
- 消息过滤： Consumer 可以根据消息标签（Tag）对消息进行过滤，确保 Consumer 最终只接收被过滤后的消息类型。消息过滤在消息队列 RocketMQ 的服务端完成
- 消息轨迹： 在一条消息从 Producer 发出到 Consumer 消费处理过程中，由各个相关节点的时间、地点等数据汇聚而成的完整链路信息
- 重置消费位点: 以时间轴为坐标，在消息持久化存储的时间范围内（默认 3 天），重新设置 Consumer 对已订阅的 Topic 的消费进度，设置完成后 Consumer 将接收设定时间点之后由 Producer 发送到消息队列 RocketMQ 版服务端的消息
- 死信队列： 死信队列用于处理无法被正常消费的消息。当一条消息初次消费失败，消息队列 RocketMQ 会自动进行消息重试；达到最大重试次数后，若消费依然失败，则表明 Consumer 在正常情况下无法正确地消费该消息。此时，消息队列 RocketMQ 不会立刻将消息丢弃，而是将这条消息发送到该 Consumer 对应的特殊队列中。 消息队列 RocketMQ 将这种正常情况下无法被消费的消息称为死信消息（Dead-Letter Message），将存储死信消息的特殊队列称为死信队列（Dead-Letter Queue）
参考：github.com/apache/rock… 关于rocketMq的概念，基本都参考了官方的文档。
