当前位置：首页 > news >正文

消息队列相关知识总结

news 2025/10/16 10:33:50

消息队列面试题全面总结

1. 消息队列基础

1.1 什么是消息队列？

消息队列（Message Queue，简称 MQ）是一个使用队列来通信的组件，本质是转发器，包含发消息、存消息、消费消息的过程。

核心组件：

生产者：发送消息
消息队列：存储消息
消费者：消费消息

流行开源消息队列：

RabbitMQ
RocketMQ
Kafka
ActiveMQ

1.2 消息队列选型对比

特性	ActiveMQ	RabbitMQ	RocketMQ	Kafka
单机吞吐量	万级	万级	10万级	10万级
时效性	毫秒级	微秒级	毫秒级	毫秒级
可用性	高（主从）	高（主从）	非常高（分布式）	非常高（分布式）
消息重复	至少一次	至少一次	至少一次/最多一次	至少一次/最多一次
消息顺序性	有序	有序	有序	分区有序
支持主题数	千级	百万级	千级	百级
消息回溯	不支持	不支持	支持（按时间）	支持（按offset）
管理界面	普通	普通	完善	普通

选型建议：

天猫双十一类秒杀：优先 Kafka、RocketMQ（高吞吐）
公司中台多主题：考虑 RocketMQ（千级）、RabbitMQ（百万级）
金融业务：Kafka、RocketMQ（稳定性、安全性）

1.3 消息队列使用场景

解耦：

系统间通过 MQ 异步通信
系统间不直接耦合，一个系统挂掉不影响其他系统
消息积压在 MQ 中，等待系统恢复后消费

异步：

非同步操作通过 MQ 异步处理
示例：创建订单后异步更新轨迹、库存、状态
提升系统响应速度，改善用户体验

削峰：

流量高峰时期缓冲请求
系统按处理能力消费消息
保证系统稳定性，防止崩溃

1.4 消息重复消费解决方案

产生原因：

生产端重推消息（直到收到成功 ACK）
消费端事务处理：拉取消息+业务处理+提交消费位移
消费端服务宕机，重新拉取消息

解决方案：

业务端实现幂等控制
本地数据库表或 Redis 缓存业务标识
处理前先校验，保证幂等性

1.5 消息丢失解决方案

三个阶段的消息保障：

消息生产阶段：

正确处理返回值和异常
异常时进行消息重发
收到 MQ 的 ACK 确认表示发送成功

消息存储阶段：

部署集群，写多个节点（副本）
一个节点挂掉不影响数据完整性
数据持久化到磁盘

消息消费阶段：

消息处理完成后回复 ACK
不能收到消息就立即回复 ACK
确保消息处理成功后再确认

1.6 消息队列可靠性保证

消息可靠性：

消息持久化：配置队列和消息持久化（durable=true）
消息确认机制：消费者成功处理后发送 ACK
消息重试策略：设置重试次数和间隔，失败后进入死信队列

顺序性保证：

有序消息识别：明确需要顺序处理的业务场景
队列顺序支持：Kafka 同一分区内有序
消费者顺序处理：单线程或串行化处理顺序消息

1.7 幂等写保证方案

核心方案：

唯一标识：为每个请求生成全局唯一 ID
数据库事务+乐观锁：通过版本号控制并发更新
数据库唯一约束：利用唯一索引防止重复写入
分布式锁：保证同一时刻仅一个请求执行关键操作
消息去重：消费者检查消息 ID 是否已处理

1.8 消息积压处理

积压原因：生产者速度 > 消费者速度

解决方案：

排查 BUG：检查是否有 bug 导致积压
优化消费逻辑：单条处理改为批量处理
水平扩容：增加队列数和消费者数量
紧急处理：
- 修复消费者问题
- 新建 10 倍 queue 数量
- 临时分发程序消费积压数据
- 征用 10 倍机器部署消费者
- 快速消费后恢复原架构

1.9 数据一致性保证

普通消息流程：

生产者发送消息到 MQ
MQ 持久化消息
MQ 返回 ACK
MQ push 消息给消费者
消费者消费后响应 ACK
MQ 删除消息

事务消息实现：

发送半事务消息到 MQ
MQ 持久化消息（待发送状态）
MQ 返回 ACK，不触发推送
生产者执行本地事务
提交 commit/rollback 到 MQ
commit：更新消息状态为可发送
rollback：删除消息
状态超时：反查生产者结果

1.10 设计模式参考

观察者模式：

一对多关系，主题和观察者
主题发布消息，通知所有观察者
适合耦合度高的场景

发布订阅模式：

发布者->发布订阅中心->订阅者
完全解耦，发布者不知道订阅者
适合系统间解耦场景

2. 消息队列架构设计

2.1 消息队列架构设计要点

整体流程：

Producer → Broker → Consumer
两次 RPC 调用

RPC 设计：

参考 Dubbo 框架
服务发现、序列化协议

Broker 设计：

持久化方案：文件系统 vs 数据库
消息堆积处理机制

消费关系：

点对点 vs 广播
关系维护：ZK 或 Config Server

高可用设计：

多副本机制
Leader & Follower 模式
Broker 故障重新选举

事务特性：

与本地业务同事务
本地消息落库
定时任务扫描补偿

伸缩性扩展：

Broker → Topic → Partition
增加 Partition 和数据迁移
提高吞吐能力

3. RocketMQ 深度解析

3.1 选择 RocketMQ 的原因

开发语言优势：

