消息(Message)
生产者和消费者数据流转的基础数据模型，主要属性有
| 字段名 | 默认值 | 必要性 | 说明 |
|---|---|---|---|
| Topic | null | 必填 | 消息所属topic的名称 |
| Body | null | 必填 | 消息体 |
| Tags | null | 选填 | 消息标签，方便服务器过滤使用。目前只支持每个消息设置一个 |
| Keys | null | 选填 | 代表这条消息的业务关键词 |
| Flag | 0 | 选填 | 完全由应用来设置，RocketMQ不做干预 |
| DelayTimeLevel | 0 | 选填 | 消息延时级别，0表示不延时，大于0会延时特定的时间才会被消费 |
| WaitStoreMsgOK | true | 选填 | 表示消息是否在服务器落盘后才返回应答 |
属性解读
Topic
定义消息会发送到哪个Topic上
Body
消息携带的真正的业务数据
Tags
消息在同一个Topic进行的二级分类
不同的 Topic 之间的消息没有必然的联系，而 Tag 则用来区分同一个 Topic 下相互关联的消息，例如全集和子集的关系、流程先后的关系。
Keys
Apache RocketMQ 每个消息可以在业务层面的设置唯一标识码 keys 字段，方便将来定位消息丢失问题。 Broker 端会为每个消息创建索引（哈希索引），应用可以通过 topic、key 来查询这条消息内容，以及消息被谁消费。由于是哈希索引，请务必保证 key 尽可能唯一，这样可以避免潜在的哈希冲突。
Flag
选填，消息的标记，完全由应用设置，RocketMQ不做任何处理，类似于memcached中flag的作用。目前还没应用过
DelayTimeLevel
设置延迟消息，当大于0时，代表此消息是延迟消息，会被延迟消费
WaitStoreMsgOK
消息在被发送端发送到broker，broker在将消息存储到磁盘上之后，才会进行返回，保证消息的可靠性。
队列(MessageQueue)
队列是消息存储的物理概念，
一个topic会有多个队列
一个消息最终会发送到topic的某个队列上
一个消费者也会从一个或多个队列上进行消费
生成者(Producer)
消息的起始，将业务消息组装成message，发送给broker
发送消息的方式
- 普通消息发送
- 同步发送
- 异步发送
- 单向发送
- 顺序消息发送
- 批量消息发送
- 延迟消息发送
- 事务消息发送
消费者(Consumer)
消息的终点，负责将消息从broker中取出，并进行处理
消息者与队列形成对应关系：
- 消费者 >= 队列：消费者与队列形成一对一的关系，其余的消费者空闲
- 消费者 < 队列：一个消费者对应多个队列
消费模式
消息获取方式的消费模式
-
push
Push是服务端主动推送消息给客户端，优点是及时性较好，但如果客户端没有做好流控，一旦服务端推送大量消息到客户端时，就会导致客户端消息堆积甚至崩溃。
-
pull
Pull是客户端需要主动到服务端取数据，优点是客户端可以依据自己的消费能力进行消费，但拉取的频率也需要用户自己控制，拉取频繁容易造成服务端和客户端的压力，拉取间隔长又容易造成消费不及时。
消费者组内消息分配方式的消费模式
-
集群模式
消费者组内的消费者互斥的消费消息，一个消费者组消费全量的消息
-
广播模式
消费者组内的每一个消费者都消费全量的消息
订阅关系一致
同一个消费者组下所有消费者实例所订阅的Topic、Tag必须完全一致。如果订阅关系（消费者组名-Topic-Tag）不一致，会导致消费消息紊乱，甚至消息丢失。
