【面试】Kafka / RabbitMQ / ActiveMQ
一、Kafka 面试常见问题
Q1. Kafka 的优势和适用场景？
答：
高吞吐、低延迟，适合日志采集、埋点数据、大数据实时处理。
分布式架构，水平扩展简单。
Topic + Partition 模型，天然支持并行消费。
追问：
如果业务需要严格顺序消费怎么办？
→ 通过设置 key，将相同业务数据写入同一 partition，保证有序。
Q2. Kafka 如何保证消息不丢失？
答：
生产端：acks=all，开启重试，启用幂等生产者。
Broker：多副本（replication-factor >= 3）。
消费端：手动提交 offset（处理完成后再提交）。
追问：
如果生产端发送超时，但消息实际写成功了，会不会导致重复消息？
→ 会，解决方案是消费端幂等处理，例如订单表唯一 key 去重。
Q3. Kafka 消息积压怎么解决？
答：
增加分区，扩容消费者。
批量拉取、批量消费。
限流/降级，不重要的消息丢弃。
追问：
如果 Topic 消息量太大导致磁盘爆满怎么办？
→ 设置消息过期策略（retention.ms / retention.bytes），或者扩容磁盘 / 做分区迁移。
Q4. Kafka 如何实现“Exactly Once”？
答：
生产端：启用幂等性 + 事务写入。
消费端：处理完再提交 offset，消费逻辑保证幂等。
追问：
Kafka 事务会不会降低性能？
→ 会，吞吐量下降，但适合金融类、订单支付场景。
二、RabbitMQ 面试常见问题
Q1. RabbitMQ 的优势和典型场景？
答：
支持 AMQP 协议，功能丰富（路由、主题、广播）。
适合订单通知、延迟任务、异步解耦。
内置确认机制（ACK/NACK）、死信队列。
追问：
如果要做延迟队列，用 RabbitMQ 怎么实现？
→ 使用 TTL + 死信交换机（DLX）。
Q2. RabbitMQ 如何保证消息可靠性？
答：
生产端：开启 publisher confirm。
Broker：开启持久化（durable queue + persistent message）。
消费端：手动 ACK，失败时重回队列。
追问：
如果消费端一直挂掉，消息会不会丢？
→ 不会，但会堆积在队列里，需要考虑限流和重试机制。
Q3. RabbitMQ 如何解决消息堆积？
答：
增加消费者数量。
拆分队列，按业务类型分流。
使用惰性队列（Lazy Queue），消息直接落盘，减少内存占用。
追问：
如果积压太严重导致内存溢出怎么办？
→ 使用 Lazy Queue 或迁移到 Kafka。
Q4. RabbitMQ 如何保证消息顺序？
答：
单队列单消费者时有序。
多消费者时要控制并发，例如分区路由 + 哈希一致性。
追问：
如果必须在多消费者情况下保证顺序？
→ 使用一致性哈希队列，把同一业务 ID 路由到同一队列。
三、ActiveMQ 面试常见问题
Q1. ActiveMQ 的特点和使用场景？
答：
支持 JMS，和 Java 生态兼容性好。
功能较全（点对点 Queue、发布订阅 Topic、调度消息）。
企业内部老系统常见。
追问：
为什么很多新项目更倾向用 Kafka/RabbitMQ？
→ ActiveMQ 性能较低，社区活跃度下降，Kafka 更适合高吞吐，RabbitMQ 更适合灵活路由。
Q2. ActiveMQ 如何保证消息不丢？
答：
开启 KahaDB 持久化。
设置持久化队列。
消费端使用 CLIENT_ACK 或事务模式。
追问：
如果 Broker 崩溃重启，消息会丢吗？
→ 不会，持久化消息会在重启后恢复。
Q3. ActiveMQ 如何实现延迟消息？
答：
使用 Scheduled Message 插件（
AMQ_SCHEDULED_DELAY属性）。适合定时任务、订单超时取消。
追问：
和 RabbitMQ 的延迟队列比有什么区别？
→ ActiveMQ 原生支持；RabbitMQ 需要 TTL + DLX 组合。
Q4. ActiveMQ 如何实现集群高可用？
答：
Master/Slave 模式（基于共享存储或数据库）。
网络集群（network of brokers）。
追问：
如果 Master 宕机，消费者会不会中断？
→ 会短暂中断，切换到 Slave 继续消费。
四、总结对比（面试官常问）
| 特性 | Kafka | RabbitMQ | ActiveMQ |
|---|---|---|---|
| 定位 | 高吞吐日志流处理 | 可靠消息投递，灵活路由 | 企业级，JMS 兼容 |
| 吞吐量 | 最高（百万级 TPS） | 中等（万级 TPS） | 较低 |
| 消息顺序 | 分区内有序 | 队列内有序 | 队列内有序 |
| 可靠性 | 副本机制 + offset | ACK + 持久化 | JMS ACK + 持久化 |
| 延迟队列 | 需额外实现 | TTL+DLX | 原生支持 |
| 典型场景 | 大数据、日志、埋点 | 订单处理、通知、延迟任务 | 传统企业应用 |