快手 AI 全栈二面凉经

《面试题目》

1. 项目
2. @Transactional 相关注解参数、失效时机等
3. MySQL 隔离级别可重复读，解决部分幻读之类的
4. Redis 大 key 定义、解决
5. MySQL 主从相关的东西
6. 后面都问了啥忘了（作者注：Go 八股没背，只能硬着头皮回忆 Java 八股）
7. 最后 AI Coding 是给你一个很简短的题目和几个最基础的功能，让你在产品视角上落地这个产品，配合 AI 制定要实现哪些功能，并实现和测试

---

《参考解析》

1. @Transactional 的失效时机：rollbackFor 决定哪些异常触发回滚，默认只认 RuntimeException 和 Error，抛受检异常必须显式声明；propagation 决定事务怎么传播，REQUIRES_NEW 会挂起外层事务开新事务，NOT_SUPPORTED 直接不参与事务；readOnly 影响的是驱动层的优化提示，不是强制约束；timeout 超时会抛异常并回滚。失效场景主要是代理没生效（同类自调用、非 public 方法、final 方法）和异常被吞掉。另外注意 @Transactional 与 synchronized 一起用时，锁的释放早于事务提交，可能出现「锁内查不到、锁外已提交」的问题。
2. 可重复读与幻读：InnoDB 的 RR 用 MVCC 保证普通一致性读在整个事务里看到同一个快照，因此不会出现不可重复读；幻读在「快照读」下也基本被消除。但在「当前读」（select ... for update、update、delete）时仍需靠 Next-Key Lock（记录锁 + 间隙锁）来阻止其他事务在区间内插入，这才是 RR 下幻读被「部分解决」的原因。要区分快照读和当前读来回答，比笼统说「RR 解决了幻读」准确得多。
3. Redis 大 key：一般按「value 超过 10KB」或「集合类元素超过 5000 个」这类经验阈值来判断，也可以直接 redis-cli --bigkeys 或分析 RDB 得到实际分布。危害是单次操作阻塞主线程、网络带宽被打满、集群下分片倾斜、删除时同步释放内存造成卡顿。处理方式：拆分（按业务维度分成多个 key）、用 HSCAN / SSCAN 分批遍历、删除时用 UNLINK 异步回收；设计阶段就要给 key 设 TTL 和容量上限，避免无限增长。
4. MySQL 主从：主库把变更写进 binlog，从库的 IO 线程拉取并写入 relay log，SQL 线程重放，实现异步复制；半同步复制要求至少一个从库确认收到才算提交，牺牲一点延迟换更低的数据丢失风险。典型问题是主从延迟，读写分离下会读到旧数据，缓解手段有强制走主库读、semi-sync、并行复制、以及把大事务拆小。回答时最好补一句：延迟监控和「哪些读可以容忍旧数据」的白名单机制，比单纯调参数更重要。
5. AI Coding 场景题怎么答：别一上来就写代码，先把「谁在用、核心场景是什么、这一版必须有的功能是哪几个」讲清楚，再让 AI 生成实现，最后补上测试和边界。面试官看的通常不是最终代码量，而是你有没有产品判断——能不能砍功能、能不能说清验收标准、会不会对 AI 产出做验证。