任何查询网站有没有做404,购物网站建设论文,wordpress分享到朋友圈,閪是什么意思教程#xff1a;基本概念 | RocketMQ
视频教程
https://www.bilibili.com/video/BV1d5411y7UW?vd_sourcef1bd3b5218c30adf0a002c8c937e0a27
版本#xff1a;5.0
一 基本概念
1.1 生产者/Producer
1.1.1 定义 消息发布者。是构建并传输消息到服务端的运行实体。…教程基本概念 | RocketMQ
视频教程
https://www.bilibili.com/video/BV1d5411y7UW?vd_sourcef1bd3b5218c30adf0a002c8c937e0a27
版本5.0
一 基本概念
1.1 生产者/Producer
1.1.1 定义 消息发布者。是构建并传输消息到服务端的运行实体。 生产者通常被集成在业务系统中将业务消息按照要求封装成消息(Message)并发送至服务端 传输行为: 发送方式生产者可通过API接口设置消息发送的方式。Apache RocketMQ 支持同步传输和异步传输。 批量发送生产者可通过API接口设置消息批量传输的方式。例如批量发送的消息条数或消息大小。 事务行为Apache RocketMQ 支持事务消息对于事务消息需要生产者配合进行事务检查等行为保障事务的最终一致性。详见事务消息Transaction。 生产者和主题的关系为多对多关系即同一个生产者可以向多个主题发送消息对于平台类场景如果需要发送消息到多个主题并不需要创建多个生产者同一个主题也可以接收多个生产者的消息以此可以实现生产者性能的水平扩展和容灾。 1.1.2 模型关系 消息由生产者Producer初始化并发送到Apache RocketMQ 服务端。 消息按照到达Apache RocketMQ 服务端的顺序存储到主题(Topic)的指定队列(MessageQueue)中。 消费者(Consumer)按照指定的订阅关系从Apache RocketMQ 服务端中获取消息并消费。
1.1.3 内部属性
客户端ID 定义生产者客户端的标识用于区分不同的生产者。集群内全局唯一。 取值客户端ID由Apache RocketMQ 的SDK自动生成主要用于日志查看、问题定位等运维场景不支持修改。
通信参数
接入点信息 必选 连接服务端的接入地址用于识别服务端集群。 接入点必须按格式配置建议使用域名避免使用IP地址防止节点变更无法进行热点迁移。身份认证信息 可选 客户端用于身份验证的凭证信息。 仅在服务端开启身份识别和认证时需要传输。请求超时时间 可选 客户端网络请求调用的超时时间。取值范围和默认值参考系统说明规范系统设置。
预绑定主题列表
事务检查器
发送重试策略
1.1.4 使用建议
不建议单一进程创建大量生产者
生产者Producer和主题Topic是多对多的关系支持同一个生产者向多个主题(Topic)发送消息Message。对于生产者Producer的创建和初始化建议遵循够用即可、最大化复用原则如果有需要发送消息Message到多个主题Topic的场景无需为每个主题Topic都创建一个生产者Producer。
不建议频繁创建和销毁生产者
生产者Producer是可以重复利用的底层资源类似数据库的连接池。因此不需要在每次发送消息Message时动态创建生产者Producer且在发送结束后销毁生产者。这样频繁的创建销毁会在服务端产生大量短连接请求严重影响系统性能。 1.2 主题/Topic
1.2.1 定义 Topic是消息传输和存储的顶层容器用于标识同一类业务逻辑的信息。 为逻辑概念非实体的消息容器。 定义数据的分类隔离 在 Apache RocketMQ 的方案设计中建议将不同业务类型的数据拆分到不同的主题中管理通过主题实现存储的隔离性和订阅隔离性。 定义数据的身份和权限 Apache RocketMQ 的消息本身是匿名无身份的同一分类的消息使用相同的主题来做身份识别和权限管理。
1.2.2 模型关系 主题是 Apache RocketMQ 的顶层存储所有消息资源的定义都在主题内部完成但主题是一个逻辑概念并不是实际的消息容器。 主题内部由多个队列组成消息的存储和水平扩展能力最终是由队列实现的并且针对主题的所有约束和属性设置最终也是通过主题内部的队列来实现。
1.2.3 内部属性
主题名称
定义主题的名称用于标识主题主题名称集群内全局唯一。
取值由用户创建主题时定义。
约束参考系统说明规范系统设置。
队列列表
定义队列MessageQueue作为主题的组成单元是消息存储的实际容器一个主题内包含一个或多个队列消息实际存储在主题的各队列内。
取值系统根据队列数量给主题分配队列队列数量创建主题时定义。
约束一个主题内至少包含一个队列。
消息类型
定义主题所支持的消息类型
取值创建主题时选择消息类型。包括Normal普通消息、FIFO顺序消息、Delay定时/延时消息、Transaction事务消息。
约束Apache RocketMQ 从5.0版本开始支持强制校验消息类型即每个主题只允许发送一种消息类型的消息这样可以更好的运维和管理生产系统避免混乱。为保证向下兼容4.x版本行为强制校验功能默认开启。
1.2.4 行为约束
消息类型强制校验 Apache RocketMQ 5.x版本支持将消息类型拆分到主题中进行独立运维和处理因此系统会对发送的消息类型和主题定的消息类型进行强制校验若校验不通过则消息发送请求会被拒绝并返回类型不匹配异常。校验原则如下 消息类型必须一致发送的消息的类型必须和目标主题定义的消息类型一致。 主题类型必须单一每个主题只支持一种消息类型不允许将多种类型的消息发送到同一个主题中。 为保证向下兼容4.x版本行为上述强制校验功能默认开启。
常见错误使用场景 发送的消息类型不匹配例如创建主题时消息类型定义为顺序消息发送消息时发送事务消息到该主题中此时消息发送请求会被拒绝并返回类型不匹配异常。 单一消息主题混用例如创建主题时消息类型定义为普通消息发送消息时同时发送普通消息和顺序消息到该主题中则顺序消息的发送请求会被拒绝并返回类型不匹配异常。
1.2.5 使用建议
按照业务分类合理拆分主题
主题拆分设计应遵循大类统一原则即将相同业务域内同一功能属性的消息划分为同一主题。 消息类型是否一致不同类型的消息如顺序消息和普通消息需要使用不同的主题。 消息业务是否关联如果业务没有直接关联。比如淘宝交易消息和盒马物流消息没有业务交集需要使用不同的消息主题同样是淘宝交易消息女装类订单和男装类订单可以使用同一个订单。当然如果业务量较大或其他子模块应用处理业务时需要进一步拆分订单类型您也可以将男装订单和女装订单的消息拆分到两个主题中。 消息量级是否一样数量级不同或时效性不同的业务消息建议使用不同的主题。例如某些业务消息量很小但是时效性要求很强。如果跟某些万亿级消息量的业务使用同一个主题会增加消息的等待时长。 正确拆分示例 线上商品购买场景下
订单交易如订单创建、支付、取消等流程消息使用一个主题。
物流相关消息使用一个主题。
积分管理相关消息使用一个主题。错误拆分示例拆分粒度过粗会导致业务隔离性差不利于独立运维和故障处理。例如所有交易消息和物流消息都共用一个主题。拆分粒度过细会消耗大量主题资源造成系统负载过重。例如按照用户ID区分每个用户ID使用一个主题。 单一主题只收发一种类型消息避免混用 主题的设计原则为通过主题隔离业务不同业务逻辑的消息建议使用不同的主题。同一业务逻辑消息的类型都相同因此对于指定主题应该只收发同一种类型的消息。
主题管理尽量避免自动化机制 主题属于顶层资源和容器拥有独立的权限管理、可观测性指标采集和监控等能力创建和管理主题会占用一定的系统资源。因此生产环境需要严格管理主题资源请勿随意进行增、删、改、查操作。 虽然提供了自动创建主题的功能但是建议仅在测试环境使用生产环境请勿打开避免产生大量垃圾主题无法管理和回收并浪费系统资源。
1.3 消息/Message
1.3.1 定义 消息是 Apache RocketMQ 中的最小数据传输单元。生产者Producer将业务数据的负载和拓展属性包装成消息Message发送到服务端服务端按照相关语义将消息投递到消费端进行消费。 消息不可变性 消息Message本质上是已经产生并确定的事件一旦产生后消息的内容不会发生改变。即使经过传输链路的控制也不会发生变化消费端获取的消息都是只读消息视图。 消息持久化 默认对消息进行持久化即将接收到的消息Message存储到 Apache RocketMQ 服务端的存储文件中保证消息的可回溯性和系统故障场景下的可恢复性。
1.3.2 模型关系
消息所处的流程和位置如下 消息Message由生产者(Prpducer)初始化并发送到Apache RocketMQ 服务端。 消息Message按照到达Apache RocketMQ 服务端的顺序存储到队列MessageQueue中。 消费者Consumer按照指定的订阅关系从Apache RocketMQ 服务端中获取消息Message并消费。
1.3.3 消息内部属性
系统保留属性
主题名称 定义当前消息所属的主题Topic的名称。集群内全局唯一。 取值从客户端SDK接口获取。
消息类型 定义当前消息的类型。 取值从客户端SDK接口获取。参考1.2.3 消息类型
消息队列 定义实际存储当前消息的队列。详见1.4。 取值由服务端指定并填充。
消息位点 定义当前消息存储在队列中的位置。详见 消息进度管理。 取值由服务端指定并填充。取值范围0~long.Max。
消息ID 定义消息的唯一标识集群内每条消息的ID全局唯一。 取值生产者客户端系统自动生成。固定为数字和大写字母组成的32位字符串。
索引Key列表可选 定义消息的索引键可通过设置不同的Key区分消息和快速查找消息。 取值由生产者客户端定义。
过滤标签Tag可选 定义消息的过滤标签。消费者可通过Tag对消息进行过滤仅接收指定标签的消息。 取值由生产者客户端定义。 约束一条消息仅支持设置一个标签。
定时时间可选 定义定时场景下消息触发延时投递的毫秒级时间戳。更多信息详见 消息模型 定时/延时消息。 取值由消息生产者定义。 约束最大可设置定时时长为40天。
消息发送时间 定义消息发送时生产者客户端系统的本地毫秒级时间戳。 取值由生产者客户端系统填充。 说明客户端系统时钟和服务端系统时钟可能存在偏差消息发送时间是以客户端系统时钟为准。
消息保存时间戳
定义消息在Apache RocketMQ 服务端完成存储时服务端系统的本地毫秒级时间戳。 对于定时消息和事务消息消息保存时间指的是消息生效对消费方可见的服务端系统时间。 取值由服务端系统填充。 说明客户端系统时钟和服务端系统时钟可能存在偏差消息保留时间是以服务端系统时钟为准。
消费重试次数 定义消息消费失败后Apache RocketMQ 服务端重新投递的次数。每次重试后重试次数加1。更多信息、详见1.11。 取值由服务端系统标记。首次消费重试次数为0消费失败首次重试时重试次数为1。
业务自定义属性 定义生产者可以自定义设置的扩展信息。 取值由消息生产者自定义按照字符串键值对设置。
消息负载 定义业务消息的实际报文数据。 取值由生产者负责序列化编码按照二进制字节传输。 约束详见 三 系统说明规范系统设置。
1.3.4 行为约束 消息大小不得超过其类型所对应的限制否则消息会发送失败。
系统默认的消息最大限制如下 普通和顺序消息4 MB 事务和定时或延时消息64 KB
1.3.4 使用建议
单条消息不建议传输超大负载 作为一款消息中间件产品Apache RocketMQ 一般传输的是都是业务事件数据。单个原子消息事件的数据大小需要严格控制如果单条消息过大容易造成网络传输层压力不利于异常重试和流量控制。 生产环境中如果需要传输超大负载建议按照固定大小做报文拆分或者结合文件存储等方法进行传输。
消息中转时做好不可变设计 Apache RocketMQ 服务端5.x版本中消息本身不可编辑消费端获取的消息都是只读消息视图。 但在历史版本3.x和4.x版本中消息不可变性没有强约束因此如果您需要在使用过程中对消息进行中转操作务必将消息重新初始化。 1.4 消息队列/MessageQueue 消息存储和传输的实际容器也是消息的最小存储单元。
1.4.1 定义 队列MessageQueue是 Apache RocketMQ 中消息存储和传输的实际容器也是 Apache RocketMQ 消息的最小存储单元。 Apache RocketMQ 的所有主题Topic都是由多个队列MessageQueue组成以此实现队列数量的水平拆分和队列内部的流式存储。
队列的主要作用如下 存储顺序性 队列天然具备顺序性即消息按照进入队列的顺序写入存储同一队列间的消息天然存在顺序关系队列头部为最早写入的消息队列尾部为最新写入的消息。消息在队列中的位置和消息之间的顺序通过位点Offset进行标记管理。 流式操作语义 Apache RocketMQ 基于队列的存储模型可确保消息从任意位点读取任意数量的消息以此实现类似聚合读取、回溯读取等特性这些特性是RabbitMQ、ActiveMQ等非队列存储模型不具备的。
1.4.2 模型关系 Apache RocketMQ 默认提供消息可靠存储机制所有发送成功的消息都被持久化存储到队列中配合生产者和消费者客户端的调用可实现至少投递一次的可靠性语义。 Apache RocketMQ 队列模型和Kafka的分区Partition模型类似。在 Apache RocketMQ 消息收发模型中队列属于主题的一部分虽然所有的消息资源以主题粒度管理但实际的操作实现是面向队列。 例如生产者指定某个主题向主题内发送消息但实际消息发送到该主题下的某个队列中。 Apache RocketMQ 中通过修改队列数量以此实现横向的水平扩容和缩容。
1.4.3 内部属性
读写权限 定义当前队列是否可以读写数据。 取值由服务端定义枚举值如下 6读写状态当前队列允许读取消息和写入消息。 4只读状态当前队列只允许读取消息不允许写入消息。 2只写状态当前队列只允许写入消息不允许读取消息。 0不可读写状态当前队列不允许读取消息和写入消息。
约束队列的读写权限属于运维侧操作不建议频繁修改。
1.4.4 行为约束 每个主题Topic下会由一到多个队列MessageQueue来存储消息每个主题对应的队列数与消息类型以及实例所处地域Region相关。
1.4.5 使用建议
按照实际业务消耗设置队列数 Apache RocketMQ 的队列数可在创建主题或变更主题时设置修改队列数量的设置应遵循少用够用原则避免随意增加队列数量。
主题内队列数过多可能对导致如下问题 集群元数据膨胀 Apache RocketMQ 会以队列粒度采集指标和监控数据队列过多容易造成管控元数据膨胀。 客户端压力过大 Apache RocketMQ 的消息读写都是针对队列进行操作队列过多对应更多的轮询请求增加系统负荷。
常见队列增加场景 需要增加队列实现物理节点负载均衡 Apache RocketMQ 每个主题的多个队列可以分布在不同的服务节点上在集群水平扩容增加节点后为了保证集群流量的负载均衡建议在新的服务节点上新增队列或将旧的队列迁移到新的服务节点上。 需要增加队列实现顺序消息性能扩展 在 Apache RocketMQ 服务端4.x版本中顺序消息的顺序性在队列内生效的因此顺序消息的并发度会在一定程度上受队列数量的影响因此建议仅在系统性能瓶颈时再增加队列。
1.5 消费者/Consumer 消息订阅者是用来接受并处理消息的运行实体。
1.5.1 定义 消费者是 Apache RocketMQ 中用来接收并处理消息的运行实体。 消费者通常被集成在业务系统中从 Apache RocketMQ 服务端获取消息并将消息转化成业务可理解的信息供业务逻辑处理。
在消息消费端可以定义如下传输行为 消费者身份消费者必须关联一个指定的消费者分组以获取分组内统一定义的行为配置和消费状态。 消费者类型Apache RocketMQ 面向不同的开发场景提供了多样的消费者类型包括PushConsumer类型、SimpleConsumer类型、PullConsumer类型仅推荐流处理场景使用等。具体信息详见消费者分类。 消费者本地运行配置消费者根据不同的消费者类型控制消费者客户端本地的运行配置。例如消费者客户端的线程数消费并发度等实现不同的传输效果。
1.5.2 模型关系
消息由生产者初始化并发送到Apache RocketMQ 服务端。 消息按照到达Apache RocketMQ 服务端的顺序存储到主题的指定队列中。 消费者按照指定的订阅关系从Apache RocketMQ 服务端中获取消息并消费。
1.5.3 内部属性
消费者分组名称 定义当前消费者关联的消费者分组名称消费者必须关联到指定的消费者分组通过消费者分组获取消费行为。更多信息详见1.6。 取值消费者分组为Apache RocketMQ 的逻辑资源需要您提前通过控制台或OpenAPI创建。具体命名格式详见 三 系统说明规范系统设置。
客户端ID 定义消费者客户端的标识用于区分不同的消费者。集群内全局唯一。 取值客户端ID由Apache RocketMQ 的SDK自动生成主要用于日志查看、问题定位等运维场景不支持修改。
通信参数
接入点信息 必选 连接服务端的接入地址用于识别服务端集群。 接入点必须按格式配置建议使用域名避免使用IP地址防止节点变更无法进行热点迁移。身份认证信息 可选 客户端用于身份验证的凭证信息。 仅在服务端开启身份识别和认证时需要传输。请求超时时间 可选 客户端网络请求调用的超时时间。取值范围和默认值详见 三 系统说明规范系统设置。
预绑定订阅关系列表
定义指定消费者的订阅关系列表。 Apache RocketMQ 服务端可在消费者初始化阶段根据预绑定的订阅关系列表对目标主题进行权限及合法性校验无需等到应用启动后才能校验。
取值建议在消费者初始化阶段明确订阅关系即要订阅的主题列表若未设置或订阅的主题动态变更Apache RocketMQ 会对目标主题进行动态补充校验。
消费监听器 定义Apache RocketMQ 服务端将消息推送给消费者后消费者调用消息消费逻辑的监听器。 取值由消费者客户端本地配置。 约束使用PushConsumer类型的消费者消费消息时消费者客户端必须设置消费监听器。消费者类型的具体信息详见 消费者分类。
1.5.4 行为约束 在 Apache RocketMQ 领域模型中消费者的管理通过消费者分组实现同一分组内的消费者共同分摊消息进行消费。因此为了保证分组内消息的正常负载和消费 Apache RocketMQ 要求同一分组下的所有消费者以下消费行为保持一致 投递顺序 消费重试策略
1.5.5 使用建议
不建议在单一进程内创建大量消费者 Apache RocketMQ 的消费者在通信协议层面支持非阻塞传输模式网络通信效率较高并且支持多线程并发访问。因此大部分场景下单一进程内同一个消费分组只需要初始化唯一的一个消费者即可开发过程中应避免以相同的配置初始化多个消费者。
不建议频繁创建和销毁消费者 Apache RocketMQ 的消费者是可以重复利用的底层资源类似数据库的连接池。因此不需要在每次接收消息时动态创建消费者且在消费完成后销毁消费者。这样频繁地创建销毁会在服务端产生大量短连接请求严重影响系统性能。
1.6 消费者组/ConsumerGroup
1.6.1 定义 消费者分组是 Apache RocketMQ 系统中承载多个消费行为一致的消费者的负载均衡分组。 和消费者不同消费者分组并不是运行实体而是一个逻辑资源。在 Apache RocketMQ 中通过消费者分组内初始化多个消费者实现消费性能的水平扩展以及高可用容灾。 在消费者分组中统一定义以下消费行为同一分组下的多个消费者将按照分组内统一的消费行为和负载均衡策略消费消息。 订阅关系Apache RocketMQ 以消费者分组的粒度管理订阅关系实现订阅关系的管理和追溯。具体信息详见 六 订阅关系 投递顺序性Apache RocketMQ 的服务端将消息投递给消费者消费时支持顺序投递和并发投递投递方式在消费者分组中统一配置。具体信息详见 四消息模式 顺序消息 消费重试策略 消费者消费消息失败时的重试策略包括重试次数、死信队列设置等。具体信息详见消息重试。
1.6.2 模型关系
消息由生产者初始化并发送到Apache RocketMQ 服务端。 消息按照到达Apache RocketMQ 服务端的顺序存储到主题的指定队列中。 消费者按照指定的订阅关系从Apache RocketMQ 服务端中获取消息并消费。
1.6.3 内部属性
消费者分组名称 定义消费者分组的名称用于区分不同的消费者分组。集群内全局唯一。 取值消费者分组由用户设置并创建。具体命名规范详见 三 系统说明给范系统设置。
投递顺序性 定义消费者消费消息时Apache RocketMQ 向消费者客户端投递消息的顺序。 根据不同的消费场景Apache RocketMQ 提供顺序投递和并发投递两种方式。具体信息详见 四 消息模式 顺序消息。 取值默认投递方式为并发投递。
消费重试策略 定义消费者消费消息失败时系统的重试策略。消费者消费消息失败时系统会按照重试策略将指定消息投递给消费者重新消费。具体信息详见 消息重试。 取值重试策略包括 最大重试次数表示消息可以重新被投递的最大次数超过最大重试次数还没被成功消费消息将被投递至死信队列或丢弃。 重试间隔Apache RocketMQ 服务端重新投递消息的间隔时间。 最大重试次数和重试间隔的取值范围及默认值详见 三 系统说明给范系统设置。 约束重试间隔仅在PushConsumer消费类型下有效。
订阅关系
定义当前消费者分组关联的订阅关系集合。包括消费者订阅的主题以及消息的过滤规则等。订阅关系由消费者动态注册到消费者分组中Apache RocketMQ 服务端会持久化订阅关系并匹配消息的消费进度。更多信息详见 订阅关系。
1.6.4 行为约束 在 Apache RocketMQ 领域模型中消费者的管理通过消费者分组实现同一分组内的消费者共同分摊消息进行消费。因此为了保证分组内消息的正常负载和消费 Apache RocketMQ 要求同一分组下的所有消费者以下消费行为保持一致 投递顺序 消费重试策略
1.6.5 使用建议
按照业务合理拆分分组 Apache RocketMQ 的消费者和主题是多对多的关系对于消费者分组的拆分设计建议遵循以下原则 消费者的投递顺序一致同一消费者分组下所有消费者的消费投递顺序是相同的统一都是顺序投递或并发投递不同业务场景不能混用消费者分组。 消费者业务类型一致一般消费者分组和主题对应不同业务域对消息消费的要求不同例如消息过滤属性、消费重试策略不同。因此不同业务域主题的消费建议使用不同的消费者分组避免一个消费者分组消费超过10个主题。
消费者分组管理尽量避免自动化机制 在 Apache RocketMQ 架构中消费分组属于状态管理类的逻辑资源每个消费分组都会涉及关联的消费状态、堆积信息、可观测指标和监控采集数据。因此生产环境需要严格管理消费者分组资源请勿随意进行增、删、改、查操作。
Apache RocketMQ 虽然提供了自动创建消费者分组的功能但是建议仅在测试环境使用生产环境请勿打开避免产生大量消费者分组无法管理和回收且浪费系统资源。
1.7 订阅关系
1.7.1 定义 订阅关系是 Apache RocketMQ 系统中消费者获取消息、处理消息的规则和状态配置。 订阅关系由消费者分组动态注册到服务端系统并在后续的消息传输中按照订阅关系定义的过滤规则进行消息匹配和消费进度维护。
通过配置订阅关系可控制如下传输行为 消息过滤规则用于控制消费者在消费消息时选择主题内的哪些消息进行消费设置消费过滤规则可以高效地过滤消费者需要的消息集合灵活根据不同的业务场景设置不同的消息接收范围。具体信息请参见消息过滤。 消费状态Apache RocketMQ 服务端默认提供订阅关系持久化的能力即消费者分组在服务端注册订阅关系后当消费者离线并再次上线后可以获取离线前的消费进度并继续消费。
1.7.2 订阅关系判断原则 Apache RocketMQ 的订阅关系按照消费者分组和主题粒度设计因此一个订阅关系指的是指定某个消费者分组对于某个主题的订阅判断原则如下 不同消费者分组对于同一个主题的订阅相互独立如下图所示消费者分组Group A和消费者分组Group B分别以不同的订阅关系订阅了同一个主题Topic A这两个订阅关系互相独立可以各自定义不受影响。 同一个消费者分组对于不同主题的订阅也相互独立如下图所示消费者分组Group A订阅了两个主题Topic A和Topic B对于Group A中的消费者来说订阅的Topic A为一个订阅关系订阅的Topic B为另外一个订阅关系且这两个订阅关系互相独立可以各自定义不受影响。 1.7.3 模型关系 消息由生产者初始化并发送到Apache RocketMQ 服务端。 消息按照到达Apache RocketMQ 服务端的顺序存储到主题的指定队列中。 消费者按照指定的订阅关系从Apache RocketMQ 服务端中获取消息并消费。
1.7.4 内部属性
过滤类型 定义消息过滤规则的类型。订阅关系中设置消息过滤规则后系统将按照过滤规则匹配主题中的消息只将符合条件的消息投递给消费者消费实现消息的再次分类。 取值 TAG过滤按照Tag字符串进行全文过滤匹配。 SQL92过滤按照SQL语法对消息属性进行过滤匹配。
过滤表达式 定义自定义的过滤规则表达式。 取值具体取值规范请参见过滤表达式语法规范。
1.7.5 行为约束
订阅关系一致
Apache RocketMQ 是按照消费者分组粒度管理订阅关系因此同一消费者分组内的消费者在消费逻辑上必须保持一致否则会出现消费冲突导致部分消息消费异常。 1.7.6 使用建议
建议不要频繁修改订阅关系 在 Apache RocketMQ 领域模型中订阅关系关联了过滤规则、消费进度等元数据和相关配置同时系统需要保证消费者分组下的所有消费者的消费行为、消费逻辑、负载策略等一致整体运算逻辑比较复杂。因此不建议在生产环境中通过频繁修改订阅关系来实现业务逻辑的变更这样可能会导致客户端一直处于负载均衡调整和变更的过程从而影响消息接收。
二 系统说明规范系统设置
参数约束和建议 | RocketMQ
三 消息传输过程
3.1 NameServer 可以理解为注册中心负责更新和发布Broker服务。在NameServer中的集群中NameServer和NameServer之间没有消息通讯无状态。
3.2 Broker 可以理解为消息中转角色负责消息的存储和转发接收生产者的消息并持久化消息。 消息发送到Broker时Broker会将消息转发到与之关联Topic中以便让更多的接收者进行处理。 启动时向nameserver注册信息包括ip、端口、主题Topic。 生产者和消费者都是与nameserver建立连接再通过对应的broker信息与borker链接。
四 调用命令
4.1 创建主题 sh mqadmin updateTopic -n nameserver_address -t topic_name -c cluster_name -a message.typemessage_type message_type根据消息类型设置成Normal/FIFO/Delay/Transaction。如果不设置默认为Normal类型。
