RocketMQ 投递消息方式以及消息体结构分析：Message、MessageQueueSelector

🔭 嗨，您好 👋 我是 vnjohn，在互联网企业担任 Java 开发，CSDN 优质创作者
📖 推荐专栏：Spring、MySQL、Nacos、Java，后续其他专栏会持续优化更新迭代
🌲文章所在专栏：RocketMQ
🤔 我当前正在学习微服务领域、云原生领域、消息中间件等架构、原理知识
💬 向我询问任何您想要的东西，ID：vnjohn
🔥觉得博主文章写的还 OK，能够帮助到您的，感谢三连支持博客🙏
😄 代词: vnjohn
⚡ 有趣的事实：音乐、跑步、电影、游戏

目录

前言

在踏入投递消息 send 方法源码解读开始前，要先搞清楚消息的结构以及消息的不同的方式实现，以便于在阅读底层源码时不至于要重头过来再梳理各自的类、属性结构起到了什么作用，在这里再啰嗦啰嗦，让 RocketMQ 源码能够更加完整.

RocketMQ 专栏篇：

从零开始：手把手搭建 RocketMQ 单节点、集群节点实例

保护数据完整性：探索 RocketMQ 分布式事务消息的力量

RocketMQ 分布式事务消息实战指南：确保数据一致性的关键设计

RocketMQ 生产者源码分析：DefaultMQProducer、DefaultMQProducerImpl

RocketMQ MQClientInstance、生产者实例启动源码分析

Message

RocketMQ 消息构成的结构如下：

1. Topic：表示要发送消息的主题
2. body：表示消息的存储内容
3. Properties：表示消息属性
4. transactionId：在事务消息中使用

Keys、Tag：无论是 RocketMQ Tag 过滤还是延迟消息等都会利用 Properties 消息属性机制，这些特殊信息都使用了系统保留的属性 Key，设置自定义属性时要避免和系统属性 Key 相冲突

服务端会根据 Keys 创建哈希索引，设置以后，可以在 Console 系统通过 Topic、Keys 来查询消息，由于是哈希索引，尽可能保证 Key 唯一，例如：订单号、会员 Id 等

RocketMQ 系统保留的属性 Key 集合，在使用消息属性机制时尽量避免：org.apache.rocketmq.common.message.MessageConst

Properties

在 Message 结构体中可以设置的属性如下：

Topic、Tag

Topic、Tag 都是用来在业务上分类的标识，区别在于 Topic 是一级分类，Tag 理解为是二级分类，使用 Tag 可以实现对 Topic 中的消息进行过滤

Topic：消息主题，通过 Topic 对不同的业务消息进行分类

Tag：消息标签，用来进一步区分某个 Topic 下的消息分类，消息从生产者发出时就带上的属性

Tag 属性可以为 Topic 做另外一层业务上再细粒化地区分子业务

什么时候该用 Topic，什么该用 Tag？

一般可以从以下几方面进行判别：

1. 消息类型是否一致：普通消息、事务消息、定时(延时)消息、顺序消息，不同的消息类型使用不同的 Topic，无法通过 Tag 进行区分

   除了普通消息以外，其余的消息类型应该使用对应的后缀拼接，如：事务 _transaction、延迟 _delay、顺序 _order

2. 业务是否相关联：没有直接关联的消息，如淘宝交易消息与京东物流消息使用不同的 Topic 区分；若同样的是京东物流消息，电器类订单、男装类订单、鞋类订单的消息可以使用 Tag 进行划分

3. 消息优先级是否一致：如同样是物流消息，盒马必须小时内送达，天猫超市 24 小时内送达，淘宝物流则相对会慢一些，不同优先级的消息用不同的 Topic 进行区分

4. 消息量级是否相当：有些业务消息虽然量小但是实时性要求高，如果跟某些万亿量级的消息使用同一个 Topic，则有可能会因为过长的等待时间而“饿死”，此时需要将不同量级的消息进行拆分，使用不同的 Topic

总的来说，针对消息分类，可以选择创建多个 Topic，或者在同一个 Topic 下创建多个 Tag；通常情况下，不同的 Topic 之间消息没有必然的联系，而 Tag 则用来区分