1. 消息队列基础知识

核心价值与副作用

  • 解耦（Decoupling）：生产者只需关注 Topic，无需关心谁消费。通过接口协议（Contract）实现系统间的弱依赖，避免“牵一发而动全身”。

  • 异步（Asynchrony）：将非核心链路（如注册后的积分赠送、邮件发送）从主流程剥离。

    • 数据推演：主业务 $50ms$ + 积分 $100ms$ + 邮件 $100ms = 250ms$；引入 MQ 后，只需 $50ms$ 即可返回，响应速度提升 5 倍。

  • 削峰填谷（Buffering）：在秒杀等极端场景下，MQ 作为“蓄水池”，保护后端脆弱的数据库不被高并发流量直接击垮。

  • 日志/事件驱动（EDA）：通过订阅特定的事件（Event），实现复杂的流式处理逻辑。

⚠️ 引入 MQ 的代价：

  1. 系统可用性降低：MQ 挂了，整条链路可能瘫痪。

  2. 复杂度增加：必须处理消息丢失、重复、顺序性、一致性等分布式难题。

  3. 一致性问题：主系统成功，异步系统失败，导致数据最终不一致。

基本概念

为了理解消息队列，可以将其类比为快递系统：

  • Producer（生产者）：消息的源头，负责创建并发信。

    • 类比：寄件人。

  • Consumer（消费者）：消息的终点，负责接收并处理。

    • 类比：收件人。

  • Broker（消息代理/服务器）：MQ 的核心节点。负责消息的接收、存储、分发和持久化。

    • 类比：快递转运中心/菜鸟驿站。

  • Message（消息体）：传输的数据载体。通常包含 Header（元数据，如 ID、属性）和 Body（业务数据，如 JSON）。

    • 类比：包裹及其面单。

  • Topic / Queue（主题与队列）：

    • Queue：物理上的存储容器，遵循先进先出（FIFO）。

    • Topic：逻辑上的分类标签。生产者往 Topic 发，Broker 根据订阅规则分发。

  • Consumer Group（消费者组）：

    • 这是 Kafka 的核心设计。多个消费者组成一个逻辑组，组内竞争（一条消息只给组内一个人），组间共享（每个组都能拿到完整的数据流）。

两种核心模型

模型一：点对点模型 (Point-to-Point / P2P)

  • 核心逻辑：基于 Queue。消息一旦被某个消费者消费并确认，就会从队列中删除。

  • 特点：

    • 一对一：每条消息只能有一个消费者。

    • 顺序性：通常保证 FIFO。

    • 解耦：生产者不关心谁消费，只要发到 Queue 就行。

  • 典型代表：RabbitMQ 的经典 Queue 模式。

  • 应用场景：订单处理（一个订单只能由一个服务处理一次）、短信发送。

模型二：发布订阅模型 (Pub/Sub)

  • 核心逻辑：基于 Topic。生产者（发布者）将消息发布到主题，所有订阅了该主题的消费者都能收到。

  • 特点：

    • 一对多：一条消息可以被多个不同的消费者（或消费者组）独立消费。

    • 持久化驱动：消费者可以随时加入，只要消息没过期，就能从头开始读（Kafka 特性）。

  • 典型代表：Kafka（天然分布式发布订阅）、RocketMQ。

  • 应用场景：日志分析（一份日志既要给实时监控，又要给离线统计）、配置更新广播。

消息传递语义 (Message Delivery Semantics)

这是分布式系统的核心难题，通常分为三类：

  1. At most once（最多一次）：消息可能丢失，但绝不重复。

  2. At least once（至少一次）：消息绝不丢失，但可能重复（由于确认机制超时）。

  3. Exactly once（精确一次）：消息既不丢失也不重复。Kafka 通过幂等性和事务实现此语义。

2. 核心难题与通用解决方案

消息丢失（可靠性保障）

