蚂蚁集团 AI 应用研发一面：Redis bigkey/hotkey、OOM 排查与提示词注入

《面试题目》

1. 实习经历
2. Redis 如何处理 bigkey 和 hotkey？
3. Redis 的主从同步是如何做的？
4. Redis 主节点挂了，从节点如何晋升？
5. 线上服务在流量没有明显增加的情况下，突然报 OOM，且 CPU 飙高，如何排查和应急？
6. 数据库的事务是什么？
7. MySQL 为什么用 B+ 树？
8. 如何避免提示词注入？
9. 在与大模型对话的过程中，如何避免上下文压缩带来的对话质量下降？
10. 如何治理 skill？

《参考解析》

bigkey 与 hotkey 是 Redis 上两种性质完全不同的风险。 bigkey 的痛点是「单次操作耗时与内存占用」：Redis 单线程模型下，一次 DEL 一个百万元素的 key 或者对大 Hash 做 HGETALL，都会阻塞其他请求。处理方式是拆——按业务维度把大 Hash 拆成多个小 key（分桶后按 hash 取模定位），大 List 按时间或分段切；删除要改成渐进式（UNLINK 或分批 HDEL），别用一次性 DEL。hotkey 的痛点是「单 key 流量集中在一个分片」，通常不是数据大，而是访问次数占了很大比例：加本地缓存挡在最前面、把 key 复制成 N 个副本散到不同节点由客户端随机读、读写分离、必要时在网关层限流。多副本方案只适用于读多写少且能容忍短暂不一致的场景——这点面试官会追，所以要主动说清代价。

主从同步与故障晋升，要能讲到偏移量和选举。 首次同步走 psync：从库带偏移量请求，主库判断无法增量就触发全量，fork 出子进程生成 RDB 快照，期间的写命令缓存在 replication buffer 里，快照传完再补发增量。日常增量靠 repl_backlog 环形缓冲，一旦从库断开太久、偏移量被覆盖，就只能再次全量。晋升则是哨兵或 Cluster 的职责：哨兵集群通过主观下线 + 客观下线（多哨兵投票）判定主库故障，然后由 leader 哨兵从从库里按优先级、复制偏移量、runid 选新主，其余从库 replicaof 切到新主。这里必须主动补充异步复制的数据丢失窗口和脑裂：主库没真正挂、只是网络分区时可能出现双主，要靠 min-replicas-to-write 之类的配置在写入侧兜底。面试官问「从节点如何晋升」通常是想听 Raft 式的多数派选主，Cluster 里就是各主节点投票、需要多数派同意。

突发 OOM + CPU 飙高，排查要分「先止损、再定位」。 流量没涨说明不是单纯容量问题，通常是内存泄漏、大对象突增、缓存击穿，或者频繁 Full GC 导致的连锁反应。应急顺序：先摘流量/重启实例止血并保留现场（dump、GC 日志、指标），再用 jstat 看 GC 频率与老年代增长、jmap/-XX:+HeapDumpOnOutOfMemoryError 拿堆快照，top -H 加 jstack 找 CPU 热点线程。判据是「老年代是否持续上涨且 Full GC 后不回落」——不回落基本就是泄漏，按引用链找到堆积对象；能回落则更可能是瞬时大对象或缓存策略问题。注意 CPU 飙高有时是 GC 线程在打转（因为内存问题），别一上来就归因到业务代码死循环。

MySQL 为什么用 B+ 树，答案要落在磁盘 I/O 上。 B+ 树是非叶子节点只存键、不存数据，所以单个 16KB 页能放更多键、树更矮（三层可支撑千万级数据），一次查询只需 3 次左右的页读取；叶子节点用双向链表连起来，范围查询和排序可以顺序扫描，而 B 树需要在层间反复跳转；数据全部在叶子层的同深度位置，查询耗时稳定。和哈希索引比，B+ 树支持范围、排序和最左前缀，哈希只支持等值。

提示词注入的防护要在架构上做，而不是靠提示词里加一句「忽略恶意指令」。 核心原则是把模型当不可信执行器：用户输入与系统指令从数据通道上隔离（明确分隔、结构化包装），模型输出不直接触发高危动作，所有工具调用走白名单 + 参数校验 + 权限最小化，涉及写操作或敏感数据时强制人工确认。检索内容同样是不可信输入（RAG 里藏指令是常见攻击面），所以对外部文档也要做注入检测和去指令化处理。检测层面可以做输入侧的关键词/意图分类和输出侧的一致性校验，但这两层都只是兜底，真正有效的是权限边界和动作确认。

上下文压缩掉质量是必然的，能做的是让损失可控。 自由文本摘要会丢三样最要命的东西：数字、否定和约束条件。更稳的做法是把长对话压缩成结构化状态——已确认的事实、未决问题、约束与偏好、已完成动作，而不是让模型自由复述；远期内容存进可检索的记忆，需要时按问题回灌原文而不是吃摘要；近期对话保留完整原文。压缩后加一道自检（关键实体/数字是否仍在），并把「压缩后的多轮任务成功率」纳入评测，否则压缩率的收益看不出代价。

skill 治理本质是软件工程问题。 每个 skill 就是一份给模型看的可执行文档，要有明确边界（什么场景该触发、什么不该）、版本管理、依赖声明和失败语义；要有可观测性（调用成功率、人工接管率、失败样本回流）；要有回归集，改了描述必须跑一遍防止触发面漂移。最容易被忽略的是数量膨胀：skill 越多，模型的选路越容易出错，所以要定期合并低频项、把重叠能力收敛到一个入口。