消息队列Rocket的核心概念

(1) 消息模型(Message Model)
RocketMQ主要由 Producer、Broker、Consumer 三部分组成，其中Producer负责生产消息，Consumer负责消费消息，Broker负责存储消息。Broker在实际部署过程中对应一台服务器，每个Broker可存储多个Topic的消息，每个Topic的消息也可以分片存储于不同的Broker。MessageQueue存储消息的物理地址，每个Topic中的消息地址存储于多个Message Queue中。ConsumerGroup由多个Consumer 实例构成。

(2) Producer消息生产者，负责产生消息，一般由业务系统负责产生消息。

(3) Consumer消息消费者，负责消费消息，一般是后台系统负责异步消费。

(4) PushConsumer
Consumer消费的一种类型，该模式下Broker收到数据后会主动推送给消费端。应用通常向Consumer对象注册一个Listener接口，一旦收到消息，Consumer对象立刻回调Listener接口方法。该消费模式一般实时性较高。

5)PullConsumer
Consumer消费的一种类型，应用通常主动调用Consumer的拉消息方法从Broker服务器拉消息、主动权由应用控制。一旦获取了批量消息，应用就会启动消费过程。

6)ProducerGroup
同一类Producer的集合，这类Producer发送同一类消息且发送逻辑一致。若发送的是事务消息且原始生产者在发送之后崩溃，则Broker服务器会联系同一生产者组的其他生产者实例以提交或回溯消费。

7)ConsumerGroup
同一类Consumer的集合，这类Consumer通常消费同一类消息且消费逻辑一致。消费者组使得在消息消费方面，实现负载均衡和容错的目标变得非常容易。要注意的是，消费者组的消费者实例必须订阅完全相同的Topic。RocketMQ 支持两种消息模式：集群消费(Clustering)和广播消费(Broadcasting)。

8)Broker
消息中转角色，负责存储消息，转发消息，一般也称Server。在JMS规范中称为Provider。

9)广播消费
一条消息被多个Consumer消费，即使这些Consumer属于同一个Consumer Group，消息也会被Consumer Group中的每个 Consumer都消费一次，广播消费中的Consumer Group概念可以认为在消息划分方面无意义。
在CORBA Notification规范中，消费方式都属于广播消费。
在JMS规范中，相当于 JMS Topic(publish/subscribe)模型

10)集群消费
一个Consumer Group中的Consumer实例平均分摊消费消息。如某个Topic有9条消息，其中一个Consumer Group有3个实例(可能是3个进程，或3台机器)，那举每个实例只消费其中的3条消息。

11)顺序消息
消费消息的顺序要同发送消息的顺序一致，在RocketMQ中主要指的是局部顺序，即一类消息为满足顺序性，必须Producer单线程顺序发送，且发送到同一个队列，这样Consumer 就可以按照Producer发送的顺序去消费消息。

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

13)严格顺序消息
顺序消息的一种，无论正常异常情况都能保证顺序，但牺牲了分布式Failover特性，即Broker集群中只要有一台机器不可用，则整个集群都不可用，服务可用性大大降低。 若服务器部署为同步双写模式，此缺陷可通过备机自动切换为主避免，不过仍然会存在几分钟的服务不可用。(依赖同步双写，主备自动切换，自动切换功能目前还未实现)目前已知的应用只有数据库binlog同步强依赖严格顺序消息，其他应用绝大部分都可以容忍短暂乱序，推荐使用普通的顺序消息。

14)Message Queue
在RocketMQ中，所有消息队列都是持久化的，长度无限的数据结构，所谓长度无限是指队列中的每个存储单元都是定长，访问其中的存储单元使用Offset来访问，offset为java long类型，64位，理论上在100年内不会溢出，所以认为是长度无限，另外队列中只保存最近几天的数据，之前的数据会按照过期时间来删除。也可以认为Message Queue是一个长度无限的数组，offset就是下标。

15)标签(Tag)
为消息设置的标志，用于同一主题下区分不同类型的消息。来自同一业务单元的消息，可以根据不同业务目的在同一主题下设置不同标签。标签能够有效地保持代码的清晰度和连贯性，并优化RocketMQ提供的查询系统。消费者可以根据Tag实现对不同子主题的不同消费逻辑，实现更好的扩展性。