要实现“零丢失”，必须保证链路的三个环节都闭环：

  • 生产者端：

    • 确认机制：Kafka 使用 acks=all，RabbitMQ 使用 Confirm 模式。

    • 重试逻辑：捕获网络异常进行指数退避重试。

  • Broker 端：

    • 持久化：消息写入磁盘而非仅留存在内存。

    • 多副本：Leader 宕机后，Follower 能立即接管（Kafka ISR 机制）。

  • 消费者端：

    • 手动 ACK：业务逻辑执行成功后再告知 MQ 删除消息。切记不可在执行业务前自动提交。

重复消费（幂等性）

由于网络抖动导致 ACK 丢失，MQ 可能会重发消息。幂等性是消费端的必修课：

核心思想： 无论执行多少次，结果都一样，防止重复消费。

  • 数据库唯一键：利用 SQL UNIQUE KEY 防止重复插入。

  • Redis 分布式锁/去重表：记录已处理的消息 ID。

  • 状态机控制：update order set status=2 where status=1。

消息顺序性

  • 原理：MQ 只能保证**单分区（Partition/Queue）**内的消息有序。

  • 方案：

    1. 发送端：通过 Message Key 将相关消息（如同一订单）路由到同一个分区。

    2. 消费端：单线程处理，或在多线程处理时根据 Key 进行内存哈希分发。

消息积压

  • 原因：消费速度远慢于生产速度，或消费者挂掉。

  • 应急方案：

    1. 扩容：增加消费者实例，并同步增加 Topic 的分区数（分区数是并行度的上限）。

    2. 降级：停掉非核心业务，腾出资源给核心消费链路。

    3. 修复：如果是消费逻辑死循环或数据库慢查询，必须先修复代码。

3. Kafka

Kafka 基础架构

Kafka 的架构设计是为了水平扩展和高吞吐量而生的。

  • Broker：Kafka 节点。一个 Kafka 集群由多个 Broker 组成。

  • Topic：逻辑上的消息分类。

  • Partition（分区）：核心概念。一个 Topic 可以分成多个 Partition，分布在不同的 Broker 上。这是 Kafka 并行度的最小单位。

  • Replica（副本）：为了高可用，每个 Partition 有多个副本。

    • Leader：负责所有的读写请求。

    • Follower：只负责从 Leader 同步数据，不处理客户端请求。

  • Zookeeper vs KRaft：

    • Old (ZK)：负责元数据管理、Controller 选举。痛点是当分区过多时，ZK 的写入压力大，重平衡慢。

    • New (KRaft)：将元数据存储在 Kafka 内部的 Raft 日志中，消除了对外部 ZK 的依赖，极大地提升了扩展性和元数据同步速度。

Kafka 写入流程

确定分区：Producer 根据 Partition Strategy（指定分区 > Key Hash > 轮询）决定消息去往哪个 Partition。

寻找 Leader：从 Broker 获取元数据，找到该分区的 Leader 副本所在的 Broker。

写入 Leader：Leader 将消息写入本地 Log（先入 Page Cache）。

副本同步 (ISR)：Follower 从 Leader 拉取数据。当 ISR 集合中的所有副本都写入成功后，Leader 才会认为消息已提交。

返回 ACK：根据配置返回确认。

acks 的区别：

  • acks=0：Producer 发出即认为成功。吞吐最高，最易丢数据。

  • acks=1：只要 Leader 写入成功即返回。Leader 挂了且 Follower 未同步时会丢数据。

  • acks=-1 (all)：Leader 和所有 ISR 副本都写入成功才返回。最安全，延迟最高。

什么是 ISR (In-Sync Replicas)：

  • 指与 Leader 保持“同步”的副本列表。如果一个 Follower 落后太多（由 replica.lag.time.max.ms 控制），会被踢出 ISR。

Kafka 消费模型

Pull 模型：Kafka 采用消费者主动拉取（Pull）模式。

  • 优点：消费者可以根据自己的处理能力控制速率；方便批量拉取。

Consumer Group：一个组内，每个分区只能由一个消费者消费。这保证了负载均衡。

Rebalance（重平衡）：

  • 触发场景：消费者增减、订阅 Topic 变更、分区数增加。

  • 发生时会怎样：所有消费者停止消费（STW - Stop The World），重新分配分区所有权。

  • 如何避免频繁 Rebalance：

    1. 合理设置 session.timeout.ms（心跳超时）。

    2. 设置 max.poll.interval.ms（处理逻辑过长会导致误判消费者死亡）。

