美团后端一面：埋点、Agent 工作流与消息幂等

《面试题目》

1. 直播间项目由几个人开发，工作量和业务规模多大，后端怎样分工？
2. 埋点数据最终存在哪里，底层如何存储，是否可能丢失？
3. 采集哪些数据，为什么需要把这些数据放在服务端？
4. 是否遇到开发后才发现职责划分不合理的需求，技术方案怎样评审？
5. 上线后出现过哪些问题，怎样处理？
6. Agent 工作流的需求来自哪里，自己负责哪些部分？
7. 第一个任务生成错误代码时，后续任务会不会放大错误，怎样定位和处理？
8. 同事使用后反馈如何，生成代码是否符合团队规范，原因怎样分析？
9. 多个任务全部串行生成后再统一审查有什么问题，是否考虑逐任务执行和审查？
10. 模型生成代码质量不高有哪些原因，任务数量增多会怎样影响结果？
11. 调研过哪些编码工具与工作流方案，如何比较它们？
12. 生成结果能否直接被业务人员理解，还需要怎样改进？
13. MySQL 有哪些事务隔离级别，怎样排查和优化慢查询？
14. Java 线程池从提交任务到拒绝任务的流程是什么？
15. Java 线程怎样创建并开始执行？
16. 消息队列适合哪些场景，消费者设计有哪些原则，怎样实现幂等？
17. Redis 如何完成原子操作，只允许消费一次的场景为什么会选择 Lua 而非单独 SETNX？
18. Spring 事务有哪些使用方式，代码怎样组织？
19. 如何原地反转单链表的指定区间 left 到 right？

《参考解析》

工作流先把失败留在当前任务

每个任务需要清楚的输入、改动范围和验收条件。完成后检查实际差异及运行结果，符合条件才让后续任务依赖它。一次生成大量改动会增加审查难度，也更难找到错误从哪一步开始。复盘时可以拿一条失败记录，区分需求理解偏差、上下文缺失、工具执行失败和验证不足，再解释为什么相应改法有效。

消费者幂等不能只靠内存标记

用稳定的业务事件编号识别重复消息，并让去重记录与业务写入具备一致的提交边界。例如同库操作可放在一个事务内，再用唯一约束挡重复。业务处理成功后确认消息；如果确认失败导致重投，仍由幂等机制保证不会重复执行。失败消息还需要可追踪的重试次数和后续处理方式。

Lua 与 SETNX 对应的动作不同

单条 Redis 命令自身是原子的。若需求仅是“键不存在才写入”，可使用 SET 的 NX 选项，并按需要附带过期时间；若要先检查状态、再修改多个值，则需把这些动作合成原子执行单元。Lua 脚本执行期间不会插入其他客户端的命令，但它不提供数据库式的失败回滚，脚本运行时出错前的写入可能已生效。

区间反转链表

设置哑节点，先找到第 left 个节点的前驱。保留区间的第一个节点作为反转后的尾部，反复把它后面的节点摘下，插到前驱后面，共移动 right − left 次。这样可统一处理从头节点开始反转的情况。遍历时间为 O(n)，额外空间为 O(1)；left 等于 right 时直接返回原链表。