1.MQ的基本要素

1.1.消息（Message）

消息是 RocketMQ 中的最小数据传输单元。生产者将业务数据的负载和拓展属性包装成消息发送到服务端，服务端按照相关语义将消息投递到消费端进行消费。
消息由以下几个部分组成：

• 消息主题（Topic）：用于标识同一类业务逻辑的消息。

• 消息标签（Tag）：用于进一步区分某个主题下的消息分类，消费者可以通过订阅特定的标签来实现细粒度过滤。

• 消息体（Body）：存储业务数据的负载，可以是任意格式的字节数组。

• 消息属性（Property）：存储一些拓展属性，如消息ID、消息类型、消息优先级等。

• 消息索引（Key）：用于快速查找到对应的消息内容。

  1.2.主题（Topic）

  主题是 RocketMQ 中消息传输和存储的顶层容器，用于标识同一类业务逻辑的消息。主题通过TopicName来做唯一标识和区分。
  主题的作用主要如下：

• 定义数据的分类隔离：建议将不同业务类型的数据拆分到不同的主题中管理，通过主题实现存储的隔离性和订阅隔离性。

• 定义数据的身份和权限：RocketMQ 的消息本身是匿名无身份的，同一分类的消息使用相同的主题来做身份识别和权限管理。
  RocketMQ 支持以下几种类型的主题：

• Normal：普通消息，消息本身无特殊语义，消息之间也没有任何关联。

• FIFO：顺序消息，RocketMQ 通过消息分组MessageGroup标记一组特定消息的先后顺序，可以保证消息的投递顺序严格按照消息发送时的顺序。

• Delay：定时/延时消息，通过指定延时时间控制消息生产后不要立即投递，而是在延时间隔后才对消费者可见。

• Transaction：事务消息，RocketMQ 支持分布式事务消息，支持应用数据库更新和消息调用的事务一致性保障。

  1.3.标签（Tag）

  标签是 RocketMQ 提供的细粒度消息分类属性，可以在主题层级之下做消息类型的细分。消费者通过订阅特定的标签来实现细粒度过滤。
  标签可以根据业务需求自定义，例如：

• 订单创建、支付、取消等流程消息可以使用一个主题OrderTopic，并使用不同的标签OrderCreate、OrderPay、OrderCancel来区分不同阶段的订单消息。

• 物流相关消息可以使用一个主题LogisticsTopic，并使用不同的标签LogisticsSend、LogisticsReceive、LogisticsReturn来区分不同状态的物流消息。

  1.4.队列（MessageQueue）

  队列是 RocketMQ 中消息存储和传输的实际容器，也是消息的最小存储单元。RocketMQ 的所有主题都是由多个队列组成，以此实现队列数量的水平拆分和
  队列内部的流式存储。
  队列通过QueueId来做唯一标识和区分。每个主题内至少包含一个队列，队列数量在创建主题时定义，可以根据业务量和性能需求进行调整。
  队列的作用主要如下：

• 实现消息的水平扩展：通过增加队列数量，可以提高消息的存储和传输能力，支持更大规模的业务场景。

• 实现消息的负载均衡：通过将不同的队列分配给不同的生产者和消费者，可以实现消息的负载均衡，避免单点压力过大。

• 实现消息的顺序保证：对于顺序消息，RocketMQ 会将同一组顺序消息发送到同一个队列中，以保证消息的投递顺序。

  1.5.消息标识（MessageId）

  消息标识是 RocketMQ 为每条消息生成的一个全局唯一的字符串，用于标识和追踪消息。消息标识由以下几部分组成：

• BrokerName：消息所在的Broker节点名称。

• BrokerId：消息所在的Broker节点ID。

• CommitLogOffset：消息在CommitLog中的偏移量。

• QueueId：消息所在的队列ID。

• QueueOffset：消息在队列中的偏移量。
  通过消息标识，可以快速定位到某条特定的消息，并获取其相关信息。例如，可以通过查询消息轨迹来查看消息从生产者发出到消费者接收并处理过程中的完整链路信息。

2.MQ中的主要角色和相关联系

2.1.Producer

• Producer是消息的生产者，负责将业务系统中产生的消息发送到Broker。
• Producer支持多种发送方式，如同步发送、异步发送、顺序发送和单向发送。
• Producer还支持批量发送、异步发送、压缩发送等方式来降低网络开销和提高吞吐量。
• Producer在发送消息之前，需要先从NameServer集群中的随机一台获取Topic和Broker的映射关系，并缓存在本地内存中。
• 然后根据负载均衡策略选择一个Broker Master建立长连接，并将消息发送到该Broker。
• 如果发送失败，Producer会根据不同的发送方式进行重试或回调。

2.2.Broker

• Broker是消息的存储者，负责接收Producer发送的消息，并将消息存储在磁盘或内存中。
• Broker还负责响应Consumer的拉取请求，并将消息返回给Consumer。
• Broker支持主从部署，一个Master可以对应多个Slave，Master支持读写，Slave只支持读。
• Broker在启动时，会向NameServer集群中的每一台注册自己的路由信息，并定期发送心跳包来维持连接。
• Broker还会定期扫描磁盘或内存中的消息，删除过期或已消费的消息，以释放空间。
• Broker还提供了事务消息、顺序消息、延迟消息等功能来满足不同场景的需求。

2.3.Consumer

• Consumer是消息的消费者，负责从Broker拉取或推送消息，并进行业务处理。
• Consumer支持两种消费模式：集群消费和广播消费。
  • 集群消费模式下，同一个Consumer Group中的Consumer实例会对同一个Topic下的不同Message Queue进行负载均衡消费；
  • 广播消费模式下，同一个Consumer Group中的Consumer实例会对同一个Topic下的所有Message Queue都进行消费。
• Consumer在启动时，也需要先从NameServer集群中的随机一台获取Topic和Broker的映射关系，并缓存在本地内存中。
• 然后根据消费模式和负载均衡策略选择一个或多个Broker Master或Slave建立长连接，并从它们拉取或推送消息。
• 如果拉取失败，Consumer会根据重试策略进行重试或回调。

2.4.NameServer

• NameServer是一个轻量级的路由注册中心，支持Broker的动态注册和发现，保存Topic和Broker之间的关系。
• NameServer通常也是集群部署，但是各NameServer之间不会互相通信，各NameServer都有完整的路由信息，即无状态。
• NameServer提供了简单而高效的路由服务，使得Producer和Consumer能够快速找到对应的Broker地址，并且能够动态感知Broker的上下线变化。