【本文参考领域模型概述 | RocketMQ (apache.org)】基于5.0版本。
1 领域模型概述
Apache RocketMQ是一款典型的分布式架构下的中间件产品，使用异步通信方式和发布订阅的消息传输模型。通信方式和传输模型的具体说明，请参考下文通信方式介绍和消息传输模型介绍。Apache RocketMQ产品具备异步通信的优势，系统拓扑简单、上下游耦合较低，主要用于异步解耦，流量削峰填谷等场景。
1.1 Apache RocketMQ 领域模型
如上图所示，Apache RocketMQ中消息的声明周期主要分为消息生产、消息存储、消息消费三部分。
生产者生产消息并发送到Apache RocketMQ服务端，消息被存储在服务端的主题中，消费者通过订阅主题消费消息。
消息生产
生产者（Producer）:
Apache RocketMQ 中用于生产消息的运行实体，一般集成于业务调用链上游。生产者是轻量级匿名无身份的。
消息存储
（1）主题（Topic）：
Apache RocketMQ 消息传输和存储的分组容器，主题内部有多个队列组成，消息的存储和水平扩展实际是通过主题内的队列实现的。
（2）队列（Message Queue）:
Apache RocketMQ 消息存储和存储的实际单元容器，类比于其他消息队列的分区。Apache RocketMQ通过流式特性的无限队列结构来存储消息，消息在队列中具备顺序性存储特征。
（3）消息（Message）：
Apache RocketMQ 的最小传输单元。消息具备不可变性，在初始化发送和完成传输后即不可变。
消息消费
（1）消费者分组（ConsumerGroup）：
Apache RocketMQ 发布订阅模式中定义的独立的消费身份分组，用于统一管理底层运行的讴歌消费者（Consumer）。同一个消费组的多个消费者必须保持消费逻辑和配置一致，共同分担该消费组订阅的消息，实现消息能力的水平扩展。
（2）消费者（Consumer）：
Apache RocketMQ 消费消息的运行实体，一般集成在业务调用链的下游。消费者 必须被指定到某一个消费组中。
（3）订阅关系（Subscription）:
Apache RocketMQ 发布订阅模型中消息过滤、重试、消费进度的规则配置。订阅关系以消费组粒度进行管理，消费组通过定义订阅关系控制执行消费组下的消费者如何实现消息过滤、消费重试以及消费进度恢复等。
Apache RocketMQ 的订阅关系除了过滤表达式之外都是持久化的，即服务端重启或请求断开，订阅关系依然保留。
1.2 通信方式介绍
分布式系统架构思想下，将复杂系统拆分为多个独立的子模块，例如微服务模块。此时就需要考虑子模块之间的远程通信，典型的通信模式分为以下两种：同步的RPC远程调用和基于中间件代理的异步通信方式。
同步RPC调用模型：
同步RPC调用模型下，不同系统之间直接进行调用通信，每个请求直接从调用方发送到被调用方，然后要求被调用方立即返回响应结果给调用方，已确定本次调用结果是否成功。注意：此处的同步并不代表RPC的编程接口方式，RPC也可以有异步非阻塞调用的编程方式，但本质上仍然是需要再指定时间内得到目标端的直接响应。
异步通信模型：
异步消息通信模式下，各子系统之间无需强耦合直接连接，调用方只需要将请求转化成异步事件（消息）发送给中间代理，发送成功即可认为该异步链路调用完成，剩下的工作中间代理会负责将事件（消息）可靠通知到下游的调用系统，确保任务执行完成。该中间代理一般就是消息中间件。
异步通信优势如下：
1、系统拓扑简单。由于调用方和被调用方统一和中间代理通信，系统是星型结构，易于维护和管理。
2、上下游耦合性弱。上下游系统之间弱耦合，结构更灵活，由中间代理负责缓冲和异步恢复。上下游系统之间可以独立升级和变更，不会互相影响。
3、容量削峰填谷。基于消息的中间代理往往具备很强的流量缓冲和整形能力，业务流量高峰到来时不会击垮下游。
1.3 消息传输模型介绍
主流的消息中间件和传输模型主要为点对点模型和发布订阅模型。
点对点模型
点对点模型也叫队列模型，具有以下特点：
消息匿名：消息上下游沟通的唯一的身份就是队列，下游消费者从队列获取消息无法申明独立身份。
一对一通信：基于消费者匿名特点，下游消费者即使有多个，但都没有自己独立的身份，因此共享队列中的消息，每一条消息都只会被唯一一个消费者处理。因此点对点模型只能实现一对一通信。
发布订阅模型
发布订阅模型具有如下特点：
1、消费独立：相比队列模型的匿名消费方式，发布订阅模型中消费方都会具备的身份，一般叫订阅组（订阅关系），不同订阅组之间相互独立不会互相影响。
2、一对多通信：基于独立身份的设计，同一个主题内的消息可以被多个订阅组处理，每个订阅组都可以拿到全量消息。因此发布订阅模型可以实现一对多通信。
传统模型相比
点对点模型和发布订阅模型各有优势，点对点模型更为简单，而发布订阅模型扩展性更高。 Apache RocketMQ使用的传输模型为发布订阅模型，因此也具有发布订阅模型的特点。
2 主题（Topic）
本节介绍Apache RocketMQ 中的主题（Topic）的定义、模型关系、内部属性、行为约束、版本兼容和使用建议。
2.1 定义
主题是Apache RocketMQ 中消息传输和存储的顶层容器，用于标识同一类业务逻辑的消息。主题的作用主要如下：
1、定义数据的分类隔离：在Apache RocketMQ 的方案设计中，建议将不同业务模型的数据拆分到不同的主题中管理，通过主题实现存储的隔离性和订阅隔离性。
2、定义数据的身份和权限：Apache RocketMQ 的消息本身是匿名无身份的，同一分类的消息使用相同的主题来做身份识别和权限管理。
2.2 模型关系
在整个Apache RocketMQ 的领域模型中，主题所处的流程和位置如下：
主题是Apache RocketMQ 的顶层存储，所有消息资源的定义都在主题内完成，但主题是一个逻辑概念，并不是实际的消息容器。
主题内部由多个队列组成，消息的存储和水平扩展能力最终是由队列实现的；并且针对主题的所有约束和属性设置，最终也是通过主题内部的队列来实现的。
2.3 内部属性
主题名称
定义：主题的名称，用于标识主题，主题名称集群内全局唯一。
取值：由用户创建主题时定义。
约束：请参见 参数限制
队列列表
定义：队列作为主题的组成单元，是消息存储的实际容器。一个主题内包含一个或多个列队，消息实际主题的各个队列中。
取值：系统根据队列数量给主题分配队列，队列数量在创建主题是定义。
约束：一个主题内至少包含一个队列。
消费类型
定义：主题所支持的消息类型。
取值：创建主题时选择消息类型。Apache RocketMQ 支持的主题类型如下：
1、Normal：普通消息，消息本身无特殊语义，消息之间也没有任何关联。
2、FIFO：顺序消息，Apache RocketMQ通过消息分组MessageGroup标记一组特定消息的先后顺序，可以保证消息的投递顺序严格按照消息发送时的顺序。
3、Delay：定时/延时消息，通过执行延时时间控制消息生产后不会立即投递，而在是延时间隔后才对消费者可见。
4、Transaction：事务消息，Apache RocketMQ 支持分布式事务消息，支持应用数据库更新和消息调用的事务一致性保障。
约束：Apache RocketMQ 从5.0版本开始，支持强制校验消息类型，即每个主题值允许发送一种类型的消息，这样可以更好的运维和管理生产系统，避免混乱。为保证向下兼容4.x版本，强制校验功能默认开启。
2.4 行为约束
消息类型强制校验
Apache RocketMQ 5.x版本支持将消息类型拆分到主题中进行独立运维和管理，因此系统会对发送的消息类型和主题定义的消息类型进行强制校验，如果校验不通过，则消息发送请求会被拒绝，并返回类型不匹配异常。校验规则如下：
1、消息类型必须一致：发送的消息的类型，必须和目标主题定义的消息类型一致。
2、主题类型必须单一：每个主题只支持一种消息类型，不允许将多种类型的消息发送到同一个主题中。
常见错误使用场景
发送的消息类型不匹配，例如：创建主题时消息类型定义为顺序消息，发送消息时发送事务消息到该主题中，此时消息发送请求会被拒绝，并返回类型不匹配异常。
单一消息主题混用，例如：创建主题时消息类型定义为普通消息，发送消息时同时发送普通消息和顺序消息到该主题，则顺序消息的发送请求会被拒绝，并返回类型不匹配异常。
2.5 使用建议
按照业务分类合理拆分主题
Apache RocketMQ 的主题拆分设计应遵循大类统一原则，即将相同业务域内同一功能属性的消息划分为同一主题。拆分主题时，可以从以下角度考虑拆分粒度：
1、消息类型是否一致：不同类型的消息，如顺序消息和普通消息要使用不同的主题。
2、消息业务是否关联：如果业务没有直接关联，比如，淘宝交易消息和盒马物理消息没有业务交集，需要使用不同的消息主题；同样是淘宝交易消息，女装类订单和男装类订单可以使用同一个订单。当然，如果业务量较大或其他子模块应用处理业务时需要进一步拆分订单类型，也可以将男装订单和女装订单的消息拆分到两个主题中。
3、消息量级是否一样：数量级不同或时效性不同的业务消息建议使用不同的主题，例如某些业务消息量很小但是时效性要求高的，如果跟某些万亿级消息量的业务使用同一个主题，会增加消息的等待时长。
正确拆分实例：线上商品购买场景下，订单交易如订单创建、支付、取消等流程消息使用同一个主题，物流相关消息使用一个主题，积分管理相关使用一个主题。
错误拆分示例：
1、拆分粒度过粗：会导致业务隔离性差，不利于独立运维和故障处理。例如，所有交易消息和物流消息都共用一个主题。
2、拆分粒度过细：会消耗大量主题资源，造成系统负载过重。例如，按照用户ID区分，每个用户ID使用一个主题。
单一主题只收发一种类型消息，避免混用
Apache RocketMQ 主题的设计原则为通过主题隔离业务，不同业务逻辑的消息建议使用不同的主题。同一业务逻辑消息的类型都相同，因此，对于指定主题，应该只收发同一种类型的消息。
主题管理尽量避免自动化机制
在Apache RocketMQ 架构中，主题属于顶层资源和容器，拥有独立的权限管理、可观测性指标采集和监控等能力，创建和管理主题会占用一定的系统资源。因此，生产环境需要严格管理主题资源，请勿随笔进行增删改查操作。
Apache RocketMQ 虽然提供了自动创建主题的功能，但是建议仅在测试环境使用，生产环境勿用，避免产生大量垃圾啊主题，无法管理和回收并浪费系统资源。
3 队列（MessageQueue）
本节介绍Apache RocketMQ队列的定义、模型关系、内部属性、版本兼容及使用建议。
3.1 定义
队列是Apache RocketMQ 中消息存储和传输的实际容器，也是Apache RocketMQ消息的最小存储单元。Apache RocketMQ的所有主题都是由多个队列组成，以此实现队列数量的水平拆分和队列内部的流式存储。
队列的主要作用如下：
1、存储顺序性：
队列天然具备顺序性，即消息按照进入队列的顺序写入存储，同一队列间的消息天然存在顺序关系，队列头部为最早写入的消息，队列尾部为最后写入的消息。消息在队列中的位置和消息之间的顺序通过位点（Offset）进行标记管理。
2、流式操作语义：
Apache RocketMQ 基于队列的存储模型可确保消息从任意位点读取任意数量的消息，以此实现类似聚合读取、回溯读取等特性，这些特点是RabbitMQ、ActiveMQ等非队列存储模型不具备的。
3.2 模型关系
在整个Apache RocketMQ的领域模型中，队列所处的流程和位置如下：
Apache RocketMQ 默认提供消息可靠存储机制，所有发送成功的消息都被持久化存储到队列中，配合生产者和消费者客户端的调用可实现至少投递一次的可靠性语义。
Apache RocketMQ 队列模型和Kafka的分区模型类型。在Apache RocketMQ消息收发模型中，队列属于主题的一部分，虽然所有的消息资源以主题粒度管理，但实际的操作实现是面向队列。例如，生产者执行某个主题，向主题内发送消息，但实际消息发送到该主题下的某个队列中。
Apache RocketMQ 中通过修改队列数量，以此实现横向的水平扩容和缩容。
3.3 内部属性
读写权限
定义：当前队列是否可以读写数据。
取值：由服务端定义，枚举值如下：
6：读写状态，当前队列允许读取消息和写入消息。
4：只读状态，当前队列只允许读取消息，不允许写入消息。
2：只写状态，当前队列只允许写入消息，不允许读取消息。
0：不可读写状态：当前队列不允许读取和写入消息。
约束：队列的读写权限属于运维侧操作，不建议频繁修改。
3.4 行为约束
每个主题下会由一个到多个队列来存储消息，每个主题对应的队列数量与消息类型以及实例所处地域相关。
3.5 版本兼容性
队列的名称属于在Apache RocketMQ服务端的不同版本中有如下差异：
1、服务端3.x/4.x版本：队列名称由：主题名称+brokenID+QueueID 组成，和物理节点绑定。
2、服务端5.x版本：队列名称为一个集群分配的全局同一的字符串组成，和物理节点解耦。
因此，在开发过程中，建议不要对队列名称做任何假设和绑定。如果在代码中自定义拼接队列名称并和其他操作绑定，一旦服务端版本升级，可能会出现队列名称无法解析的兼容性问题。
3.6 使用建议
按照实际业务消耗设置队列数
Apache RocketMQ 的队列数可以在创建主题或 变更主题时设置修改，队列的数量设置应遵循少用够用原则，避免随机增加队列数量。
主题内部队列数过多可能会导致如下问题：
1、集群元数据膨胀
Apache RocketMQ会以队列粒度采集指标和监控数据，队列过多容易造成管控元数据膨胀。
2、客户端压力过大
Apache RocketMQ的消息读写都是在很对队列进行操作，队列过多对应更多的轮询请求，增加系统负荷。
4 消息（Message）
本节介绍Apache RocketMQ 中消息的定义、模型关系、内部属性、行为约束及使用建议。
4.1 定义
消息时Apache RocketMQ中最小的数据传输单元。生产者将业务数据的负载和扩展属性包装成消息发送到Apache RocketMQ服务端，服务端按照相关语义将消息投递到消费端进行消费。
Apache RocketMQ的消息模型具有如下特点：
1、消息不可变性
消息本质上是已经产生并确定的事件，一旦产生后，消息的内容不会发生改变。即使经过传输链路的控制也不会发生变化，消费端获取的消息都是只读消息视图。
2、消息持久化
Apache RocketMQ 会默认对消息进行持久化，即将接收到的消息存储到Apache RocketMQ服务端的存储文件中，保证消息的可回溯性和系统故障场景下的可恢复性。
4.2 模型关系
在整个Apache RocketMQ的领域模型中，消息所处的流程和位置如下：
1、消息由生产者初始化并发送到Apache RocketMQ服务端。
2、消息按照到达Apache RocketMQ服务端的顺序存储到队列中。
3、消费者按照指定的订阅关系从Apache RocketMQ服务端中获取消息并消费。
4.3 消息内部属性
系统保留属性
主题名称
定义：当前消息所属的主题的名称。集群内全局唯一。
取值：从客户端SDK接口获取。
消息类型
定义：当前消息的类型。
取值：从客户端SDK接口获取。Apache RocketMQ支持的消息类型如下：
1、Normal：普通消息，消息本身无特殊语义，消息之间也没有任何关联。
2、FIFO：顺序消息，Apache RocketMQ通过消息分组MessageGroup标记一组特定消息的先后顺序，可以保证消息的投递顺序严格按照消息发送时的顺序。
3、Delay：定时/延时消息，通过执行延时时间控制消息生产后不会立即投递，而在是延时间隔后才对消费者可见。
4、Transaction：事务消息，Apache RocketMQ 支持分布式事务消息，支持应用数据库更新和消息调用的事务一致性保障。
消息队列
定义：实际存储当前消息的队列。
取值：由服务端指定并填充。
消息位点
定义：当前消息存储在队列中的位置。
取值：由服务端指定并填充。取值范围：0~long.Max。
消息ID
定义：消息的唯一标识，集群内每条消息的ID全局唯一。
取值：生产者客户端系统自动生成。固定为数字和大写字母组成的32位字符串。
索引Key列表（可选）
定义：消息的索引键，可通过设置不同的Key区分消息和快速查找消息。
取值：由生产者客户端定义。
过滤标签Tag（可选）
定义：消息的过滤标签。消费者可通过Tag对消息进行过滤，仅接收指定标签的消息。
取值：由生产者客户端定义。
约束：一条消息仅支持设置一个标签。
定时时间（可选）
定义：定时场景下，消息触发延时投递的毫秒级时间戳。
取值：由消息生产者定义。
约束：最大可设置定时时长40天。
消费发送时间
定义：消息发送时，生产者客户端系统的本地毫秒级时间戳。
取值：由生产者客户端系统填充。
说明：客户端系统时钟和服务端系统时钟可能存在偏差，消息发送时间是以客户端系统时钟为准。
消息保存时间戳
定义：消息在Apache RocketMQ服务端完成存储时， 服务端系统的本地毫秒级时间戳。 对于定时消息和事务消息，消息保存时间指的是消息生效对消费方可见的服务端系统时间。
取值：由服务端系统填充。
说明：客户端系统时钟和服务端系统时钟可能存在偏差，消息保留时间是以服务端系统时钟为准。
消费重试次数
定义：消息消费失败后，Apache RocketMQ 服务端重新投递的次数。每次重试后，重试次数加1。
取值：由服务端系统标记。首次消费，重试次数为0；消费失败首次重试时，重试次数为1。
业务自定义属性
定义：生产者可以自定义设置的扩展信息。
取值：由消息生产者自定义，按照字符串键值对设置。
消息负载
定义：业务消息的实际报文数据。
取值：由生产者负责序列化编码，按照二进制字节传输。
4.4 行为约束
消息大小不得超过其类型所对应的限制，否则消息会发送失败。
系统默认的消息最大限制如下：
普通和顺序消息：4 MB
事务和定时或延时消息：64 KB
4.5 使用建议
单条消息不建议传输超大负载
作为一款消息中间件产品，Apache RocketMQ一般传输的都是业务事件数据。单个单子消息事件的数据大小需要严格可能控制，如果单条消息过大容易造成网络传输层压力，不利于异常重试和流量控制。
生产环境中如果需要传输超大负载，建议按照固定大小做报文拆分，或者结合文件存储等方法进行传输。
消息中转时做好不可变设计
Apache RocketMQ服务端5.x版本中，消息本身不可编辑，消费端获取的消息都是只读消息视图。
原文地址:https://blog.csdn.net/geminigoth/article/details/136044300
本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若转载，请注明出处：http://www.7code.cn/show_66575.html
如若内容造成侵权/违法违规/事实不符，请联系代码007邮箱：suwngjj01@126.com进行投诉反馈，一经查实，立即删除！
