消息队列的7种消息场景
2023-11-06 15:53:59 1 举报AI智能生成
登录查看完整内容
消息队列技术选型需要考虑的7种消息场景
作者其他创作
大纲/内容
生产者发送消息
Broker 保存消息
消费者消费消息
是消息队列最基础的功能
系统解耦
削峰填谷
作用
流程图
普通消息
是指生产者发送消息的顺序和消费者消费消息的顺序是一致的。
这三个消息消费者需要按照顺序来进行消费
同一个用户提交订单、订单支付、订单出库
场景
集群中有多个生产者发送消息，网络延迟不一样，很难保证发送到Broker的消息落盘顺序是一致的
如果Broker有多个分区或队列，生产者发送的消息会进入多个分区，无法保证顺序消费
如果有多个消费者来异步消费同一个分区，很难保证消费顺序跟生产者发送顺序一致
实现难点
生产者给消息赋值一个 key，对 key 做 Hash 运算来指定消息发送到哪一个分区
Kafka 和 Pulsar
对同一个用户的一笔订单，提交订单、订单支付、订单出库这三个消息赋值同一个 key，就可以把这三条消息发送到同一个分区
生产者在发送消息的时候，可以通过 MessageQueueSelector 指定把消息投递到 MessageQueue
RocketMQ
Exchange 根据设置好的 Route Key 将数据路由到不同的 Queue 中
RabbitMQ
其它
同一个生产者必须同步发送消息到同一个分区
一个分区绑定一个消费者
一个分区只能给同一个消费者消费
保证消息有序的两个条件
顺序消息
是指消息发送后不会立即被消费，而是指定一个时间，到时间后再消费
也叫定时消息
电商购物时，30 分钟未支付订单，让订单自动失效
定义 18 个延时级别，每个延时级别对应一个延时时间
生产者把消息发送到 Broker 后，Broker 首先把消息保存到 SCHEDULE_TOPIC_XXXX 这个 Topic
然后调度任务会判断是否到期，如果到期，会把消息从 SCHEDULE_TOPIC_XXXX 取出投递到原始的 queue，这样消费者就可以消费到了
旧版本的消息只支持最大两个小时的延时，RocketMQ5.0基于时间轮算法实现了定时消息
延时消息首先会写入一个 Delayed Message Tracker 的数据结构中
Delayed Message Tracker 根据延时时间构建 delayed index 优先级队列
消费者拉取消息时，首先去 Delayed Message Tracker 检查是否有到期的消息。如果有则直接拉取进行消费
Pulsar
方式一：投递到普通队列都不消费，等消息过期后被投递到死信队列，消费者消费死信队列
方式一：生产者发送消息时，先发送到本地 Mnesia 数据库，消息到期后定时器再将消息投递到 broker
方式一：可以通过生产者拦截器来实现消息延时发送
方式一：定义延时 Topic，利用类似 RocketMQ 的方案来实现延时消息
Kafka
实现
延时消息
是指生产消息和消费消息满足事务的特性
通过 Channel 来开启事务消息
给多个生产者设置同一个事务 ID ，从而把多个 Topic 、多个 Partition 放在一个事务中，实现原子性写入
即一批消息要不全部发送成功，要不全部发送失败
只支持生产消息的事务特性的组件
对于事务语义的定义是：允许事件流应用将消费、处理、生产消息整个过程定义为一个原子操作
是通过 half 消息来实现的
电商购物场景：账户服务扣减账户金额后，发送消息给 Broker，库存服务来消费这条消息进行扣减库存
例子
不能保证消费消息的原子性
事务消息
主要用于跟踪消息的生命周期，当消息丢失时可以很方便地找出原因
跟普通消息一样，也需要存储和查询，也会占用消息队列的资源
消息生命周期的关键节点一定要记录
不能影响正常消息的发送和消费性能
不能影响 Broker 的消息存储性能
要考虑消息查询维度和性能
选择的考虑点
轨迹消息
使用的情况
当消费者消费失败时，会进行重试，如果重试 16 次还是失败，则这条消息会被发送到死信队列
实现消费端死信队列的组件
生产者发送消息被拒绝，并且 requeue 参数设置为 false
Broker 消息过期了
队列达到最大长度
消息会被发送到死信队列的情况
消息变成死信消息后，会被发送到死信交换机（Dead-Letter-Exchange）
实现生产者和 Broker 死信队列的组件
死信队列
需要优先处理的一些消息
如银行的金卡客户、银卡客户优先级高于普通客户
使用场景
支持优先级队列的组件
优先级消息
消息队列的7种消息场景
0 条评论
回复 删除
下一页
