定义：当消费者处理速度跟不上生产速度时，通过反馈机制告知生产者降低发送速率，防止系统过载。

RabbitMQ：通过 prefetch 限制未确认消息数量。达到上限后不再推送，天然背压。

Kafka：消费者自己控制拉取速率（pull 模式），可以暂停消费。但没有自动背压机制，需在应用层实现。

三个条件缺一不可：

1. Exchange 持久化：assertExchange(name, type, { durable: true })
2. Queue 持久化：assertQueue(name, { durable: true })
3. Message 持久化：sendToQueue(name, msg, { persistent: true })

注意：持久化不保证 100% 不丢。消息先到 PageCache，还没刷盘就宕机会丢。需要更高可靠性用 publisher confirms。

Offset：消息在 Partition 内的唯一递增编号，标识消费进度。

管理方式：

1. 自动提交：enable.auto.commit=true，定期提交，可能丢消息或重复消费。
2. 手动提交：commitSync() 或 commitAsync()，处理完再提交，更精确。
3. 指定 offset：seek(partition, offset)，可以回溯重新消费。

ACK (ack)：告诉 Broker 消息处理成功，可以删除。消息的生命周期结束。

NACK (nack)：告诉 Broker 消息处理失败。

• requeue=true：消息重新入队，重新投递给消费者。
• requeue=false：消息变成死信（如果配置了 DLX）或被丢弃。

注意：NACK + requeue=true 可能导致消息无限循环重试。建议设置最大重试次数。

1. 消息丢失：ACK 机制 + 持久化 + 生产者确认
2. 消息重复：幂等消费（唯一 ID + 去重表）
3. 消息积压：扩容消费者 + 监控告警
4. 消息乱序：相同 Key 路由到同一 Partition
5. 系统复杂度：引入 MQ 增加了运维成本，需要监控、 HA、故障恢复

点对点 (PTP)：一条消息只被一个消费者消费。多个消费者竞争消费，消息在消费者间分配。适合任务分发。

发布订阅 (Pub/Sub)：一条消息被所有订阅者各消费一次。每个订阅者独立接收完整消息。适合事件广播。

Kafka 的 Consumer Group：结合两者优势 — 组内竞争消费（PTP），组间广播（Pub/Sub）。

1. 副本机制 (Replica)：每个 Partition 有多个副本，分布在不同 Broker 上。
2. Leader/Follower：读写都走 Leader，Follower 同步数据。Leader 宕机时 Follower 自动晋升。
3. ISR (In-Sync Replicas)：与 Leader 保持同步的副本集合。只有 ISR 中的副本才能成为新 Leader。
4. Controller：Kafka 集群中有一个 Broker 担任 Controller，负责分区 Leader 选举、Broker 故障检测。

小规模场景可以：QPS < 5000、消息量小、已在用 Redis、不需要复杂路由时，Redis Streams 是轻量好选择。

不能替代的场景：

• 需要复杂路由（多种 Exchange）
• 消息不能丢失（Redis 内存为主，RDB/AOF 可能丢数据）
• 需要大量消息堆积（Redis 受内存限制）
• 需要成熟的运维监控生态

VHost (Virtual Host)：RabbitMQ 中的逻辑隔离单位，类似于数据库中的"数据库"概念。

• 每个 VHost 有独立的 Exchange、Queue、Binding、权限
• 不同项目/环境可以用不同的 VHost 隔离
• 默认 VHost 是 /
• 用户可以被授权访问特定的 VHost

RabbitMQ：声明队列时设置 x-max-priority（如 10），发送消息时设置 priority 字段。高优先级消息优先被消费。

Kafka：没有原生优先级支持。可以通过不同 Topic 模拟（高优先级 Topic 优先消费），或在应用层实现。

// RabbitMQ 优先级队列
ch.assertQueue('tasks', {
  arguments: { 'x-max-priority': 10 }
});
ch.sendToQueue('tasks', msg, { priority: 5 });

根本原因：消费者处理成功，但 ACK 未到达 Broker（网络超时、消费者宕机、Broker 重启）。Broker 认为消息未消费，重新投递。

常见场景：

1. 消费者处理完消息后，发送 ACK 前宕机
2. 网络抖动导致 ACK 丢失
3. 消费者处理超时，Broker 认为消费失败重新投递

结论：任何消息队列都可能重复投递，消费者必须保证幂等。

Rebalance：Consumer Group 中有消费者加入或退出时，Partition 需要重新分配给剩余消费者。

问题：

1. Rebalance 期间所有消费者暂停消费（Stop The World）
2. 频繁 Rebalance 导致消费延迟
3. 可能触发连锁 Rebalance（消费者超时 → Rebalance → 更多超时）

优化：

• 调大 session.timeout.ms 和 heartbeat.interval.ms
• 使用 StickyAssignor 减少分区迁移
• 确保消费者处理逻辑高效

1. 运维成本：MQ 本身是分布式系统，需要 HA、监控、升级、故障恢复。
2. 一致性问题：分布式事务难处理。生产者写库成功但 MQ 发送失败怎么办？需要补偿机制。
3. 调试困难：异步链路比同步链路更难追踪。需要分布式追踪（如 Jaeger）。
4. 消息堆积风险：消费者故障时消息堆积，可能导致内存溢出或磁盘满。
5. 系统可用性：MQ 挂了 = 系统不可用。MQ 成了新的单点。

核心问题清单：

1. 消息丢失：生产者确认 + Broker 持久化 + 消费者手动 ACK
2. 消息重复：唯一 ID + 去重表 + 幂等消费
3. 消息顺序：相同 Key → 相同 Partition，分区有序
4. 消息延迟：TTL + 死信队列 / 时间轮 / Redis ZSET
5. 消息积压：扩容消费者 + 监控告警 + 降级方案
6. 消息回溯：Kafka offset 重置
7. 高可用：RabbitMQ 镜像队列 / Kafka 副本机制
8. 安全：认证、授权、VPC 隔离、消息加密

总结公式：消息不丢 + 不重 + 有序 + 可回溯 = 可靠消息系统。