# 1. RabbitMQ 核心模型中 Exchange/Queue/Binding 的路由语义（direct/topic/fanout/headers） A Producer 将消息发到 Exchange，Exchange 按绑定与 routing key 路由到 Queue ✓ 正确答案 B Producer 直接发送消息到指定 Queue C fanout 交换机按 routing key 精确匹配 D headers 交换机按 routing key 匹配
# 2. 消息可靠性中 publisher confirm、mandatory/return、consumer ack 与 requeue 的组合 A publisher confirm 保证发送成功，mandatory/return 兜底不可路由消息，consumer ack 保证消费不丢 ✓ 正确答案 B 开启 publisher confirm 后无需消费端 ack C mandatory 标志会让消息强制进入队列 D requeue 不会造成重复消费
# 3. 高可用队列选型中 Quorum Queue 与 Streams 的复制模型以及镜像队列为何被 4.x 移除 A Quorum Queue 与 Streams 都无复制能力 B 镜像队列在 4.x 中仍是推荐方案 C Quorum Queue 基于 Raft 协议，多数副本确认后返回，提供强一致性与自动故障转移 ✓ 正确答案 D 镜像队列没有脑裂风险
# 4. 内存与磁盘告警中 memory high watermark、disk free limit、flow control 的触发与治理 A 内存高水位默认 100% B flow control 只影响消费者，不影响生产者 C 磁盘空闲限制不影响 RabbitMQ 运行 D 内存或磁盘达到阈值时 RabbitMQ 进入 flow control，阻塞生产者保护节点 ✓ 正确答案
# 5. 安全运维中用户与 vhost 权限、TLS 认证、插件与版本升级 A TLS 只能加密，不能用于认证 B vhost 不参与权限隔离 C 用户通过 vhost 隔离租户，并为用户配置 configure/read/write 权限 ✓ 正确答案 D 插件升级无需考虑兼容性
# 6. 常见故障排障中连接被重置、channel 异常关闭、消息丢失、集群脑裂恢复 A 消息丢失多因未持久化、未开启 confirm、未手动 ack 等可靠性配置缺失 ✓ 正确答案 B 连接被重置只会由权限不足导致 C 集群脑裂与网络分区无关 D channel 异常关闭永不发生
# 7. 性能调优中消息大小、持久化开销、连接/信道管理与线程池配置 A 线程池配置与性能无关 B 大消息不会增加内存压力 C 连接越多性能越好，无需复用 D 持久化消息需要 fsync 到磁盘，可靠性更高但吞吐与延迟受影响 ✓ 正确答案
# 8. 插件生态中 Shovel、Federation、Management UI、Prometheus 插件的运维用途 A Prometheus 插件用于替代 Management UI B Shovel 只能用于本集群内部转发 C Federation 无法跨集群复制消息 D Shovel 用于跨集群消息转发，Federation 实现多集群联邦，Prometheus 暴露指标供监控 ✓ 正确答案
# 9. 死信机制中 TTL、x-dead-letter-exchange 配置与重投策略 A 死信消息只能丢弃，无法重投 B 消息被 reject 且 requeue=false、TTL 过期或队列超长时会进入死信交换机 ✓ 正确答案 C TTL 过期后消息直接消失，不会进入死信 D DLX 只能用于消息过期场景
# 10. 消息堆积与消费治理中队列长度、prefetch 设置、消费者处理能力与限流 A 扩容消费者不会提升消费速率 B prefetch 越大消费越稳定，无副作用 C 队列长度反映生产速率，与消费无关 D prefetch 控制消费者一次预取的消息数，过大易导致消费不均与内存积压 ✓ 正确答案
# 11. 集群与节点运维中 Erlang cookie、节点发现、网络分区处理与恢复 A 所有节点 Erlang cookie 必须一致，否则节点无法加入集群 ✓ 正确答案 B 网络分区无需处理，会自动恢复 C 节点发现与 cookie 无关 D partition 策略只为性能设置
# 12. 消费者预取（prefetch）与公平分发中 channel.basicQos 的设置原则以及 prefetch 过大/过小对吞吐与延迟的影响？ A round-robin 是公平的默认分发 B prefetch=1 吞吐最高 C prefetch 越大越公平 D basicQos 设置未确认消息数上限，实现按处理能力公平分发 ✓ 正确答案
# 13. 消息顺序保证中单队列单消费者与多消费者两种场景下 RabbitMQ 如何（不）保证顺序以及业务如何自行排序？ A requeue 不影响顺序 B 多消费者也能保证全局顺序 C 单队列单消费者可保证顺序，多消费者并行消费会破坏顺序 ✓ 正确答案 D 顺序与消费端并发无关
# 14. 连接与信道管理中连接/信道数上限与内存开销以及客户端连接风暴的服务器端限制与防护？ A 连接风暴只影响客户端 B 信道与连接无关，不起内存 C 连接越多越好，无需限制 D 一个 TCP 连接可承载多个信道，连接与信道都占用内存，需限制并复用 ✓ 正确答案
# 15. 大消息处理中 frame_max 对消息大小的限制与大消息的存储/序列化策略？ A frame_max 限制帧大小，大消息应放外部存储、MQ 只传引用 ✓ 正确答案 B frame_max 无限制，任意大小消息可发 C 大消息在内存中处理无压力 D 大消息无需序列化优化
# 16. Streams 与 Quorum 队列运维中日志分段存储、消费游标与保留策略 A Streams 采用日志分段存储，支持按 offset 回溯消费与保留策略 ✓ 正确答案 B Streams 消费后消息立即移除 C Quorum Queue 支持任意回溯 D Streams 无消费游标
# 17. 多租户与治理中 vhost 隔离、资源配额（limits）、监控大盘与告警设计 A vhost 不影响权限隔离 B vhost 隔离逻辑资源，配额限制资源占用，监控保障可观测 ✓ 正确答案 C 配额只能限制内存，不能限制磁盘 D 多租户无需监控大盘
# 18. 延迟消息实现中 TTL 加 DLX 经典方案与延迟消息插件（rabbitmq_delayed_message_exchange）的取舍 A TTL+DLX 用原生机制模拟延迟，灵活性与性能受限；延迟插件支持任意延迟 ✓ 正确答案 B TTL+DLX 支持任意灵活延迟 C 延迟插件无需依赖任何插件 D 两者性能与功能完全相同
# 19. 迁移与升级中 3.x 到 4.x 的兼容性、镜像队列迁移到 Quorum 队列的路径与风险 A 3.x 到 4.x 无需关注移除特性 B 4.x 移除镜像队列，需将镜像队列迁移到 Quorum 队列，迁移有丢消息与顺序变化风险 ✓ 正确答案 C 镜像队列在 4.x 仍可用 D 迁移 Quorum 队列无任何风险
# 20. 高可用切换细节中 Quorum 队列的 leader 选举与少数派存活以及客户端重连与重发布的行为？ A leader 变更时客户端无需重连 B 少数派存活也能正常写入 C Quorum Queue 基于 Raft，leader 故障时多数派存活才能选举新 leader，少数派存活时禁止写入 ✓ 正确答案 D Quorum Queue 无 leader 概念
