【面试】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 原生支持
典型场景 大数据、日志、埋点 订单处理、通知、延迟任务 传统企业应用
相关推荐
uhakadotcom11 分钟前
如何从阿里云的sls日志中清洗出有价值的信息?
后端·面试·github
豆苗学前端1 小时前
长时间不操作自动退出登录(系统非活跃状态下自动登出机制的企业级设计方案)
前端·后端·面试
绝无仅有2 小时前
猿辅导面试系列:MQ消息队列解析与常见面试问题
后端·面试·github
绝无仅有2 小时前
猿辅导计算机面试文章经典总结
后端·面试·github
怪兽201414 小时前
Handler中有Loop死循环,为什么没有阻塞主线程,原理是什么?
android·面试
ikoala14 小时前
Node.js 25 正式发布:性能飙升、安全升级、全面向 Web 靠拢!
前端·面试·node.js
木易 士心15 小时前
Android 开发核心知识体系与面试指南精简版
android·面试·职场和发展
专注前端30年15 小时前
2025 最新 Vue2/Vue3 高频面试题(10月最新版)
前端·javascript·vue.js·面试
好玩的Matlab(NCEPU)16 小时前
Redis vs RabbitMQ 对比总结
数据库·redis·rabbitmq
沐怡旸16 小时前
【底层机制】【Android】AIDL原理与实现机制详解
android·面试