Java 语言开发，易于理解和调试
问题排查时可深入阅读源码

社区生态：

阿里巴巴开源并在内部大量使用
经得起生产环境考验
活跃的社区支持

特性丰富：

12 种高级特性
顺序消息、事务消息、消息过滤、定时消息
复杂业务场景解决方案

3.2 RocketMQ vs Kafka

Kafka 优缺点：

✅ 高吞吐量（十几万 QPS）
✅ 集群部署，高可用
❌ 可能数据丢失（磁盘缓冲区）
❌ 功能单一，适用场景受限

RocketMQ 优缺点：

✅ 功能丰富（延迟队列、消息事务等）
✅ 10 万级吞吐量
✅ Java 开发，符合国内技术栈
❌ 性能略低于 Kafka

选型建议：

纯消息收发：Kafka（高吞吐）
业务功能需求：RocketMQ（功能丰富）
Java 技术栈：RocketMQ（更适配）

3.3 延时消息底层原理

实现机制：

Broker 接收延时消息，存入延时 Topic 队列
ScheduleMessageService 执行定时任务
检查消息是否到达设定时间
转发到原始 Topic
Producer 消费消息

3.4 分布式事务处理

最终一致性方案：

转账示例问题：

A 减 100 成功，B 加 100 成功 ✅
A 减 100 失败，B 加 100 失败 ✅
A 减 100 成功，B 加 100 失败 ❌
A 减 100 失败，B 加 100 成功 ❌

RocketMQ 事务流程：

A 服务发送 Half Message 到 Broker
Half Message 发送成功后执行本地事务
本地事务结果：
- 成功：发送 Commit
- 失败：发送 Rollback
- 无响应：事务回查
B 服务消费消息，失败时重试
重试失败记录异常，人工兜底处理

3.5 消息顺序保证

顺序性要求：

同一订单的创建、付款、完成需严格顺序
不同订单可并发消费

实现方案：

业务划分不同队列
顺序消息发送到同一队列
消费者加锁保证顺序消费

原理：

Producer 发送顺序消息到同一 MessageQueue
Consumer 加锁消费
Broker 对 MessageQueue 加锁

3.6 消息不重复消费

解决方案：

业务逻辑实现幂等性
唯一订单号或事务 ID 作为标识
确保同样操作只执行一次

3.7 消息积压处理

积压原因：

发送变快
消费变慢

解决方案：

扩容消费端实例数
降级关闭不重要业务
减少发送数据量

4. Kafka 深度解析

4.1 Kafka 核心特性

高吞吐量、低延迟：每秒几十万条消息，毫秒级延迟
可扩展性：集群热扩展
持久性、可靠性：消息持久化到本地磁盘，数据备份
容错性：允许 n-1 个节点失败（n 为副本数）
高并发：支持数千客户端同时读写

4.2 Kafka 高性能原因

顺序写入优化：

减少磁盘寻道时间
顺序写入比随机写入高效

批量处理技术：

积累足够数据后批量发送
减少网络开销和磁盘 I/O

零拷贝技术：

数据直接从磁盘发送到网络套接字
避免用户空间和内核空间多次拷贝
降低 CPU 和内存负载

压缩技术：

减少网络传输数据量
提高整体吞吐量

4.3 Kafka 消费者模型

推送模型（push）缺点：

难以适应不同消费速率的消费者
容易造成消费者来不及处理
导致拒绝服务和网络拥塞

拉取模型（pull）优势：

消费者自己记录消费状态
可以按照任意顺序消费消息
支持重置到旧偏移量重新处理

消费者组：

多个消费者组成组，共同消费 topic
每个分区同一时间只能由一个消费者读取
多个 group 可同时消费同一 partition

消费方式：

pull 模式根据消费者能力调整速率
timeout 参数避免空循环

4.4 Kafka 消息顺序保证

分区内有序：

同一分区消息按照写入顺序追加
消费者按顺序读取

实现方案：

生产者端：相同 Key 的消息发送到同一分区
消费者端：单线程消费同一分区
全局顺序：
- 只使用一个分区（性能下降）
- 业务层面排序（复杂度增加）

4.5 Kafka 消息积压处理

解决方案：

增加消费者实例数量
确保消费者数 ≤ 分区数
增加主题分区数量
重新平衡消费者组

4.6 分区与消费者关系

核心规则：

一个分区只能被同组的一个消费者消费
一个消费者可以消费多个分区数据
分区数决定同组消费者个数上限

最佳实践：

分区数 = 消费者线程数
达到最大吞吐量
超过分区数的线程是资源浪费

4.7 Kafka 高可用机制

集群架构：

多个 broker 组成集群
topic 划分为多个 partition
每个 partition 存在于不同 broker

副本机制：

每个 partition 有多个副本
选举 leader 处理读写请求
follower 同步数据

故障恢复：

broker 宕机，partition 在其他机器有副本
leader 宕机，follower 重新选举 leader

4.8 Kafka 消息确认机制

ACK 配置：

ACK=0：最不可靠，不等待服务器确认
ACK=1：默认，等待 leader 确认
ACK=-1：最可靠，等待所有副本确认

5. RabbitMQ 深度解析

5.1 RabbitMQ 核心特性

持久化机制：

消息、队列、交换器持久化
服务器重启消息不丢失

import pikaconnection = pika.BlockingConnection(pika.ConnectionParameters('localhost'))
channel = connection.channel()# 声明持久化队列
channel.queue_declare(queue='durable_queue', durable=True)