Peter.P.Zhang的个人博客

基本概念

应用场景

• 异步任务处理
• 流量控制，削峰填谷
• 服务间解耦
• 消息广播
• 流计算

可能带来的问题

1. 引入额外的中间件，增加系统复杂度
2. 数据延迟
3. 数据一致性问题

理解两种消息模型

队列模型(点对点模型)

队列是先进先出的线性表（First-In-First-Out），最初的消息队列就是严格意义上的队列。

1. 一个或者多个生产者向队列中发送消息的集合就是队列中可以消费到的消息
2. 队列中消息的顺序即生产消息的自然顺序
3. 一个或多个消费者竞争消费同一个队列中的消息
4. 无法做到将一份消息分发给多个消费者，但可以通过生产者生产多份消息到不同的队列来解决

发布订阅模型

1. Topic作为服务端存放消息的容器，存储了该主题下的所有消息> 2. 消费者先订阅消息主题（Topic）
2. 主题可以被多个消费者订阅
3. 服务端分别维护了每一个消费者对该Topic的当前消费位置

常用消息队列产品

RabbitMQ

典型的队列模型

1. 利用exchange路由到多个队列实现发布订阅模型
2. 为了实现发布订阅模型，需要复制多分数据和多个队列，资源消耗比较多
3. 每个队列消息是独立的，因此消息是全局有序的

RocketMQ

标准的发布订阅模型

1. 为了提升消费性能，引入了queue，通过多个队列实现并行消费
2. 每一个消费组作为一个订阅者，消费一份完整的消息，不同的消费组之间互不影响
3. 消费组中包含多个消费者，同一个Group内的消费者为竞争消费关系
4. 服务端维护着每个消费组的消费位置（consumer offset）
5. 消费组内每一个消费者可以绑定一个或多个queue进行消费，一个queue只能被消费组内的一个消费者绑定
6. 同一个队列中的消息是有序的，全局维度消息是无序的

Question 1：如何增加Topic中消息的消费速度？ 是否存在消费极限？

增加队列及消费者，单纯的增加消费者可能并不能解决问题

Question1：如何实现顺序消息 ？

单一的消息队列

Kafka

跟RocketMQ完全一样的消息模型，queue --> partition

如何选型？

• RabbitMQ
• RocketMQ
• Kafka
• Pulsar：下一代云原生分布式消息队列（存算分离）

常见问题 & 使用姿势

消息重复

消息重复的情况必然存在

消息传递服务质量

• At most once
• At least once
• Exactly once

我们使用的消息队列产品绝大多数提供的服务质量都是：At least once

一般使用幂等消费来解决消息重复的问题

At least once + 幂等消费 = Exactly once（从对系统影响的结果来看）

1. 数据库唯一约束
2. 数据库乐观锁
3. 分布式锁

Question 1：还有哪些场景会引发消息重复？

丢消息

痛点不在于丢消息，而在于消息丢了你还不知道

1. 增加消息检测逻辑：上游给消息编号，下游检测编号连续性
2. 基于业务日志进行消息流转监控

消息积压

一般考虑消费端消费性能差导致的消息积压问题

1. 提高消费者的能力
2. 扩容消费者/扩容分区（queue）

Question ：是否可以通过在消费端增加消息缓存来实现加速消费的目的？

阿里云RMQ特点

1. 消息默认重试次数：16次
2. 消息体限制：4M