消息可靠性保证：生产者确认、持久化、消费者ACK机制

面试问题：如果消息在发送过程中丢失了，你如何排查并保证可靠性？

面试官考察点：是否理解生产者确认机制（ACK 级别）、重试策略、以及事务消息的使用场景。

回答框架：① 确认模式选择（acks=all / 同步写入）；② 失败重试 + 幂等性；③ 回调或事务消息兜底；④ 验证：查看消息轨迹。

简短示例回答：我会先设置 acks=all 确保 Leader 和所有 ISR 副本都写入。同时开启重试（retries=3）并配合幂等生产者防止重复。若仍失败，使用半消息 + 事务补偿机制，或记录到本地表进行定时扫描重发。

可能追问：acks=0 或 1 为什么可能丢消息？事务消息如何保证最终一致性？

避坑提醒：不要只提“设置 acks=all”就结束，要说明重试可能引发重复消息，必须配合幂等性。

面试问题：假设 Broker 突然宕机，你怎么确保已收到的消息不丢失？

面试官考察点：持久化策略（刷盘时机）、副本机制、以及操作系统层面的知识。

回答框架：① 持久化级别（异步刷盘 vs 同步刷盘）；② 副本同步（ISR 机制）；③ 顺序写 + 日志文件；④ 重启恢复流程。

简短示例回答：我会启用同步刷盘（每个消息写入后强制 fsync），并配置至少 2 个副本（min.insync.replicas=2）。同时利用顺序写提升吞吐，宕机后通过日志回放恢复未刷盘的消息。对于重要场景还可开启事务日志双写。

可能追问：你觉得同步刷盘对性能影响多大？如何权衡？RocketMQ 的刷盘策略与 Kafka 有何不同？

避坑提醒：不要忽略操作系统页缓存的影响；讲清楚“写成功”是指写入磁盘还是写入页缓存。

面试问题：如果消费者处理完消息后提交 ACK 失败，会发生什么？如何设计？

面试官考察点：是否清楚手动 ACK 与自动 ACK 的区别、offset 提交时机、以及幂等消费。

回答框架：① 使用手动 ACK 模式；② 先处理业务再提交 offset；③ 失败处理：重试或转入死信队列；④ 业务侧幂等设计（去重表/唯一键）。

简短示例回答：我会选择手动 ACK，业务处理成功后才提交 offset。若处理失败，将消息放入重试队列并记录日志；超限后转入死信队列人工处理。同时在消费逻辑中加入去重机制（如用 Redis 或数据库唯一约束）防止重复执行。

可能追问：自动 ACK 在什么场景下能接受？如何实现消息的至少一次语义？

避坑提醒：避免说“失败就重新消费”，要区分“处理失败”和“提交失败”；强调业务幂等是根本保障。