Broker

消息中转角色，负责存储消息，转发消息，一般也称Server。在 JMS规范中称为Provider。RocketMQ一般在多个服务器部署broker集群，从而达到分布式、高可用、可横向扩展的目的。

Name Server

Name Server是一个几乎无状态节点，可集群部署，节点之间无同步信息。它主要提供broker注册、Topic路由管理等功能。

Topic

在RocketMQ中，topic类似于JMS规范中的队列，所有消息都是存放在不同的topic中，生产者与消费者都以topic名字进行生产与消费。(注：RocketMQ的topic并不是jms规范中广播消费topic的概念)。

一个Topic可以存在多个broker之中，这样topic就可以分布在不同的broker从而达到分布式的目的。

一个Topic下面，可以有多个队列，可以理解成分区，Topic的消息是放在不同队列下的。

Queue

在RocketMQ中，queue是存放数据的最小单位，queue是存在于topic下面的。在RocketMQ中，queue不同于JMS规范中的队列，可以理解为topic的分区。

生产组

一类Producer的集合名称，这类Producer通常发送一类消息，且发送逻辑一致，一般由业务系统负责产生消息。

消费组

一类Consumer的集合名称，这类Consumer通常消费一类消息，且消费逻辑一致，一般是后台系统负责异步消费。消费进度由存储在消费组上。

消费者实例

一个消费者实例代表消费组的一员，不同的消费者用不同的实例名字创建。

生产者实例

一个生产者实例代表生产者的一员，不同的生产者用不同的实例名字创建。

PUSH消费

Consumer的一种，应用通常向Consumer对象注册一个Listener接口，一旦收到消息，Consumer对象立刻回调Listener接口方法。在RocketMQ中，客户端会自动起线程消费消息，线程数是5-64，意味着，listener里面的方法，会被多线程执行。客户端内部可以根据堆积量进行调整，使用者不需要新启、管理消费线程。并有流控机制，当客户端缓存一定量消费不及时，会停止推送新消息。

PULL消费

Consumer的一种，应用通常主动调用Consumer的拉消息方法从Broker拉消息，主动权由应用控制，但实时性取决于应用主动拉取的频率。在PULL消费中，线程由应用自主决定。

广播消费

注意：使用消费模式，在很多使用场景都会带来影响或限制，在RocketMQ中，应尽量避免使用此消费模式。在RocketMQ中，消费者有两种不同的方式消费topic中的消息，其中一种是广播消费。在广播消费模式下，一条消息被多个Consumer消费，即使这些Consumer属于同一个Consumer Group，消息也会被Consumer Group中的每个Consumer都消费一次，广播消费中的Consumer Group概念可以认为在消息划分方面无意义。V1.x版本由于广播消费的消费进度，是保存在客户端的，对于很多使用场景会带来影响，在RocketMQ中，并不推荐使用此消费模式。

集群消费

一个Topic可以被一个或多个Consumer Group消费，每个Consumer Group有自己独立的消费进度，消费进度是保存在服务端的。一个Consumer Group中的消费者实例可以平均分摊消费消息，做到负载均衡。例如某个Topic有9条消息，其中一个Consumer Group有3个不同的消费者实例（可能是3个进程，或者3台机器），那么每个实例只消费其中的3条消息。在此消费模式下，可以做到Point-To-Point的消费，也可以做到JMS里面广播消费，能满足绝大部分场景，推荐使用此消费模式。

有序消息

消费消息的顺序要同发送消息的顺序一致，在RocketMQ中，主要有两种有序消息。

普通有序消息

有序消息的一种，在正常情况下可以保证完全的顺序消息，但是一旦发生通信异常，Broker重启，由于队列总数发生变化，哈希取模后定位的队列会变化，产生短暂的消息顺序不一致。如果业务能容忍在集群异常情况（如某个Broker宕机或者重启）下，消息短暂的乱序，使用普通顺序方式比较合适。

严格有序消息

有序消息的一种。无论正常异常情况都能保证顺序，但是牺牲了分布式Failover特性，即Broker集群中只要有一台机器不可用，则整个集群都不可用（或者影响hash值对应队列的使用），服务可用性大大降低。如果服务器部署为同步双写模式，此缺陷可通过备机自动切换为主避免，不过仍然会存在几分钟的服务不可用。若业务能容忍短暂乱序，推荐普通有序消费。

分布式消息服务-RocketMQ