三、RocketMQ的JAVAAPI的基础概念

消息(Message)

生产者和消费者数据流转的基础数据模型，主要属性有

字段名	默认值	必要性	说明
Topic	null	必填	消息所属topic的名称
Body	null	必填	消息体
Tags	null	选填	消息标签，方便服务器过滤使用。目前只支持每个消息设置一个
Keys	null	选填	代表这条消息的业务关键词
Flag	0	选填	完全由应用来设置，RocketMQ不做干预
DelayTimeLevel	0	选填	消息延时级别，0表示不延时，大于0会延时特定的时间才会被消费
WaitStoreMsgOK	true	选填	表示消息是否在服务器落盘后才返回应答

属性解读

Topic

定义消息会发送到哪个Topic上

Body

消息携带的真正的业务数据

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）不一致，会导致消费消息紊乱，甚至消息丢失。