卓越教育后端开发面经：索引、Redis 与幂等组件

《面试题目》

1. 实习经历相关的问题。
2. MySQL 的索引类型有哪些？
3. Redis 有哪些数据结构？
4. 购物车适合用哪种数据结构，key-value 怎么设计？
5. 平时怎么用 AI 工具？
6. 怎么保障 AI 不会重复给出错误结果？
7. 项目相关的问题。
8. 幂等组件怎么设计？锁和数据的过期时间怎么定？
9. 反问：团队规模、组内方向与开发语言。

《参考解析》

MySQL 的索引类型。 按数据结构分，最常用的是 B+ 树索引：非叶节点只存键，树矮（千万级数据大约三层）、叶子节点用双向链表串起来，因此等值查询与范围扫描都很高效，是 InnoDB 的默认选择。哈希索引（Memory 引擎或自适应哈希）只支持等值、不支持范围与排序；全文索引用于文本检索，生产上更常见的是外接 ES；空间索引（R-Tree）用于地理位置。按物理含义分，InnoDB 里聚簇索引就是主键索引、叶子节点直接存整行数据，二级索引的叶子存的是主键值，所以通过二级索引查非索引列需要「回表」。按列数分单列与联合索引，联合索引遵守最左前缀，设计顺序通常是「等值条件在前、区分度高的在前、范围条件放最后」，并尽量让高频查询走覆盖索引避免回表。几个常被追问的边界：主键建议自增（避免页分裂与随机写）、区分度极低的列（性别、状态）单独建索引收益很小、索引不是越多越好（每次写入都要维护所有二级索引，占空间也拖慢写入）、以及索引失效的典型场景（列上做函数运算或隐式类型转换、前导 % 的模糊匹配、or 连接非索引列）。回答时把「为什么快」和「代价是什么」都带上，比只背失效清单更完整。

Redis 的数据结构与底层编码。 对外是五种基础结构：String、Hash、List、Set、ZSet，另有 Bitmap、HyperLogLog、GEO、Stream 这类扩展。面试官通常想听的是「同一个类型在不同规模下用不同编码」：String 底层是 SDS（带长度、二进制安全、预分配减少扩容），小整数会走共享对象；Hash 在元素少且短时用 listpack（早期 ziplist），超过阈值转为 hashtable；List 早期是 ziplist + quicklist，新版本统一为 quicklist（quicklist 里每个节点是 listpack）；Set 在全是整数且规模小时用 intset，否则用 hashtable；ZSet 在小规模用 listpack，大规模转 skiplist + dict（dict 提供 O(1) 的分数查询，skiplist 支持范围与排名）。这套设计的动机是「小数据省内存、大数据保性能」，阈值由 *-max-listpack-entries / *-max-listpack-value 控制，超过就转换且不会转回来。还要说清单线程模型的影响：命令是原子的，但慢命令（keys、大集合的 smembers、大 key 的删除）会阻塞整个实例，所以生产上用 scan 分页、用 unlink 异步删除、并监控慢查询与大 key。持久化上 RDB 快照与 AOF 各有取舍，缓存场景一般配合过期策略（惰性 + 定期采样删除）与内存淘汰策略（allkeys-lru 等）一起讲。

购物车用哪种数据结构、key-value 怎么设计。 购物车的访问模式是「按用户读全量、按商品增删改单个条目、需要控制过期」，最贴合的是 Hash：cart:{userId} 为 key，field 是 skuId，value 存结构化的条目信息（数量、选中状态、加入时间、促销快照等，通常序列化成 JSON 或紧凑字符串）。选 Hash 而不是 String 存整个 JSON 的理由是并发与开销：改一个商品不需要读改写整个购物车，天然避免了并发覆盖（单个 field 的操作是原子的），并且能对单个 field 设逻辑过期。如果业务需要按「加入时间」排序或做最近浏览，可以用 ZSet 存 skuId → 时间戳，条目详情放 Hash，两者组合；但要注意跨结构的原子性，通常会落到 Lua 脚本或直接以数据库为准。key 设计要点：加业务前缀与版本（cart:v1:{userId} 便于重建与灰度）、用 Hash Tag 保证同用户的多 key 落在同一分片（cart:{userId}:detail 这类写法在 Redis Cluster 下会被路由到同一 slot）、以及区分「缓存」与「存储」——购物车是有状态业务数据，Redis 更适合作为加速层，权威数据仍要落库并做双写或异步回源。过期策略上整个购物车设一个较长的 TTL（如 30 天）并在每次写入续期，条目级的「失效」用字段标记而不是删除，便于回溯与恢复。

