# 1. Spring AMQP 的 @RabbitListener 与 RabbitMQ Streams 在 Spring Boot 3.5+ 的集成 A @RabbitListener 只能消费 AMQP B RabbitMQ Streams 与 AMQP 队列完全相同 C Stream 不支持重放 D @RabbitListener 声明式消费，AMQP 队列消费即删，Stream 是日志型持久队列支持重放与消费者组 ✓ 正确答案
# 2. Spring Boot 3.5+ 中 @TransactionalEventListener 与本地消息表（Outbox Pattern）的最终一致 A 业务事务内不能写消息表 B 事务内直接发 MQ 最可靠 C Outbox 无法保证消息不丢 D 业务事务与 outbox 表同库原子写，提交后异步投递并标记，@TransactionalEventListener 保证投递在提交后，实现最终一致 ✓ 正确答案
# 3. RocketMQ 的 transactionalMessage 与本地事务回滚 A 半消息对消费者立即可见 B 本地事务失败消息仍会投递 C 事务消息无需回查 D 先发半消息再执行本地事务，成功 COMMIT 回滚 ROLLBACK，状态未知时 broker 回查确认，实现最终一致 ✓ 正确答案
# 4. RocketMQ 的事务回查（checkLocalTransactionState） A 回查是生产者主动查询 broker B broker 未收到提交/回滚时回查本地事务结果，据此决定半消息提交/回滚，保证最终一致，超限进死信 ✓ 正确答案 C 回查会无限进行 D 回查无需本地事务状态
# 5. 幂等性实现（数据库唯一索引/Redis SET/状态机） A 唯一索引无法去重 B 幂等靠去重键 + 原子判断：数据库唯一索引、Redis SETNX、状态机分别适用不同场景，可结合使用 ✓ 正确答案 C Redis SETNX 不保证幂等 D 状态机与幂等无关
# 6. 消息幂等性的实现方案，唯一主键约束、Redis 去重表、数据库唯一索引 A DB 唯一主键/唯一索引可靠强一致，Redis 去重表高并发，可结合使用实现幂等 ✓ 正确答案 B 唯一索引不能用于幂等 C Redis 去重表比 DB 更可靠 D 幂等只能用一种方案
# 7. 消息重复消费的根本原因与幂等设计 A at-least-once 语义下 ack 丢失/重试/崩溃都会导致重复投递，消费端需幂等（去重键+原子生效）应对 ✓ 正确答案 B 重复消费只在网络故障时发生 C MQ 保证不重复消费 D 幂等只在 producer 端
# 8. RabbitMQ 的 Publisher Confirms 与事务 A Publisher Confirms 异步确认可靠且性能好，channel 事务吞吐低，现代推荐用 confirm ✓ 正确答案 B confirm 无法确认消息落盘 C 事务比 confirm 更适合生产 D 事务与 confirm 性能相同
# 9. RabbitMQ 的 Quorum Queue（仲裁队列） A Quorum Queue 是单副本镜像 B Quorum Queue 基于 Raft 多副本复制，多数派确认与故障转移，保证高可用一致性，替代镜像队列 ✓ 正确答案 C Quorum Queue 不复制数据 D Quorum Queue 与经典队列完全相同
# 10. RabbitMQ 的四种 Exchange 类型与路由键匹配规则（direct/topic/fanout/headers） A direct 支持通配符 B topic 忽略 routing key C fanout 也按 routing key 路由 D direct 精确匹配 routing key，topic 用通配符匹配，fanout 广播忽略 key，headers 按 header 匹配 ✓ 正确答案
# 11. RabbitMQ 的死信队列（DLX/DLQ）在消息重试与失败处理场景的应用 A 死信队列无法接收拒绝的消息 B 死信队列只用于发送 C 死信后消息自动重试无限次 D 消息被拒/过期/队列满进入死信队列，配合延时队列实现重试，最终失败进死信供人工处理/告警 ✓ 正确答案
# 12. RabbitMQ 的消息确认（ack/nack/requeue） A basicAck 后消息还在队列 B requeue 与 ack 无关 C basicAck 确认删除，basicNack 否定确认，requeue=true 重新入队可能死循环，requeue=false 进死信 ✓ 正确答案 D ack 前崩溃消息丢失
# 13. RocketMQ 5.x Pop 消费的消息粒度分配与消费者心跳/可见性超时（visibility timeout）的协同 A Pop 消费取走即永久删除 B Pop 按消息粒度借出并设可见性超时，超时未确认重新可见，心跳维持会话，实现 at-least-once ✓ 正确答案 C 可见性超时与重投无关 D Pop 按队列整体分配固定
# 14. RocketMQ 的 Topic/Queue/Message 模型 A Topic 分多个 Queue，Queue 是并行与顺序单元，一个 Queue 同一时刻被组内一个消费者消费 ✓ 正确答案 B Queue 可被多个消费者组内消费者同时消费 C Message 无标签 D Queue 数与并行度无关
# 15. RocketMQ 集群消费与广播消费的差异及顺序消费（MessageListenerOrderly）的锁语义 A 广播消费一条消息只处理一次 B 顺序消费与全局消费并行度相同 C 广播消费适合分摊负载 D 集群消费分摊给组内一个消费者，广播消费每个消费者都处理，顺序消费用队列锁串行保 Queue 内顺序 ✓ 正确答案
# 16. 消息丢失的三大场景（生产者、Broker、消费者） A 消息丢失只在消费者端 B 生产者未确认/未重试、Broker 未持久化/副本不足、消费者未确认/偏移过早提交都会丢消息，三端分别防护 ✓ 正确答案 C 消费者 ack 与丢消息无关 D Broker 持久化后永不丢
# 17. 消息可靠投递（生产端确认 + 消费端 ACK） A 只要生产端确认即可 B 生产端确认（acks/confirm）+ broker 持久化 + 消费端处理成功才 ack，配合幂等实现端到端不丢不重 ✓ 正确答案 C 消费端 ack 不影响可靠性 D 可靠投递只需消费端配合
# 18. RabbitMQ Channel 的线程安全边界与连接复用（Channel 数限制） A 一个连接可复用多个 Channel，但 Channel 非线程安全且数量有上限，需单线程使用或连接池管理 ✓ 正确答案 B Channel 是线程安全的 C Channel 数无限 D 每个线程必须独立 Connection
