三、RocketMQ的JAVAAPI的基础概念

消息(Message)

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

属性解读

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