幂等组件的设计与锁、过期时间。 幂等的前提是先确定「幂等键」：来源于业务唯一标识（订单号、请求 id、支付流水号）或客户端生成的 token，服务端用唯一索引或 Redis 的 SET key value NX PX 来保证「同一请求只处理一次」。组件一般分两层：第一层是「请求去重」，用幂等键记录「处理中/已完成」的状态与结果，重复请求直接返回已存的结果（这是幂等最强的形式，用户重试也能拿到同样的响应）；第二层是「业务状态机」，在数据层用带前置状态的 CAS 更新保证状态不会被重复推进（例如 UPDATE ... SET status='SUCCESS' WHERE id=? AND status='REQUESTED'，影响行数为 0 就表示已被处理）。分布式锁适合「防并发重复执行」而不适合做幂等本身——锁会过期、可能误删别人的锁，所以锁必须配合幂等键使用，锁只是减少并发冲突的手段。锁的过期时间不能拍脑袋：应当按「业务 P99 执行时长」留出安全余量（比如 P99 的 2–3 倍），并实现看门狗式续期（持有期间定期续约），同时给续期次数设上限防止死循环占锁；释放锁要用 value 比对（Lua 脚本或 Redisson 的封装）确保只删自己的锁。幂等记录的过期时间则取决于业务的可重试窗口：支付类通常要覆盖完整的退款/对账周期（数天到数十天，多数会直接落库而不是只放 Redis），而普通写接口几天足够；关键在于记录的 TTL 必须大于「用户可能重试的最长时间」，否则过期后重放会变成新请求，反而破坏幂等。用 Redis 存幂等记录时要考虑持久化与主从切换的丢数据风险，对强一致要求的场景以数据库唯一键为准、Redis 只做前置过滤。

AI 工具的使用方式与「不重复给错」的落地。 日常研发里 AI 工具最有价值的三个位置是：读陌生代码与文档（把上下文摘要交给模型，缩短上手时间）、写样板与边界代码（单测、DDL、正则、脚本），以及排查（把报错与日志给它做假设生成，再由人去验证）。回答「怎么保证不重复犯错」时，重点应落在机制而不是模型自觉：一是把「已经确认的规则」写成模型每次都会读到的显式文件（项目约定、目录结构、禁止事项），让约束有单一出处；二是任何模型产出的结论都必须经过程序化验证（编译、类型检查、lint、单测、跑一次真实命令），验证不通过的结论不进代码库；三是把踩过的坑沉淀成可检索的记录并绑定到具体场景，而不是靠记忆；四是对关键路径保留人工复核。要实现「同样的错误不出现第二次」，核心是把一次性教训转成自动化检查项——能写成静态规则的就写进 CI，能写成用例的就进回归集。回答里最好带一个自己踩过并已修好的具体例子（哪个约束、何时加的、之后是否再犯），这比泛泛谈「我会 double check」有说服力得多。

面试节奏与项目追问的准备。 这场面试的结构很典型：实习、八股、AI 工具、项目各占一块，总时长约 40 分钟，意味着每块只能有几分钟的深度，所以答题要「结论先行 + 一到两个展开点」，不要把时间耗在铺垫上。八股部分（索引、Redis）的常见陷阱是背结构而不讲动机，建议每个知识点都准备「它解决什么问题、代价是什么、什么场景不适用」三句话。项目部分被追问的通常是三处：数据一致性与并发（对应幂等、锁、缓存与库的一致性）、性能瓶颈是怎么定位的（要有具体的监控指标与排查路径，而不是「优化了 SQL」）、以及你个人做的取舍（为什么这么设计、有没有更好的替代）。反问环节可以围绕团队的技术方向（例如组内对外输出 AI 能力、以 Java 为主栈）、新人培养路径、以及业务指标的考核方式提问，这些问题的答案能直接判断岗位是否符合预期，比问薪资更有效率。