Kafka 存储机制

顺序写磁盘：Kafka 所有的消息都是追加写（Append-only），利用了磁盘顺序写远快于随机写的物理特性。

Segment 文件：一个 Partition 被切分为多个 Segment（.log 和 .index）。便于过期数据清理和提高查找效率。

稀疏索引 (Sparse Index)：索引文件不记录每条消息，而是记录部分消息的偏移量，减小索引大小，使其能常驻内存。

零拷贝 (Zero Copy)：

  • 传统 IO 需要 4 次拷贝（磁盘 -> 内核 -> 用户态 -> 内核 -> 网卡）。

  • Kafka 利用 sendfile 系统调用，实现 磁盘 -> 内核 -> 网卡 的直接传输，极大地降低了 CPU 压力。

Kafka为什么快：

  • 顺序写磁盘。

  • Page Cache（利用系统内存缓存）。

  • 零拷贝技术。

  • 批量发送与压缩（减少网络 IO）。

  • 分区并行处理。

Kafka 高可用机制

多副本机制：每个分区都有冗余副本。

Leader 选举：如果 Leader 挂了，Controller 会从 ISR 列表中选出一个作为新 Leader。如果 ISR 为空且允许 unclean.leader.election.enable=true，则会从非同步副本中选（会丢数据）。

Kafka Exactly Once

为了解决“重复发送”和“分布式事务”问题，Kafka 引入了：

  1. 幂等性 Producer：

    • 通过 Producer ID (PID) 和 Sequence Number 实现。Broker 会记录每个 PID 对应的最大序列号，重复的请求会被丢弃。

    • 限制：只能保证单会话、单分区的幂等。

  2. 事务 (Transaction)：

    • 通过 Transaction Coordinator 管理。支持 Consume-Transform-Produce 模式，确保一组操作要么全成功，要么全失败。

Kafka 常见问题

消息丢失

  • Producer 端：acks=0/1 或发送失败未重试。解法：acks=all, retries=max。

  • Broker 端：未同步到 Follower 且 Leader 宕机。解法：min.insync.replicas > 1。

  • Consumer 端：自动提交 offset。解法：手动提交，处理完业务再 commit。

消息重复

  • 原因：生产者重试或消费者消费完业务但在提交 offset 前挂了。

  • 解法：消费端实现幂等性（最根本解法）。

消息乱序

  • 原因：多分区自然无序；或者单分区内，上一个请求失败重试导致后面的请求先入队。

  • 解法：

    • 全局有序：设置单分区。

    • 分区有序：保证同 Key 进入同分区。

    • 重试乱序解法：设置 max.in.flight.requests.per.connection=1 或开启幂等性。

Kafka 调优

  • 吞吐量优化：

    • batch.size：增加每个批次的大小（如 32KB）。

    • linger.ms：增加等待时间，让消息积累后再发送。

    • compression.type：使用 lz4 或 snappy 压缩，减少网络带宽消耗。

  • 分区数设计：

    • 分区数一般建议为 Broker 数量的整数倍。并非越多越好，过多分区会增加重平衡时间和文件句柄开销。

4. RabbitMQ

RabbitMQ 基于 AMQP（Advanced Message Queuing Protocol）协议实现，以其灵活的路由机制和健壮的消息可靠性著称。

RabbitMQ 架构

RabbitMQ 的核心设计在于生产者不直接将消息发送到队列，而是发送给 Exchange。

  • Producer：生产者，创建消息并发布。

  • Exchange（交换机）：核心大脑。负责接收生产者发送的消息，并根据路由规则（Routing Key）转发到对应的队列。

  • Queue（队列）：存储消息的容器，直到消费者取走。

  • Binding（绑定）：Exchange 和 Queue 之间的虚连接。定义了消息从交换机流向队列的路径。

  • Consumer：消费者，订阅并处理队列中的消息。

Exchange 类型

交换机决定了消息如何流转，不同类型的匹配逻辑：

类型

匹配逻辑

特点

Direct

精确匹配

