美的 软件开发 一面面经：素材生产 Agent 与分库分表设计

《面试题目》

1. 实习经历
2. 有没有比工作流方式更适合产出短视频方案、更加灵活的做法？
3. 让你设计一个素材生产 Agent，你会怎么设计？
4. 你是如何进行压缩的？
5. 你如何保证重要信息不会被压缩掉？
6. 大模型如何与 Agent 进行交互？
7. 你项目中的分布式锁如何实现？
8. 如何防止死锁？
9. 任务没有执行完怎么办？
10. 看门狗机制的原理
11. B+ 树的性质
12. 三层能存 2000 多万数据是怎么算的？
13. 如果索引很大会导致层高变高吗，比如说联合索引？
14. 如果有 5 亿数据量，你怎么设计表？
15. 你如何进行分表？
16. 跨表分页如何实现？
17. 业务层聚合会不会导致 OOM？
18. 我要查一条数据，怎么确定是哪个表查询？
19. 分布式事务如何实现？
20. 你们那里的分布式事务方案是什么？
21. 比如说库存扣减，你会选用哪种分布式事务方案？
22. 微服务主要的组件有哪些？
23. 微服务有什么好处、有什么劣势？

反问：业务

《参考解析》

1. 素材生产 Agent 的设计题要先把链路画出来：输入（需求、品牌规范、素材库）→ 脚本与分镜 → 素材生成（图、视频、文案）→ 组装 → 质检 → 人工确认 → 交付。然后说清哪几步交给模型、哪几步用规则或工作流兜住：确定性流程用工作流，需要判断、探索、救场的环节才用 Agent。追问「有没有比工作流更灵活的方式」时，落点应当是可控性换灵活性——自由度上去以后，质检和回滚必须补上。

2. 上下文压缩的关键是「结构化留要点」，不是把历史复述一遍：分层处理——系统提示与规则常驻，任务状态沉淀成结构化摘要（目标、约束、已完成、待办、关键实体），原始对话按需检索回填。保真的做法是把关键实体、数值约束、未完成事项单独抽成字段，而不是指望模型改写时不丢信息；压缩完回跑几个关键问题做验证，是最有说服力的答法。

3. 分布式锁要答出正确释放与续期两件事：Redis 用 SET NX PX 加唯一 value 占锁，释放时用 Lua 比对 value 再删，避免误删别人的锁；锁的过期时间与业务耗时不一致时，用看门狗定时续期，业务结束再主动释放。还要能说出锁粒度、可重入、以及 Redis 主从切换导致锁丢失的风险与 Redlock 的争议。防死锁靠超时、续期与唯一的持有者标识，别把「不设置过期时间」当方案。

4. B+ 树的层高是可以算出来的：非叶子节点只存键和页指针、不存数据行，所以一页能放很多键；三层容量约等于「内节点扇出² × 叶子行数」。按页 16KB、bigint 主键 8 字节加 6 字节页指针算，单页约 1170 个键；叶子行按 1KB 估，一页约 16 行，于是三层约 1170×1170×16 ≈ 2190 万行，这就是 2000 多万的来历。索引列越宽扇出越小，联合索引尤其明显，层高可能变高、查询多一次 IO。

5. 5 亿数据的表设计先问「能不能不分」：先做归档与冷热分离、清理冗余索引和大字段，能靠分区表和读写分离解决就不分库分表。真要分，先定分片键——按用户或租户维度，保证绝大多数查询能落到单分片；范围分片便于归档、哈希分片分布均匀，各有取舍；检索类需求可以另外同步到 ES。

6. 跨表分页是分库分表最难的地方：offset 深分页在分片下会放大成全分片扫描，应该改成游标分页（带上一页的最大 ID 或时间戳）。跨分片取前 N 用小顶堆归并，跨分片 count 和任意排序则要有取舍，能设计成路由到单分片最好。答这题时要主动点出「分页方案要在设计分片键时就一起考虑」，而不是事后补救。

7. 分布式事务选型按一致性要求分档：强一致场景用 TCC 或 AT 模式；库存扣减这类高并发写更适合「Redis 预扣 + 消息队列异步落库 + 最终一致」，或者本地消息表、事务消息。无论选哪种，都要讲清补偿、幂等与对账——只说「用 Seata」等于没答。

8. 微服务的优劣要结合自己项目里的例子：组件层面答全注册中心、配置中心、网关、RPC 框架、链路追踪、限流熔断、消息队列；好处是独立部署与扩容、技术异构、故障隔离、按团队拆分；代价是分布式复杂度、链路变长带来的一致性难题、运维与排障成本上升。能举一个自己踩过的坑（比如一个请求跨了五个服务后怎么定位），比背优缺点清单更有分量。