目录
序
概念简述
一、客户端概念
1. Topic-主题
2.ConsumerGroup(消费者组)
概念一览图
二、消息传输模型
三、实践应用
1.配置文件
2.生产者
3.消费者
配置一览图
最后的话
序
接上一篇对rabbitMQ队列进行了梳理 《一文搞懂rabbitMQ消息队列概述》。
本篇对另一种消息队列rocketMQ进行概述理解。
注:本文依据当前最新版本5.x为基础展开
概念简述
分为三个方面进行分析理解:
- 客户端概念
- 消息传输模型
- 实践应用
一、客户端概念
1. Topic-主题
主题是RocketMQ消息传输和存储的顶层容器,标识同一类业务消息逻辑数据。只是一个逻辑容器,并不是实际的消息容器。
messageType(消息类型):控制台创建主题时,需要设置一种消息类型,后续向该主题传输消息,该主题只会接收对应的消息类型,不匹配的则会直接拒绝接收。
- Normal(普通消息):没有特殊语义,消息自己没有任何关联
- FIFO(顺序消息):MQ通过消息分组messageGroup标记一组特定消息的先后顺序,可以保证消息的投递顺序可以严格按照消息的发送顺序进行投递。
- Delay(定时/延时消息):通过设置延时时间控制消息生产后不立即投递,而是等延时间隔时间后对消费者可见。
- Transaction(事务消息):rocketMQ支持分布式事务,支持应用数据库消息和消息回调事务一致性保障。
queue(队列):控制台创建主题时,需要设置主题的队列数量,不用单独创建队列,MQ服务器会自动创建。抛开不同服务商的实现,对于队列本身来说,单个queue 具有自然顺序性;
注1:对于RocketMQ的队列,还具备一个独一无二的的特性,流式操作语义:队列的存储模型可确保消息从任意位点(offset)读取任意数量的消息,以此实现类似聚合读取、回溯读取等特性。
2.ConsumerGroup(消费者组)
概念:是Apache RocketMQ中存在多个消费行为一直的消费者负载均衡分组。
投递顺序性:控制台创建消费者分组时,需要设置一种消费者投递的顺序。
- 顺序投递:消费顺序和发送顺序完全一致。
- 并发投递:并发消费,尽可能按时间顺序处理。
注2:按消费者是否设置消费者组,对于投递顺序性有不同的特性,详细可参考RocketMQ官网消费者组详解
消费重试策略:控制台创建消费者分组时设置。保证消费者消费消息异常或失败后出去的重试策略。
- 重试次数
- 死信队列设置
- 重试时间间隔
- ...
注3:根据消费者类型不同,重试触发时机存在差异
(1)PushConsumer:异常时返回失败状态码,立即重试
(2)SimpleConsumer:静默等待超时,服务器自动重试
注4:建议通过减少重试次数+延长重试间隔来降低系统压力,避免出现无限重试或大量重试的情况。
在控制台中 topic主题 与 consumerGroup消费者组 没有直接的关联
概念一览图
二、消息传输模型
MQ的消息传输模型大致分为两类:点对点消息模型、发布/订阅消息模型
Apache RocketMQ只支持一种消息模型:发布/订阅消息模型
注5:Apache RabbitMQ两种消息传输模型都支持
三、实践应用
1.配置文件
- nameServer:服务器地址(控制台获取)
- AccessKey(控制台获取)
- SecretKey(控制台)
- producer groupId(客户端自定义设置)
2.生产者
- topic:主题(控制台获取)
- messageKey:消息唯一索引键(客户端自定义设置)
- messageBody:消息内容体(客户端自定义设置)
- messageTag:消息过滤标签(客户端自定义设置)
3.消费者
- topic:主题(控制台获取)
- consumerGroup:消费者组(控制台获取)
- messageTag:消息过滤标签(客户端自定义设置,与生产者过滤标签对应)
消费者订阅关系
上面说到控制台topic与consumerGroup没有直接的关联,其实是在客户端通过消费者产生的联系。
项目中集成RocketMQ可参考: springboot 整合 腾讯云RocketMq版消息队列服务
配置一览图
最后的话
至此rocketMQ的基本概念大致清楚了,但是想要生产运用不仅仅止步于表面,自己更需要去深耕框架底层的逻辑实现,才能真正掌握并达到事半功倍的效果。
行动起来