消息的 routing key 必须与 Binding 中的 routing key 完全一致。

Fanout

广播

忽略 routing key。将消息转发给所有绑定到该交换机的队列，性能最高。

Topic

通配符匹配

支持模糊匹配。* 匹配一个单词，# 匹配零个或多个单词（如 log.#）。

Headers

属性匹配

不根据 routing key，而是根据消息内容中的 headers 属性匹配（性能较差，极少使用）。

消息路由机制

流程路径：Producer → Exchange → Binding → Queue → Consumer。 这种解耦设计使得一个生产者发出的消息可以根据不同的业务规则投递到不同的队列中，极大地增强了系统的灵活性。

消息确认机制（ACK）

为了保证消息不丢失，RabbitMQ 提供了双向确认：

  • 发布确认 (Publisher Confirms)：生产者发送消息到 Exchange 后，Broker 异步回传一个确认（Ack），告诉生产者消息已安全到达。

  • 消费确认 (Consumer ACK)：

    • 自动 ACK：消息一旦发给消费者，RabbitMQ 立即从内存删除。如果消费者中途崩溃，数据会丢失。

    • 手动 ACK（推荐）：消费者处理完业务逻辑后，显式调用 basic.ack。如果消费者挂了且未发 Ack，消息会重新入队（Re-queue）发给其他消费者。

持久化机制（Persistence）

要保证 RabbitMQ 重启后消息不丢失，必须同时满足三个条件：

  1. Exchange 持久化：声明时 durable=true。

  2. Queue 持久化：声明时 durable=true。

  3. 消息持久化：发送消息时设置 deliveryMode=2。

死信队列（DLQ - Dead Letter Queue）

死信队列不是一种特殊的队列，而是一个普通的交换机，用来接收“无法被正常消费”的消息。

  • 触发条件：

    1. 消息被拒绝：消费者调用 nack/reject 且 requeue=false。

    2. 消息过期：消息达到了 TTL（生存时间）限制。

    3. 队列达到最大长度：最早的消息会被挤出变成死信。

  • 典型应用：

    • 异常处理：将处理失败的消息存入 DLQ，由专门的监控程序人工接入或自动告警。

    • 延迟队列：利用 TTL 过期机制实现。

延迟队列（Delay Queue）

RabbitMQ 本身没有原生延迟队列功能，通常有以下两种方案：

  1. TTL + DLX（传统方案）：

    • 原理：消息发往一个“死信等待队列”（不设消费者），设置 10 分钟过期。过期后消息转发到绑定的死信交换机，最终进入业务队列。

    • 缺点：如果前面的消息过期时间长，后面的短，会出现“队头阻塞”。

  2. Delayed Message 插件（推荐）：

    • 原理：在 Exchange 中暂存消息，等到过期后再投递到队列中。这种方式解决了顺序阻塞问题，是目前社区最主流的解法。

RabbitMQ 高可用

为了避免单机 Broker 宕机导致服务不可用：

  • 镜像队列 (Mirror Queue)：旧版本高可用方案。消息会在集群内的多个节点同步备份。缺点是节点间同步压力大，存在性能瓶颈。

  • Quorum Queue（新方案）：基于 Raft 一致性协议 实现的持久化队列。

    • 优势：比镜像队列更安全（强一致性）、性能更稳定。

    • 适用：对数据可靠性要求极高的场景（如金融交易）。

性能优化与流控

  • Prefetch Count（预取值）：通过 basic.qos 设置。避免一个消费者一次堆积过多消息（如 1000 条），导致其过载而其他消费者闲置。建议设置为一个合理的并行处理数。

  • 流控 (Flow Control)：当 Broker 内存或磁盘空间不足时，会阻塞生产者的连接，防止 Broker 崩溃。

5. Kafka vs RabbitMQ

对比

维度

Kafka

RabbitMQ

架构模型

拉取 (Pull)。基于日志文件存储。

推送 (Push)。基于内存队列存储。

吞吐量

极高 (100万+/秒)。由于顺序写和零拷贝。

较高 (万级/秒)。受限于内存和复杂的路由。

时延

毫秒级。

微秒级。这是 RMQ 的杀手锏。

