消息队列与RocketMQ总结
2024-08-30 22:37:34 0 举报AI智能生成
消息队列与RocketMQ总结，基于官方文档 5.0 进行整理
作者其他创作
大纲/内容
概述
消息只能被一个消费者消费一次
点对点模型
多个消费者可以重复消费消息
发布/订阅模型
消息模型
提高响应速度、吞吐量
异步
减少服务之间的依赖，提供系统稳定性和可拓展性
解耦
可以应对突发的流量冲击
削峰
使用场景
系统可用性降低、复杂性提高、可能有一致性问题
使用消息队列的问题
生产者可靠性
消费者可靠性
可靠性
基础
JMS与AMQP
RabbitMQ
Kafka
RocketMQ
常见消息队列
消息队列基础
Producer与Consumer
消息需要发送给交换器，由交换器将消息路由转发到不同的消息队列中
交换器
Exchange
用于存储消息
消息队列
Queue
Broker
RabbitMQ架构
消息队列数据处理日志收集
应用场景
生产者
Producer
消费者
Consumer
一个分区只能由消费者组消费，消费者组之间互不影响
消费者组
Consumer Group
相当于 Kafka 服务器实例
主题
Topic
一个 Topic 有多个 Partition，不同 Partition 可以分布到不同的 Broker 上
可以理解为消息队列
分区
Partition
副本数量
Replica
Kafka架构模型
发消息流程
发消息模型
一个 Topic 两个消费者组的例子
消费者与消费者组
新的消费者加入消费者组，或者有消费者宕机，就会造成分区的重新分配，这个就是重平衡
重平衡期间消费者都不能消费消息
分区重平衡
可能造成消费者来不及处理消息
Broker 给消费者推消息
Push 模式
更适合 Kafka，按照自己的节奏消费消息
消费者主动从 Broker 拉取消息
Pull 模式
Kafka消费模式
分区从不删除消息，除非消息到期
每个消费者组都会维护一个已经消费到消息的 offset
消费位置
消息消费顺序
offset 会存储在 Kafka 本地的一个 Topic 中
group + topic + partition 才能确定一个 offset
offset的维护
添加发送失败的回调方法，并在回调后重试
生产者丢失消息
关闭自动提交 offset 机制，消费完成后自己提交 offset
消费者丢失消息
设置好数据同步的参数
Kafka自身丢失消息
保证消息不丢失/可靠性
重复消费问题
保证幂等性
保证消息不被重复消费
常见消费问题解决
多副本机制
副本数据同步策略
Broker 注册
Topic 注册
负载均衡
使用 ZK 提供元数据管理功能
Kafka与Zookeeper
Kafka与文件系统
分为多个文件(Segment)顺序存储消息
底层存储细节
Kafka与存储实现
追加到文件末尾的顺序写更加高效
顺序写磁盘
消息可能被多个消费者组消费，采用零拷贝将消息从磁盘拷贝到页面缓冲区，然后直接发送到网络中
零拷贝技术
Kafka高效读写数据
生产者事务
消费者事务
Kafka事务
信息发送流程
不带回调函数的异步
带回调函数的异步
异步发送API
同步发送
同步发送API
生产者API
自动提交offset
同步提交commitSync offset
异步提交commitAsync offset
数据漏消费与重复消费分析
手动提交offset
自定义存储offset
消费者API
基本使用
基本概念与名词定义
分为三部分：消息生成、消息存储、消息消费
RocketMQ领域模型
同步RPC调用模型
异步通信模型
通信方式
RocketMQ就是此模型
发布订阅模型
消息传输模型
领域模型概述
基本架构
跟基本架构差不多，只不过各个组件基本都变成了分布式部署
集群架构
RocketMQ部署架构
Broker 就是消息服务器
Broker角色
Broker参数配置
master结点崩溃
一些salve结点崩溃
所有slave结点崩溃
Broker崩溃以后有什么影响?
最佳实践
Broker模型
RocketMQ 自研的注册中心，而非使用 ZK。它是去中心化的，没有主节点，彼此之间不会信息同步。单个 Broker 会和所有 NameServer 保持长连接
NameServer
用于标识同一类业务逻辑的消息
定义
定义与模型关系
主题名称
队列列表
每个主题只允许发送一种类型的消息。主题支持的消息类型：普通消息、顺序消息、延时消息、事务消息
消息类型
内部属性
行为约束
使用示例
将相同业务域内同一功能属性的消息划分为同一主题
信息类型是否一致
消息业务是否关联
消息量级是否一样
拆分方式
按照业务分类合理拆分主题
使用建议
存储顺序性、流式操作语义
队列的作用
RocketMQ 的队列与 Kafka 的 partition 模型类似
遵循少用够用原则
按照实际业务消耗设置队列数
需要增加队列实现物理节点负载均衡
常见需要队列增加场景
队列
消息不可变性
消息持久化
消息的特点
消息内部包含：主题名称、消息类型、消息队列、消息位点、消息ID、过滤标签 Tag、定时 时间、消费重试次数、消息负载等属性
单条消息不建议传输超大负载
消息中转时做好不可变设计
消息
生产者是 RocketMQ 系统中用来构建并传输消息到服务端的运行实体
生产者与主题关系为多对多
生产者内部包含：客户端ID、通信参数、发送重试策略等属性
不建议单一进程创建大量生产者
不建议频繁创建和销毁生产者
消费者分组是 RocketMQ 系统中承载多个消费行为一致的消费者的负载均衡分组。通过消费者分组内初始化多个消费者实现消费性能的水平扩展以及高可用容灾
订阅关系
投递顺序性
消费重试策略
消费行为
消费者组内部包含：订阅关系、投递顺序性、消费重试策略（最大重试次数、重试间隔）等参数
消费者投递顺序一致
消费者业务类型一致
按照业务合理拆分分组
消费者是 RocketMQ 中用来接收并处理消息的运行实体
不建议在单一进程内创建大量消费者
不建议频繁创建和销毁消费者
消息过滤规则
消费状态
订阅关系可以控制如下传输行为
一个订阅关系指的是指定某个消费者分组对于某个主题的订阅
不同消费者分组对于同一个主题的订阅相互独立
同一个消费者分组对于不同主题的订阅也相互独立
判断原则
订阅关系判断原则
内部包含属性有：过滤类型、过滤表达式
建议不要频繁修改订阅关系
在服务端视角看来一个 Group 下的所有 Consumer 都应该是相同的副本逻辑
正确订阅关系示例
订阅关系不一致的排查
常见订阅关系不一致问题
订阅关系一致
领域模型
初始化
待消费
消费中
消费提交
消息删除
普通消息生命周期
功能原理
微服务异步解耦
离线日志收集
数据集成传输
普通消息
服务端根据消息设置的定时时间在某一固定时刻将消息投递给消费者消费
定时消息精度为秒级
相比普通消息，多了一个【定时中】状态
生命周期
避免创建大量相同定时时刻的消息
分布式定时调度
比如订单超时未支付进行取消的场景
任务超时处理
定时延时消息
支持消费者按照发送消息的先后顺序获取消息
强调多条消息间的先后顺序关系
特点
可以使用 hash 法将同一个业务 ID 的消息发送到同一个队列中
顺序消息发送必须要设置消息组
生产顺序性
相同消息组的消息按照先后顺序被存储在同一个队列.
服务端存储逻辑
按照投递的顺序进行消费
消费顺序性
建议将业务以消息组粒度进行拆分
股票的撮合交易：先出价的先交易
数据实时增量同步
顺序消息
用于保障消息生产和本地事务的最终一致性
处理流程
生产者发送的是半消息
事务待提交
消息回滚
提交待消费
相比普通消息，多了事务待提交、消息回滚、提交待消费的状态
事务生命周期
消费事务性
中间状态可见性
使用限制
避免大量未决事务导致超时
需要正确处理\"进行中\"的事务
基于 RocketMQ 分布式事务消息: 支持最终一致性
分布式事务的诉求
事务消息
部分节点异常是否影响消息发送?请求重试是否会阻塞业务调用?请求重试会带来什么不足?
消息发送重试机制主要解答如下问题
重试基本概念
生产者初始化最大重试次数，后续发送消息失败会一直重试，直到最大次数
重试流程
可以配置退避策略
重试间隔
RocketMQ 客户端内置的发送请求重试机制并不能保证消息发送一定成功，业务方需要做好兜底
功能约束
消息发送重试机制
流控机制主要解答如下问题
存储压力大
消费者消费能力不足，大量消息堆积，超过一定数量触发流控
服务端请求任务排队溢出
触发条件
reply-code: 530 reply-text: TOO_MANY_REQUESTS
流控行为
通过监控避免触发流控
处理建议
消息流控机制
消息发送重试和流控机制
消费者处理消息时主要经过以下阶段: 消息获取->消息处理->消费状态提交。不同类型消费者处理方式有所不同
功能概述
基于 SDK 内部的典型 Reactor 线程模型实现
内部原理
使用方式
消息处理时间可预估场景
PushConsumer 严格限制了消息同步处理及每条消息的处理超时时间
适用场景
PushConsumer
消息处理时长不可控场景
需要自定义消费速率场景
SimpleConsumer
PullConsumer
消费者分类
比如交易系统会产生订单、支付、物流相关的消息。不同的业务线可以对消息进行过滤，只消费自己感兴趣的消息
服务端
消息过滤原理
支持 Tag 标签过滤和 SQL 属性过滤两种过滤方式
每条消息允许设置一个 Tag 标签
Tag 标签过滤为精准字符串匹配
Tag标签过滤
生产者为消息设置的属性(Key)及属性值(Value)进行匹配
SQL属性过滤
合理划分主题和Tag标签
消息过滤
消息消费处理的容灾策略
消息消费的顺序性机制
消息分配的水平拆分策略
可以解决的问题
消费组间广播消费
消费组内共享消费
广播消费和共享消费
广播消费场景下，消费者组中仅一个消费者，不涉及负载均衡
消息粒度负载均衡: PushConsumer 和 SimpleConsumer 默认负载策略
队列粒度负载均衡: PullConsumer 默认负载策略
分类
什么事消费者负载均衡
之前的版本都是队列粒度的负载均衡
消息粒度的负载均衡策略从 RocketMQ 服务端 5.0 版本开始支持
消费分摊更均衡
对非对等消费者更友好
队列分配运维更方便
策略特点（为什么变成5.0的默认负载均衡粒度？）
消息粒度负载均衡
使用范围：5.0 之前历史版本的消费者，默认都是队列粒度负载均衡
这里三个队列被分给两个消费者，所以有一个消费者被分配了两个队列的消息。如果队列数量小于消费者数量，则有的消费者无法绑定队列
策略原理
策略特点
队列粒度负载均衡
针对消费逻辑做消息幂等
消费者负载均衡
RocketMQ 的消费进度管理机制可以解答以下问题
消息位点(Offset)
消费位点(ConsumerOffset)
消费位点初始值
新创建的ConsumerGroup从哪里开始消费消息?
消费进度原理
初始消费位点不符合需求
下游来不及消费时，可以重置消费点位到最新的位置，就绕过此部分堆积的消息
消费堆积快速清理
业务执行异常，重置消费点位后重新消费消息，以纠正异常的业务
业务回溯，纠正处理
需要谨慎操作
重置消费位点(回溯消费)
限流降级
生产太快
看看是否是消费者出现大量消费错误，是否遇到线程卡死、资源死锁等
消费过慢
生产者生产太快或消费者消费太慢
解决方法：增加消费者
产生堆积的原因
消息堆积问题
消费进度管理
推荐场景
如何保证业务完整处理消息
系统异常时处理中的消息状态如何恢复
消费失败
消息处理超时
消息重试触发条件
消费重试策略概述
已就绪状态
处理中状态
待重试状态
消费成功的状态
提交状态
死信状态
几种状态
PushConsumer消费重试策略
与 PushConsumer 一致，只是少了 待重试状态
SimpleConsumer消费重试策略
消息重试
消息在服务端中的存储以什么维度为判定条件? 消息存储以什么粒度进行管理? 消息存储超过限制后如何处理? 这些问题都是由消息存储和过期清理机制来定义的
解决的问题
原理机制
按照服务端节点粒度管理存储时长而非队列或主题
消息存储管理粒度说明
消息存储和消费状态关系说明
默认存储在本地磁盘中
消息存储文件结构
消息存储机制
消息过期清理机制
消息存储时长建议适当增加
消息存储和清理机制
Tag的使用
Keys的使用
一定要打印日志
发送消息注意事项
消息发送失败处理方式
消费过程幂等
增加Consumer实例数量
提高单个Consumer的消费并行线程数
提高消费并行度
批量方式消费
重置位点跳过非重要消息
看看消费过程能否从逻辑上优化，降低消费时间
优化每条消息消费过程
消费速度慢的处理方式
消费打印日志
其他
3000ms
请求超时时间
过大可以用OSS
不超过 4M
消息大小
3次
消息发送重试次数
默认 16 次
消息消费重试次数
参数默认值
参数约束和建议
功能特性
安装RocketMQ、启动NameServer、启动Broker+Proxy，测试消息收发
快速安装与消息发送实例
一般没有特殊要求就选这个
Local模式部署
Cluster模式部署
部署方式
实现自动主从切换的 RocketMQ 集群
Controller嵌入NameServer部署
Controller独立部署
部署方式
Controller部署
Broker部署
主备自动切换模式部署
创建主题 Topic、创建消费者组、重置消费位点、扩容 Topic队列、扩容 Broker、发送消息等
基本功能
RocketMQ Dashboard
Rocketmq-exporter 是用于监控 RocketMQ broker 端和客户端所有相关指标的系统
监控指标获取流程
Metric结构
Prometheus拉取metrics的过程
可观测性指标
RocketMQ Prometheus Exporter
基于 DLedger 的可以自动容灾切换 RocketMQ 集群
集群搭建
Dledger
权限控制(ACL)主要为 RocketMQ 提供 Topic 资源级别的高级访问控制功能，服务端通过权限控制参数实现各个资源的权限管理和校验
权限控制
建议使用 JDK 1.8 自带的 G1 收集器
JVM选项
Linux内核参数
JVM与OS配置
演进历程&选型对比
老版本的协议
Remoting 协议 SDK
支持更多语言
gRPC 协议 SDK
客户端SDK
部署与运维
Disruptor
收藏
收藏
0 条评论
回复 删除
下一页
