rocketmq概念总结

核心组成

官方文档看看挺好的
  rocketmq主要有四大核心组成部分：NameServer，Broker，Producer，Consumer四部分。

NameServer

  主要负责对源数据的管理，包括了对于Topic和路由信息的管理。

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

  NameServer是一个功能齐全的服务器，其角色类似Dubbo中的Zookeeper，但NameServer与Zookeeper相比更轻量。主要是因为每个NameServer节点互相之间是独立的，没有任何信息交互。
  NameServer压力不会太大，平时主要开销是在维持心跳和提供Topic-Broker的关系数据。
  Broker向NameServer发心跳时，会带上当前自己所负责的所有Topic信息，如果Topic个数太多（万级别），会导致一次心跳中，就Topic的数据就几十M，网络情况差的话， 网络传输失败，心跳失败，导致NameServer误认为Broker心跳失败。
  NameServer被设计成几乎无状态的，可以横向扩展，节点之间相互之间无通信，通过部署多台机器来标记自己是一个伪集群。
  每个 Broker 在启动的时候会到 NameServer 注册，Producer 在发送消息前会根据 Topic 到 NameServer 获取到 Broker 的路由信息，Consumer 也会定时获取 Topic 的路由信息。

Broker

  消息中转角色，负责存储消息，转发消息。

Broker主要负责消息的存储、投递和查询以及服务高可用保证，为了实现这些功能，Broker包含了以下几个重要子模块。

1. Remoting Module：整个Broker的实体，负责处理clients端的请求。
2. Client Manager：负责管理客户端(Producer/Consumer)和维护Consumer的Topic订阅信息。
3. Store Service：提供方便简单的API接口处理消息存储到物理硬盘和查询功能。
4. HA service：高可用服务，提供Master Broker和Slave Broker之间的数据同步功能。
5. Index Service：根据特定的Message key对投递到Broker的消息进行索引服务，以提供消息的快速查询。

  Broker是具体提供业务的服务器，单个Broker节点与所有的NameServer节点保持长连接和心跳，并会定时将topic的信息注册到NameServer，底层的通信和连接都是通过Netty实现的。
  Broker负责消息存储，以Topic为纬度支持轻量级的队列，单机可以支撑上万队列规模，支持消息推拉模型。
  支持上亿的消息堆积能力，同时可以严格保证消息的有序性。

Producer

  消息生产者，负责产生消息。

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

  Producer由用户进行分布式部署，消息由Producer通过多种负载均衡模式发送到Broker集群，发送低延时，支持快速失败。

  rocketmq提供了三种消息发送方式：同步，异步，单向。

1. 同步发送：同步发送指消息发送方发出数据后会在收到接收方发回响应之后才发下一个数据包。一般用于重要通知消息，例如重要通知邮件、营销短信。
2. 异步发送：异步发送指发送方发出数据后，不等接收方发回响应，接着发送下个数据包，一般用于可能链路耗时较长而对响应时间敏感的业务场景，例如用户视频上传后通知启动转码服务。
3. 单向发送：单向发送是指只负责发送消息而不等待服务器回应且没有回调函数触发，适用于某些耗时非常短但对可靠性要求并不高的场景，例如日志收集。

Consumer

 消息消费者，负责消费消息，一般时下游业务系统。

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

  Consumer也由用户部署，支持PUSH和PULL两种消费模式，支持集群消费和广播消息，提供实时的消息订阅机制。

1. PUSH：推送型消费者（Push Consumer）封装了消息的拉取、消费进度和其他的内部维护工作，将消息到达时执行的回调接口留给用户应用程序来实现。所以 Push 称为被动消费类型，但从实现上看还是从消息服务器中拉取消息，不同于 Pull 的是 Push 首先要注册消费监听器，当监听器处触发后才开始消费消息。
2. PULL：拉取型消费者（Pull Consumer）主动从消息服务器拉取信息，只要批量拉取到消息，用户应用就会启动消费过程，所以 Pull 称为主动消费型。

---

消息相关概念

Message（消息）

  message就是要传输的信息，一条消息必须有一个主题（Topic）。
  一条消息也可以拥有一个可选的标签（Tag）和额处的键值对，它们可以用于设置一个业务Key并在Broker上查找此消息以便在开发期间查找问题。
  一个Topic可以分散在多个Broker上，也可以在一个Broker上。
  消息分为三种：同步消息，异步消息，单向消息。

Topic（主题）

  可以看做消息的分类，它是消息的第一级类型。
  Topic与生产者和消费者的关系非常松散，一个Topic可以有0个、1个、多个生产者向其发送消息，一个生产者也可以同时向不同的Topic发送消息。一个Topic也可以被多个或者1个消费者订阅。

Tag（标签）

  以看作子主题，它是消息的第二级类型，用于为用户提供额外的灵活性。
  使用标签，同一业务模块不同目的的消息就可以用相同Topic而不同的Tag来标识，一条消息可以没有Tag。

Group（分组）

  一个分组可以订阅多个Topic。
  分组分为生产者分组和消费者分组，一般同一个服务作为一个组，一个组生产或消费的消息都是一致的。

Quene（队列）

  每个Queue内部是有序的，在RocketMQ中分为读和写两种队列，一般来说读写队列数量一致，如果不一致就会出现很多问题。

MessageQuene（消息队列）

  一个主题被划分为多个子主题，就是消息队列。
  一个Topic下可以设置多个消息队列，发送消息时执行该消息的Topic，RocketMQ会轮询该Topic下的所有队列将消息发出去，只会发送到一个MessageQuene中。
  消息的物理管理单位。一个Topic下可以有多个Queue，Queue的引入使得消息的存储可以分布式集群化，具有了水平扩展能力。

Offset

  在RocketMQ中，所有消息队列都是持久化，长度无限的数据结构，所谓长度无限是指队列中的每个存储单元都是定长，访问其中的存储单元使用Offset来访问，Offset为long类型，64位，理论上在100年内不会溢出，所以认为是长度无限。
  也可以认为Message Queue是一个长度无限的数组，Offset就是下标。

消息消费模式

  分为两种，集群消费模式，广播消费模式。

集群消费模式

  默认情况下就是集群消费，该模式下一个消费者集群共同消费一个主题的多个队列，一个队列只会被一个消费者消费，如果某个消费者挂掉，分组内其它消费者会接替挂掉的消费者继续消费。

广播消费模式

  而广播消费消息会发给消费者组中的每一个消费者进行消费，一个消息会被多次消费。

Message Order

  消息消费顺序，也有两种：顺序消费，并行消费。

顺序消费

  顺序消费表示消息消费的顺序同生产者为每个消息队列发送的顺序一致，所以如果正在处理全局顺序是强制性的场景，需要确保使用的主题只有一个消息队列。

并行消费

  并行消费不再保证消息顺序，消费的最大并行数量受每个消费者客户端指定的线程池限制。