消息路由

简单。主要靠 Topic 和 Partition。

非常强大。支持多种 Exchange 路由规则。

顺序性

分区有序。

单队列有序。

消息留存

持久化存储。消费完不立即删除。

内存为主。默认消费完即删除。

为什么用 Kafka 不用 RabbitMQ？

  • 场景是大数据量、高吞吐、日志采集、流式计算。Kafka 的高并发能力和磁盘持久化特性更适合作为“数据管道”。

什么场景选 RabbitMQ？

  • 场景是精密业务逻辑、金融交易、低延迟、复杂路由。RabbitMQ 提供了更丰富的消息确认机制（Ack）和更灵活的路由匹配。

高频问题总结

1. 如何保证消息不丢失？

话术建议： “我们需要从生产端、存储端、消费端三位一体来保障。”

  • Producer：

    • Kafka：设置 acks=all，开启重试 retries。

    • RabbitMQ：开启 Confirm 模式。

  • Broker：

    • 持久化：确保消息写入磁盘。

    • 多副本：Kafka 使用 ISR 机制，RMQ 使用镜像队列或 Quorum Queue。

  • Consumer：

    • 关闭自动 ACK。只有在业务逻辑执行成功（写入数据库）后，才手动提交位点。

2. 如何保证消息不重复消费（幂等性）？

  • 全局唯一 ID：每条消息带一个 MessageID。

  • 去重表/Redis：消费前查一下这个 ID 是否处理过。

  • 状态机控制：例如订单系统，如果状态已经是“已支付”，则跳过支付消息的处理。

3. 如何保证顺序消费？

  • Kafka：将需要顺序的消息发往同一 Partition（通过同一个 Key），且消费端采用单线程处理。

  • RabbitMQ：确保消息进入同一 Queue，且同一时间只有一个 Consumer 消费该队列。

4. 如何处理消息积压？

  1. 紧急扩容：临时增加 Topic 的 Partition 数量，并增加相应数量的 Consumer。

  2. 分流处理：写一个临时的“搬运程序”，将积压的消息快速转发到新的、容量更大的 Topic。

  3. 性能优化：检查消费端是否有慢 SQL 或阻塞操作，开启多线程消费（注意顺序性）。

5. Kafka 为什么这么快？（五大必杀技）

  1. 顺序写磁盘：Append-only。

  2. 零拷贝 (Zero Copy)：减少 CPU 和内存拷贝开销。

  3. Page Cache：充分利用操作系统内核缓存。

  4. 批量发送 (Batching)：减少网络 IO 频次。

  5. 数据压缩：减少传输带宽。

6. Kafka Rebalance 原理

  • 触发条件：组员变动（增加/减少）、Topic 变动。

  • 策略：Range（按范围）、RoundRobin（轮询）、Sticky（粘性，减少变动）。

  • 原理：由 Group Coordinator 协助，选出一个 Consumer Leader 来制定分配方案，其他成员同步该方案。

7. Kafka 如何实现高可用？

  • ISR + 副本机制：每个 Partition 都有一个 Leader 和多个 Follower。Leader 负责读写，Follower 只负责同步。

  • 选举机制：Leader 挂掉后，从 ISR（与 Leader 保持同步的副本）中选举新 Leader。

8. RabbitMQ 如何实现延迟队列？

  • TTL + DLX：设置消息在 Queue A 中的过期时间，过期后自动转发到死信交换机进入 Queue B 被消费。

9. MQ 如何实现分布式事务？

分布式事务的本质是最终一致性。

1. 本地消息表（通用方案）

  • 流程：业务库中开一张 message 表。在同一个数据库事务中，既更新业务数据又插入消息。

  • 补偿：后台有个定时任务轮询 message 表，将未发送成功的消息投递到 MQ。

2. Kafka 事务消息

  • 流程：

    1. 开启事务。

    2. 发送消息到 Kafka（此时消息标记为“未提交”，消费者不可见）。

    3. 执行本地业务逻辑。

    4. 提交/回滚 Kafka 事务。

  • 特点：主要用于 Kafka 内部多个 Partition 写入的原子性，跨系统（如 MySQL + Kafka）仍需结合幂等。

