美的 Java 秋招一面：RT 升高、Kafka 堆积与分布式锁设计

《面试题目》

面试 24 届，无手撕，全部围绕八股与项目场景追问。

1. 查询数据库的接口 RT 越来越高，怎么处理？
2. 能不能匹配到联合索引？底层数据结构是什么？
3. Kafka 消息堆积怎么办？
4. 幂等是怎么设计的？
5. 分布式锁是怎么设计的？SET NX EX 为什么要原子执行？
6. Redisson 的看门狗机制是怎么做的？
7. 流量控制是怎么做的？
8. AI 智能客服的幻觉怎么产生的？怎么解决？
9. Transformer 架构由哪些组件构成，各自的功能是什么？
10. 跨域问题怎么解决？
11. AI coding 的题目你是怎么做的？

《参考解析》

接口 RT 升高先定位再优化

按链路分段量化：网关、应用、SQL、下游 RPC、序列化各占多少。数据库侧先看慢查询日志和执行计划，确认是全表扫描、回表过多、还是索引选择性差；应用侧看连接池等待、GC 停顿、线程池排队。没有分段数据就动手加缓存，通常只是把问题推后。

联合索引能不能用上

联合索引遵循最左前缀：条件里跳过最左列、或在列上套函数与隐式类型转换，都会让后续列失去索引能力。范围查询之后的列一般也只能过滤、不能继续用于定位。判断依据是执行计划里的 key 与 key_len，不是猜。

Kafka 堆积

先区分是短时流量尖峰还是消费能力长期不足。消费者侧看单条处理耗时、是否有同步阻塞的下游调用，能并发就提高分区数与消费者并发；消费逻辑里的批量写、慢 SQL、同步 HTTP 是最常见的瓶颈。长期方案是削峰、批处理与背压，而不是无限加机器。

幂等与分布式锁

幂等要落到唯一键上：业务单号加唯一索引，插入冲突即视为重复；或者状态机加乐观锁版本号，保证同一条记录只被推进一次。Redis 锁用 SET key value NX PX ttl 一条命令完成「判断 + 占位 + 过期」，拆成 SETNX 再 EXPIRE 会在两步之间宕机留下永不过期的死锁。value 放请求标识，释放时用 Lua 比对后再删，避免误删别人的锁。Redisson 的看门狗在未显式指定过期时间时按固定周期续期，进程崩掉后锁自然过期。

AI 客服幻觉

幻觉来自模型在缺乏依据时仍然生成流畅文本。工程上的收敛手段：检索增强把回答限制在知识库片段内，找不到依据就转人工；约束输出结构并做后置校验，金额、时效、政策这类字段走规则或数据库回填；上线前用真实问题集回归，重点盯高频问题的错误率。