360 全栈一面：Redis 热点 key 怎么办、老仓库怎么改成 AI 原生

《面试题目》

1. 自我介绍。
2. 是否有存储相关的实习或者项目经历？
3. 如果 Redis 中热点 key 访问过多，如何处理？
4. 如果现在使用 Code Agent 去编程，给它一个需求，它把分析、写代码、测试都在内部完成，一次完成，怎么去做？
5. 怎么保证最终交付给我们的代码和我们的需求一致？
6. 现在有一个老的代码仓库，改造成 AI native 的代码仓库怎么去做？

《参考解析》

Redis 热点 key：先判类型——读多写少的「热读」和写集中到单个 key 的「热写」解法不同。热读：本地缓存（Caffeine）挡一层、key 加随机后缀做分片后聚合、多副本从库读、必要时把结果物化。热写：拆分 key（按维度散列）、用消息队列削峰异步落库、批量合并写。另外从根上治：热点 key 会打爆单个分片，集群模式下要提前做 key 设计避免倾斜；监控上抓 hotkeys/--hotkeys 与慢查询，先确认是真热还是大 key 拖慢。

让 Code Agent 一次完成分析、编码、测试，要把它拆成可验证的阶段而不是许愿：先把需求转成验收标准（输入输出、边界、失败行为），再让它产出改动计划（涉及哪些文件、为什么），然后分步改代码、每步跑测试，最后自检（lint、类型、单测覆盖新增分支）。工程上靠三件事兜住——可执行的测试作为判据、每次改动小步提交、把「跑测试的结果」回灌给模型让它自己修。

怎么保证交付与需求一致：把「一致」变成机器可判定的东西。需求侧写清楚验收用例；代码侧要求新增/修改的行为都有测试覆盖；评审时对照验收用例逐条检查；对模型输出做静态检查与依赖审查（有没有悄悄换库、改接口）。再加一道「人工只看决策点」的闸：改公共接口、改数据模型、改鉴权这类必须人确认。

老仓库改造成 AI native，顺序建议是：先建护栏（CI 里的 lint/类型/测试要能跑通、失败即拦），再补「可读性基建」（模块边界文档、关键路径的注释与示例、可运行的本地环境），然后才是给 Agent 用的东西——仓库级规则文件（怎么构建、怎么测、什么不能碰）、常用任务的脚本化入口、以及小颗粒度的任务模板。护栏没建好就上 Agent，产出的是不可合并的代码。

存储相关经历这题是引子，准备一个能讲深的例子即可：数据量、读写比例、选型理由（为什么 MySQL 还是 Redis、为什么加索引或分库分表）、遇到的问题与解决。