3. RocketMQ 事务消息

  • 引入了回查机制。即使 Commit 请求由于网络丢了，Broker 也会主动询问 Producer：“你刚才那个本地事务到底成功没？”这是目前最完备的 MQ 事务方案。

6. 进阶

事务消息

传统的先发消息再改数据库（或反之）在网络抖动时都会导致数据不一致。

Kafka 事务（Transactional API）

  • 原理：引入了 Transaction Coordinator（事务协调器）和 Transaction Log。

  • 过程：

    1. 生产者开启事务 initTransactions()。

    2. 发送消息到 Kafka，此时消息标记为 Uncommitted（对配置了 isolation.level=read_committed 的消费者不可见）。

    3. 生产者发送位点（Offset）到特定的 Topic。

    4. 提交事务 commitTransaction()，协调器将消息状态改为 Committed。

  • 深度细节：Kafka 事务主要解决的是 Consume-Transform-Produce（从 A 读，处理后发往 B）的原子性。

RocketMQ 事务消息（更完备的方案）

  • 核心逻辑：二阶段提交 + 事务回查。

    1. Half Message：生产者发半消息给 Broker，存储在特殊的队列中，消费者不可见。

    2. 执行本地事务：生产者执行业务 SQL。

    3. 二次确认：根据 SQL 结果给 Broker 发 Commit 或 Rollback。

    4. 回查机制：如果确认消息丢了，Broker 会定时反向调用生产者的一个接口，询问：“这个事务你到底成功没？”（检查数据库记录是否存在）。

消息顺序 + 分布式事务结合

在复杂的金融逻辑中（如扣款、发券、通知），既要保证顺序，又要保证事务。

  • 实现方案：顺序路由 + 本地消息表。

    • 步骤：

      1. 在业务数据库同事务内，插入业务数据并增加一条 message_log（状态为待处理）。

      2. 通过 order_id 作为 Partition Key，确保同一个订单的消息进入同一个分区。

      3. 异步线程扫描 message_log 发往 MQ。

      4. 消费端通过 唯一幂等键 保证即使重试也不会产生脏数据。

MQ + 微服务架构

事件驱动架构 (EDA - Event-Driven Architecture)

  • 核心：系统不再是通过 REST API 互相“下指令”，而是通过“发布事件”来驱动。

  • 优势：极度解耦。例如“订单已支付”事件发出后，库存系统、物流系统、大数据分析系统各自订阅，互不干扰。

Saga 模式（长事务处理）

  • 在微服务中，无法使用强一致性的 XA 事务，Saga 是主流替代方案。

  • 基于 MQ 的实现（异步补偿）：

    1. 服务 A 执行成功，发消息给服务 B。

    2. 服务 B 执行失败，发一个“补偿消息”回给服务 A。

    3. 服务 A 订阅补偿消息，执行逆向操作（如退款、回滚库存）。

MQ监控与运维

如何保证生产环境 MQ 的稳定？

1. 消费延迟 (Consumer Lag)

  • 定义：Log End Offset (最新生产位点) - Current Offset (当前消费位点)。

  • 监控工具：Kafka 使用 Kafka Exporter + Prometheus + Grafana。

  • 报警阈值：根据业务容忍度设置，如“关键链路积压超过 10 万条且 5 分钟未下降”即告警。

2. 堆积监控

  • 产生原因分析：

    • 消费端代码 Bug（如死循环、慢查询）。

    • 下游依赖系统（如 Redis/DB）响应变慢。

    • 突发流量激增。

  • 处理机制：监控队列深度曲线，通过斜率判断是否需要自动触发 消费者水平扩容。

3. Broker 健康状态

  • 关键指标：

    • Disk Usage：磁盘空间（Kafka 磁盘满会导致全线挂掉）。

    • CPU Load / IO Wait：判断是否有大量的小消息导致 IO 瓶颈。

    • 副本同步状态 (Under Replicated Partitions)：如果有分区副本数不足，说明某台 Broker 挂了或网络断开。

    • JVM GC：由于 MQ 处理大量对象，频繁 Full GC 会导致 Broker 假死。