对比与实战
收尾篇：全选型对比 + 生产实战（监控、积压、故障）。
三强对比
| 维度 | Kafka | RabbitMQ | Pulsar |
|---|---|---|---|
| 模型 | 分区日志 | 队列 + 交换机 | 分区 + 分层存储 |
| 吞吐 | 百万级 | 万级 | 百万级 |
| 延迟 | 毫秒级 | 微秒级 | 毫秒级 |
| 顺序 | 分区内 | 单队列 | 分区内 |
| 消费确认 | offset | ack | cursor |
| 运维 | 中（KRaft 简化） | 轻 | 重（BookKeeper） |
| 典型场景 | 日志、大数据管道 | 业务消息、任务 | 多租户、云原生 |
选型结论：
- 高吞吐流式数据 → Kafka（事实标准）
- 业务消息、灵活路由、低延迟 → RabbitMQ
- 云原生多租户、需要分层存储 → Pulsar
- 轻量随应用 → Redis Stream
生产监控
| 指标 | 看什么 |
|---|---|
| 消费 lag | 积压程度（最核心） |
| 生产/消费速率 | 吞吐对比 |
| ISR 状态 | 副本健康（ISR 收缩 = 风险） |
| 磁盘使用 | 保留策略 vs 容量 |
| 网络/IO | 瓶颈定位 |
| DLQ 积压 | 系统性问题信号 |
lag 监控是第一位：kafka-consumer-groups --describe 或 Burrow 等工具。lag 持续增长 = 消费跟不上，要扩容或查消费逻辑。
积压处理
| 场景 | 处理 |
|---|---|
| 消费慢 | 加消费者（先加分区！） |
| 消费者故障 | 修复 + 自动重平衡 |
| 积压量大 | 临时加分区 + 扩容消费者（削峰场景） |
| 消息已无意义 | 跳过（业务确认后重置 offset） |
| 下游故障 | 降级消费（只更新状态）或暂停并保序 |
关键认知：消费者数量受分区数限制，扩容先加分区（但加分区会破坏原分区顺序，要规划）。
生产配置清单
生产端: acks=all, 幂等, 重试有上限
消费端: 处理完提交, 幂等, 重试上限 + DLQ
集群: 副本 3, min.insync=2, 磁盘监控
保留: 按业务定保留时间（日志 7 天, 业务 30 天）面试追问
- Kafka 和 RabbitMQ？ 吞吐差一个量级：日志流用 Kafka，业务消息用 RabbitMQ（路由灵活延迟低）
- Pulsar 的定位？ 云原生多租户 + 分层存储（计算存储分离）。比 Kafka 新，生态小
- 最该监控什么？ 消费 lag：积压的第一信号。然后是 ISR 状态、磁盘
- 积压怎么扩？ 先加分区再加消费者（消费者 ≤ 分区数）。加分区破坏顺序要规划
- 消息过期了还要吗？ 业务确认后可重置 offset 跳过。比疯狂消费过期消息划算